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."

Comments

CVE-2008-1105

[xmas2003]

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

Oh jeez

[blackjackshellac]

I guess I better take all of my samba servers off the internet!

<snark/>

Re:Oh jeez

[value_added]

I'll check them for you, free of charge... what did you say their IPs were? :)

My guess is that most of his servers are in the 10/8 or 192.168/16 ranges. Run an nmap scan on those netblocks and I'll bet you'll find something. While you're at it, be sure to check out 127.0.0.1 for any "hidden" servers.

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).

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:Already Patched

[BiggerIsBetter]

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. Yeah, but how long before someone fixes that patch? 2 years?

buffer overrun ..

[rs232]

"Boundary failure when parsing SMB responses can result in a buffer overrun"

Does this apply to a particular CPU/MMU compiler combination or is it generic across all systems? Is it technically possible to design a system that is immune to buffer overruns or, by default, fails safe, as in not allowing any old code to walk all over the address space.

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.

Re:buffer overrun ..

[Anonymous Coward]

Possible? Yes. Possible without sacrificing all hopes of decent performance? Not as far as we know.

For example, you could use your 64-bit address space and put /every single object ever/ in its own page, at 0xXXXXXXXX00000000. Trap pages all around. That ought to do the trick, but now your TLB's shot, and your ints are 4kb large.

Re:buffer overrun ..

[kestasjk]

Is it technically possible to design a system that is immune to buffer overruns or, by default, fails safe, as in not allowing any old code to walk all over the address space. Microsoft labs are working on a solution that'll work like this: "The program you are using wants to write 0x0a83d9ed to the stack at address 0x912dfe31. Confirm or Deny?"

Re:buffer overrun ..

[owlstead]

"Does this apply to a particular CPU/MMU compiler combination or is it generic across all systems? Is it technically possible to design a system that is immune to buffer overruns or, by default, fails safe, as in not allowing any old code to walk all over the address space."

Yes, it's called managed code (Java/.NET) and yes, you can even design hardware that runs byte code. It will slightly hamper performance, but it has its advantages. Of course, the way it is currently done is to implement the JVM in software. That's ok though, you have such a small target running unsafe code that the number of buffer overruns is insignificant.

When there is a problem, an exception is raised. But an exception is a basic component in the byte code and it just crashes that part of the system at worst. Obviously that does not mean you cannot create mistakes when using managed code, but they tend not to spread as far.

Together with a good messaging system and/or immutable objects, you can create a heck of a safe system.

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.

how about this ..

[rs232]

"There is the NX bit, but you'd have to know about how far the buffer can overrun"

"we adapted the memory safety techniques from the SAFECode project .. This work makes the kernel immune to buffer overruns, dangling pointers, and other memory error vulnerabilities"

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 might clear it up for you.

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.

Re:More M$ Vulnerabilities

[nog_lorp]

http://smithii.com/samba.