(Please ignore the reply-to address, send to
jallison@whistle.com, I'm posting this from
home).
John wrote:
> Could you provide a synopsis of how the hole is exploited, so that
> we can evaluate our risk --- i.e. does our firewall protect us from
> outside attacks, etc.
Here is a quick synopsis of the bug and
the response.
In short, all Samba versions previous to 1.9.17p2
copy the user password sent by the client in a
SessionSetupAndX command (SMB user logon) into
a fixed size buffer (1024 bytes) on the stack.
Unfortunately the number of bytes that Samba
copied into that buffer was also dependent upon
a variable sent by the client.
The exploit used this fact by sending a very long
password (2k) - the second half of which contained
Linux x86 assembly code to invoke an xterm displaying
back to the attacking machine. The length field was also
set to be longer than the fixed size buffer.
Samba copied the exploit code into the fixed size
buffer which overwrote the return stack, thus allowing
the exploit code to be executed. Samba is running
as root at this point so the exploit code is also
executed as root.
This exploit is done to smbd on tcp port 139. If your
firewall blocks this port from the internet then you
are safe from external attempts to use the exploit.
Andrew had posted a fix in Australia about 1 hour
after the exploit code (which was written for
RedHat Linux) was published on the BugTraq list.
The exploit was published in the night hours in
the USA.
Andrew also reviewed all the code in Samba that
depends on client supplied input and changed all
copies to length limited versions that will print
a message if an overflow occurs.
Currently the Samba code is undergoing a full review
to ensure these problems cannot re-occur.
1.9.17p2 and all future releases will have these
fixes included.
I am currently trying to get a USA CERT advisory
published on this matter, and am awaiting a CERT
callback.
RedHat have a Samba 1.9.17p2 rpm available from
their errata site (at http://www.redhat.com/errata)
and Caldera are also aware of the problem.
I have also informed Sun, HP, SGI and other vendors
who ship Samba on their 'freeware' CD's.
Hope this helps,
Jeremy Allison,
Samba Team.