*** Warning: I spent too much time on this issue, and the content of
*** message may turn out to be completely bogus and ridiculous. Be
*** tolerant with what I write.
There's a buffer overflow in SysV's /bin/login, when it is passed too many
environment variables, there's a CERT advisory about it.
The advisory says :
<<
An array of buffers is used to store these arguments. A flaw
exists in the checking of the number of arguments accepted. This
flaw permits the array of buffers to be overflowed.
>>
So far, so good - we just have to send a big number of environment
variables. I started to do this using telnet options, but it would not
work, because for some reason, Sun's telnet server does not allow an
arbitrary amount (in terms of length, not number) of environment
variables to be passed.
Then I stumbled on Wietse Venema's post on bugtraq :
<< Traditionally SYSV login accepts "username name=value name=value..."
both from the command line and from stdin. It isn't hard to find out
if you can/cannot clobber process memory by specifying a sufficient
number of name=value values. >>
The keyword is stdin. It turns out that the following works :
[renaud@bender renaud]$ telnet sparky
Trying 10.163.156.10...
Connected to sparky.fr.nessus.org.
Escape character is '^]'.
SunOS 5.8
login: renaud FOO=BAR
Password:
Last login: Fri Dec 14 11:09:57 from bender.fr.nessu
bash-2.03$ set | grep FOO
FOO=BAR
bash-2.03$
So far so good. Locally, I can make /bin/login crash & dump core by piping
"renaud A=B A=B ......" to /bin/login. However, a backtrace shows a
strange result, so I'm not even sure it crashes "the right way".
When I do the same remotely, I can get /bin/login to exit or crash,
but I get no core file nor any warning in the logs, so I'm not sure that
what happens is a really exceptional condition (maybe it just exits
because it detects something is wrong, or it considers the username as
being too long).
Anyway, attached is a plugin that *may* recognize vulnerable systems.
I'd be interested in people testing it and telling me how it works
for them (false positives / false negatives). As Sun's patch for this
issue has not been released, it makes testing even more difficult.
You can use it as a traditional nessus plugin or directly with nasl:
nasl -t <target> binlogin_overflow.nasl
-- Renaud
*** message may turn out to be completely bogus and ridiculous. Be
*** tolerant with what I write.
There's a buffer overflow in SysV's /bin/login, when it is passed too many
environment variables, there's a CERT advisory about it.
The advisory says :
<<
An array of buffers is used to store these arguments. A flaw
exists in the checking of the number of arguments accepted. This
flaw permits the array of buffers to be overflowed.
>>
So far, so good - we just have to send a big number of environment
variables. I started to do this using telnet options, but it would not
work, because for some reason, Sun's telnet server does not allow an
arbitrary amount (in terms of length, not number) of environment
variables to be passed.
Then I stumbled on Wietse Venema's post on bugtraq :
<< Traditionally SYSV login accepts "username name=value name=value..."
both from the command line and from stdin. It isn't hard to find out
if you can/cannot clobber process memory by specifying a sufficient
number of name=value values. >>
The keyword is stdin. It turns out that the following works :
[renaud@bender renaud]$ telnet sparky
Trying 10.163.156.10...
Connected to sparky.fr.nessus.org.
Escape character is '^]'.
SunOS 5.8
login: renaud FOO=BAR
Password:
Last login: Fri Dec 14 11:09:57 from bender.fr.nessu
bash-2.03$ set | grep FOO
FOO=BAR
bash-2.03$
So far so good. Locally, I can make /bin/login crash & dump core by piping
"renaud A=B A=B ......" to /bin/login. However, a backtrace shows a
strange result, so I'm not even sure it crashes "the right way".
When I do the same remotely, I can get /bin/login to exit or crash,
but I get no core file nor any warning in the logs, so I'm not sure that
what happens is a really exceptional condition (maybe it just exits
because it detects something is wrong, or it considers the username as
being too long).
Anyway, attached is a plugin that *may* recognize vulnerable systems.
I'd be interested in people testing it and telling me how it works
for them (false positives / false negatives). As Sun's patch for this
issue has not been released, it makes testing even more difficult.
You can use it as a traditional nessus plugin or directly with nasl:
nasl -t <target> binlogin_overflow.nasl
-- Renaud
Attached Files:
-
binlogin_overflow.nasl (1.28 KB)