BugTraq
Medium severity flaw in QNX Neutrino RTOS Mar 11 2011 12:12PM
Tim Brown (timb nth-dimension org uk)
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJNedRaAAoJEPJhpTVyySo7JWAQAMwJnH0cJcD7yK2BKyxfQmXp
qefaSyaig5Gjd5mXuHOdf4nXpv2JczkGkk0t7FUQosqiWhwiTdAAG2T/yIEK0Nx/
OrcRy+l0/H6hxFTazb696KoR89oDrUtCypcndQfiMNDVxIMNmiwU+rt40t/OpIdp
zCj++09nYHnZGRaGVe8PfaTCjsFBRNlIUB6KDwlR1Akdk0laPfLZ5t9A4cPtwBrq
KsyaHhT3bWvipBDRp6AiON/S1xUn9h1e8wfonwkCNC7E+x7HOPztZ8dh/mnbOnlj
kuJrAQjrqrUetNQxYat6B122i69S+h4h3u3mOSS8qBOLhWk1vPdn2W8zwEZseQGE
1A05SMbXv28b8EOG2GBvBAaZAU2nxwkFk8r2RwGrMABkeOY/FLOmbvFAefJJDFWh
Ls0U4RSZDog8QDdE6nicPexdgQ1B0r14jarZIK7SovNLZpSbqE/vXyYsg6+RLx5L
FEJv7YJppcWYRBtONxIxU2pU02NNAOTDiOUOGKcszYI+JmegY/xx0T+Tuj27PFFY
90vHefxlQMPQFvl26KonmGA5yISu5sDfAkNSQAa913n8i/xzzYDRJcdw8iG77s/c
zezvrE9vFzYsujlWabKB2O0w+fP97mZfFCHXe13d+CL5TnAAbr1dPMthq2X+Q74+
T5AfKeCcUv4bV65lEQ/s
=GRee
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAABCAAGBQJNehGxAAoJEPJhpTVyySo7LgAP/209TsU0zybYrFDF/Z0vUYaR
2GKhLd5bEcUj4MJH+U3m60H1pzJf75jFe+4Ya1NzaKy5EoufNuwP1l20zUystpKw
Z2ezdeN2QiUtrB6E+Vly8eDDH7bl6ImPDj6wVVGBeLAVNOQu7t6U4YqE4fnh/5AZ
vpJFHqSZK1sQhUBd9adLH5AlJNu4GU1TwBS9sauj3GV/8Am6NXerL0y4lODXNOCH
P++/jmLMIpBTN56GHIKlgrrka81r0icr66fUBlb92Uwk3keIwWUs19GK7qprilXi
P/d2e6xGRdLjo/D9Z0gY24UqE2nDs4J8S768nuFInoBGKQFUTlLc9Axyv/3AW9eG
sEMqNhNu0bjs8ZcIAdNOhu41qXXxsEeCO9zqLTNeK0kvywxT5wEYJqxJKkzlQ+Sv
MlqkzCnM15Gkhal9IZR9VnEoMeevNbmZHKGQZi1g7hhrP1VU3/zo4WF9PvfXK9cF
VJb4zkB4zdUBT9/DpyV8oPXxn6bJwl7/M080hlrMCrQPtIYKy1C4P8VB5BnYMQFZ
1QMcLy/dnpios5G2yC+85Mzc57Y5fbaum0NmVYP9FAmBLOb0s3mGOduq84iHSzjz
6kHcUvR2otQoSGd07hkHprqOOC8Pz+0hjbWvmnH10AMCZcN8bUg2Jja4YyadL0Gu
40Z+Koo73i+P9MlmVgK1
=mf0J
-----END PGP SIGNATURE-----

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus