Slashdot Mirror

← Back to Stories (view on slashdot.org)

Samba Hit By 'Highly Critical' Vulnerability

Posted by timothy on from the because-people-are-bad dept.

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

8 of 70 comments (clear)

  1. CVE-2008-1105 by xmas2003 · · Score: 4, Informative

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

    --
    Hulk SMASH Celiac Disease
  2. Oh jeez by blackjackshellac · · Score: 5, Funny

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

    <snark/>

    --
    Salut,

    Jacques

    1. Re:Oh jeez by value_added · · Score: 4, Funny

      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.

  3. Already Patched by Gazzonyx · · Score: 4, Informative

    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.

    --

    If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.

  4. Re:buffer overrun .. by kvezach · · Score: 5, Informative

    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.

  5. This is why we have SELinux by FranTaylor · · Score: 5, Informative

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

  6. Re:CIFS by profplump · · Score: 4, Informative

    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.

  7. Re:buffer overrun .. by kestasjk · · Score: 4, Funny

    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?"
    --
    // MD_Update(&m,buf,j);