Samba Hit By 'Highly Critical' Vulnerability

sawky puck writes "Researchers at Secunia have flagged a 'highly critical' vulnerability in Samba, the widely deployed open-source software for networked file sharing and printing. Successful exploitation allows execution of arbitrary code by tricking a user into connecting to a malicious server (e.g. by clicking an 'smb://' link) or by sending specially crafted packets to an 'nmbd' server configured as a local or domain master browser. This issue affects both Samba client and server installations."

CVE-2008-1105

[xmas2003]

Here's the assigned Common Vulnerabilities and Exposures [samba.org] - "Boundary failure when parsing SMB responses can result in a buffer overrun"

Already Patched

[Gazzonyx]

Check the samba lists. It's already been fixed and the Debian team should be sending a patched version of samba to their repos for downstream distros either last night or some time today. It's already been rolled in to 3.0.30, IIRC.

Re:CVE-2008-1105

[Besna]

You wouldn't find this by static analysis. The constant in the key comparison is presumably fixed, but the variable "len" is not.

Re:buffer overrun ..

[kvezach]

Not in general. Straightforward "execute what you want" buffer overruns can be thwarted by using no-execute; however, this doesn't stop the overrun from overwriting data so that the right functions will have the wrong input and thus do what the exploit writer wants. So-called return-to-libc attacks (where the exploit writer rearranges the stack so that it calls prexisting functions with interesting parameters) can be made very hard to pull off with address space randomization, but that doesn't help on architectures with 32-bit or lesser size pointers.

Radical virtualization might mitigate the effects so that the bugs are irrelevant (as would a capabilities based system where, even if you do smash the stack, there's nothing interesting you can do with the privileges gained), but that's not stopping the buffer overruns themselves, just making them moot.

smb/nmb filtered by default preventing this

[Danny Rathjens]

Every network I've been on and even some of my current company's ISPs have a policy of blocking all traffic to ports 137 and 139.
Those types of filters prevent anyone following a smb:// link outside their network.

I think this is from way back in the day when remote MS Windows SMB/NMB exploits were a dime a dozen and/or network admins wanted to make sure files weren't being shared to the world.

This is why we have SELinux

[FranTaylor]

"Arbitrary" code will see lots of 'permission denied' errors as it tries to do evil.

Re:CIFS

[profplump]

There's a CIFS server for linux -- it's called Samba.

The bit being deprecated is the SMB network file system, not Samba (which isn't part of the kernel in the first place). The CIFS network file system now supported in the kernel is fully compatible with Samba file servers, and Samba file servers require neither SMB NFS nor CIFS NFS to be enabled in the kernel.

Re:CIFS

[Hatta]

Same thing pretty much. CIFS is an updated version of SMB, samba supports them both. This [iu.edu] might clear it up for you.

Re:Oh jeez

[man_of_mr_e]

That's not going to help you if you click on a malicious smb:// link. Your only hope is to egress block SMB ports (which probably isn't a bad idea anyways).

Re:The last major Samba vulnerability...

[Jeremy Allison - Sam]

There was no exploit known in the wild before this was discovered and patched, so if you install the Debian patch asap you should be fine.

Jeremy.