I was recently taking a look at the state of play regarding the security of POSIX runtime linkers and was pointed at the QNX Neutrino RTOS to take a look. In doing so I noticed a problem relating to the way that it handles LD_DEBUG_OUTPUT which allows for the creation or overwriting of an arbitrary file. Moreover the technique by which this can be achieved can be triggered even where the binary being executed is setUID and is running as another user. Tim -- Tim Brown <mailto:timb (at) nth-dimension.org (dot) uk [email concealed]> <http://www.nth-dimension.org.uk/> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Nth Dimension Security Advisory (NDSA20110310) Date: 10th March 2011 Author: Tim Brown <mailto:timb (at) nth-dimension.org (dot) uk [email concealed]> URL: <http://www.nth-dimension.org.uk/> / <http://www.machine.org.uk/> Product: QNX Neutrino RTOS 6.5.0 <http://www.qnx.com/products/neutrino-rtos/index.html> Vendor: http://www.qnx.com/ Risk: Medium Summary The QNX Neutrino RTOS runtime linker allows the creation or overwriting of an arbitrary file. Moreover the technique by which this can be achieved can be triggered even where the binary being executed is setUID and is running as another user. Technical Details Like glibc, the QNX Neutrino RTOS runtime linker supports the use of the LD_DEBUG and LD_DEBUG_OUTPUT environment variables for debugging purposes. These environment variables are trusted even where the binary being executed is setUID and is running as the another user. It is possible to create or overwrite an arbitrary file like so: LD_DEBUG=all LD_DEBUG_OUTPUT=/pwned <setuid binary here> If the file exists it will be overwritten with LD_DEBUG output and existing permissions preserved however if as in the example above it does not then a new file will be created, owned by root,nobody and writable by both (assuming it was executed by the nobody user). By default, the Neutrino runtime linker looks in /lib and then /usr/lib for dependencies. So by locating a setUID binary that is using a library from /usr/lib and creating one with the same name in /lib then the newly created library will be used. However, the Neutrino runtime linker won't write to /lib so it is necessary to win a time of check, time of use race condition by creating a symlink from the current working directory to the target library under /lib hoping that the link will be added after the check has been made that the value supplied for the LD_DEBUG_OUTPUT environment variable does not point to /lib. After winning the race it is possible to copy a malicious library over the newly created file writable file under /lib and execute the target setUID binary again. This time it loads the malicious library rather than the one in /usr/lib. This library abuses .ctors to get triggered, sets the real UID to the effective UID and pops a shell. Solutions Nth Dimension recommends that the vendor supplied patches should be applied. History On 16th December 2010, Nth Dimension contacted the RIM to report the described vulnerability affecting QNX Neutrino RTOS. from BlackBerry Incident Response responded immediately to confirm that the report had been received and forwarded to the relevant people at QNX. Following on from this, Nth Dimension and the BlackBerry Incident Response team exchanged messages and Nth Dimension supplied a PoC for the reported vulnerability. On the 24th December 2010, BlackBerry Incident Response notified Nth Dimension that the security team at QNX had assigned the flaw the internal reference number PR84526 internally and begun investigations. On the 11th February 2011, BlackBerry Incident Response notified Nth Dimension that QNX intended to issue a fix on the 11th March 2011. Current As of the 11th March 2011, the state of the vulnerabilities is believed to be as follows. A fix has been made available by QNX which it is believed successfully resolved the reported issue. This patch has not however been tested by Nth Dimension preventing us confirming that fact. Thanks Nth Dimension would like to thank all the security folk at RIM, in particular the BlackBerry Incident Response team for the way they worked to resolve the issue.