He found this feature during what he describes as a "a very, very boring day, ill at home."
Inputtrap is a utility designed to detect and start the input manager in QNX. It has a -t flag associated with it that specifies the trap file to be read. It seems that there isnt much in the way of permissions checking going on in this particular part of QNX, because Fort found out during that long and boring sick day that you can specify any file in any directory that you want as a parameter to inputtrap.
Most fun for the casual reader, any file or directory means that you can even specify files or directories that you dont specifically have access to. You know, the files that you arent supposed to be able to see? Isnt that special?
This undocumented feature seemingly honks Fort off for some baffling reason. As he says in the original advisory, "This design error problem is similar to an old Debian 1.1 DOSEmu vulnerability, back in 1999. And it was, surely, eradicated in crucial programs of most operating systems." Right on, bro.
Well, now that Fort has shown the rest of us the truth, what is to be done about it? Its funny, but even with the exploit publicly obtainable; there is no official solution available from QNX yet for the RTOS. Fort says that the problem is demonstrable in the v.6.3 or the v.6.1.0 flavor of QNX, as well as the possibility of it existing in other versions.
Fort says that he did notify QNX three months ago of the situation. Interestingly, he notified them four months after he found the exploit but Im sure thats just so his crew (shoutouts to Lucien Rocha, Carlos Barros (barrossecurity.com), George Fleury, Rodrigo Costa (NERV), Despise, gotfault.org and everyone at rfdslabs!) could make sure that this was not a repeatable but irreproducible result originating from Forts particular system. Fort indicates on his timeline that they called him right back the next day. But not since then, it appears.
The do-it-yourselfer who doesnt want to wait for no big deal, big time, big city factory support from QNX may do well to remove the inputtrap suid bit. Perhaps one could change inputtraps permissions to a trusted group of users as an alternative to performing such surgery on the bit. Perhaps there will be better methods available in the future.