Five-year-old remote code execution hole patched in Macs, Linux

Five-year-old remote code execution hole patched in Macs, Linux

Summary: Samba has issued new versions and multiple patches for a remote code execution hole in its open source software that is included in most Linux distributions as well as Apple's Mac OS X Server.


The developers of Samba yesterday released new versions and security patches to address a critical vulnerability that can be exploited by remote attackers to execute code as the "root" user from an anonymous connection. All Samba versions between 3.0.x and 3.6.3 (inclusive) are affected. Given that 3.0.25 was released in 2007, the vulnerability has been present in Samba for some five years, as pointed out by ZDNet reader Jeremy Allison.

The company has issued patches addressing the security flaw for currently supported versions of Samba (3.4.x, 3.5.x, and 3.6.x), and Samba administrators are being urged to update. In fact, due to how serious the vulnerability is, patches have been released for all Samba versions from 3.0.37 onwards, even though most of them are currently out of support.

Three new security releases (Samba 3.4.16, Samba 3.5.14, Samba 3.6.4) for currently supported versions have been issued over at Patches against older Samba versions are available at

Here's how Samba described the flaw in its security bulletin CVE-2012-1182):

The code generator for Samba's remote procedure call (RPC) code contained an error which caused it to generate code containing a security flaw. This generated code is used in the parts of Samba that control marshalling and unmarshalling of RPC calls over the network.

The flaw caused checks on the variable containing the length of an allocated array to be done independently from the checks on the variable used to allocate the memory for that array. As both these variables are controlled by the connecting client it makes it possible for a specially crafted RPC call to cause the server to execute arbitrary code.

As this does not require an authenticated connection it is the most serious vulnerability possible in a program, and users and vendors are encouraged to patch their Samba installations immediately.

Samba is the open source software that enables file and print sharing between Windows, Mac OS X, and Linux computers. It comes pre-installed on most Linux distributions, as well as on Apple's Mac OS X Server.

Samba is also included on many UNIX-based devices like network printers, network storage, as well as other media and file-sharing devices, to facilitate transferring files between them and Windows systems. These installations are more difficult to patch, since Samba is embedded and probably can't be updated.

See also:

Topics: Software, Apple, Hardware, Linux, Networking, Open Source, Operating Systems, Security

Emil Protalinski

About Emil Protalinski

Emil is a freelance journalist writing for CNET and ZDNet. Over the years,
he has covered the tech industry for multiple publications, including Ars
Technica, Neowin, and TechSpot.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Not decade old.

    The bug was added in 2007, the reporter is making the mistake of assuming it was in the first version of Samba 3.0.0, wheras it was only introduced in the 3.0.25 release. It's still bad of course, just not 10 years old.

    See here:

    for more details from an authoritative source.

    • Fixed.

    • Whatever happened to that "many eyes" hype?

      One of the biggest myth about FOSS is that "many eyes" approach is better. Truth is: It ain't.

      You know why? B/c there's no incentive to review the code in the FOSS world. It's one thing many big mouth fellas half-heartedly reviewing the code. It's completely another if just a few hired guys reviewing it knowing they'd get promoted should they do a good job or fired should they not. The latter group is far more serious in their reviewing than the first group of loud FOSS talkers.
      • You have a point but...

        I would like to point out that it was *precisely* a code review from a security team that caught this.

        Sure, it took them a while and wasn't caught by many other reviewers, but it *did* happen. I'd prefer this to closed code where no one except the creators can ever do security reviews.

      • There's also another assumption... know the one that just because you can look at 4,000,000 lines of code you're going to ruin your weekend and do so. I would submit to you that out of the hundreds of thousands of Linux users only a few hundred have ever actually opened up the sourcecode for any of their programs/kernels. 99.9% are plain old users, not programmers. And 99.9% of the programmers are busy doing things other than verifying that the codebase they're running on (i.e. the OS) is 100% bugproof.
      • Not a hype

        It seems some one is dreaming about zero bug inside a program. It will not happen, a plain truth. Learn some programming basics.

        Bugs remains hidden, almost non-existence, until it is found by scrutinization or in practice. As long as they do not remain found but not patched. Clearly, SMB team patched its bug more swiftly than Microsoft did in their systems.

        Let me put is this way. The bug hibernated for 5 years, and lived only a few days and was then killed. It is not five years old. This is in sharp contrast with many IE bugs that have been living since IE6.

        Thank you, if you could ever understand the differences between "hibernate" and "live".
    • Loverock Davidson says that's a typical response time from Linux

      Isn't Loverock Davidson always right? :-)
      Over and Out
  • we should thank the community

    for promptly fixing the issue and keeping us safe!
    The Linux Geek
    • Vulnerability Yes, but, in practice a low chance of exploit...

      Any sensible Network Administrator will not expose SMB on the WAN ip.

      Typically, users log onto a Samba Share 'after' arbitrating a 'VPN' (SSL or IPsec) tunnel set up first.

      So, while the vulnerability is serious, a local user behind a Firewall on the LAN subnet would have to perpetrate such an attack.

      Thank Dog it's been fixed.
      Dietrich T. Schmitz *Your
      • A flaw waiting to be exploited

        I see this being used by hackers for targeted attacks. Forexample use infected USB drives to get into a network and then jump from machine to machine and owning a corporation.

        We have seen this before with credit card theft etc. Imagine the havoc this would cause if it got into Amazon/iTunes/Google infrastructure.
        • Lock-down of USB ports is the rule of the day.

          Any Network Admin worth their salt knows USB is a big vector for infection.
          I have had to resort to physical locks on legacy equipment. Newer Windows 7 makes Group Policy management for USB easier.
          Dietrich T. Schmitz *Your
      • Agreed

        Of course the same applies to Windows when an SMB flaw is found. Security through multiple layers is the only way to go. It doesn't matter what OS you're using.

        And I agree about USB being locked down on sensitive systems. Of course you and I both know that Network Admins typically take the route of "least effort required" which means these policies very rarely show in the real world. My personal experience is that applies to Windows, Mac and Linux.
      • And how does the much vaunted LSM fit into this?

        You know the Linux Security Modules you have been boasting about lately. Would [i]they[/i] have found this or is that sort of discussion trotted out for Windows issues?
      • @jatbains ... let me get this straight

        [i]" ... Forexample use infected USB drives to get into a network and then jump from machine to machine and owning a corporation. "[/i]

        You wouldn't by any chance be the all powerful, all seeing Admin' that allows USB usage, enterprise-wide, through group policy settings, would you?

        .. mental note: must never hire jatbains for anything other than janitor in big corporate / multi-national business scenarios.
    • We were late.

      "Promptly" is a relative term :-(. Of course we fixed the problem as soon as we knew about it, but it's a shame it took 5 years for it to be found. During that time we've passed extensive fuzzing tests, static code analysis and many other security audits. It just goes to show that a determined human analysis is currently still better than any amount of automated checking. Hats off to the friendly and professional folks from HP's Zero Day Initiative program.

      I've also had to deal with a vulnerability from the people who sell zero day exploits for a living (mentioning no names here). Those people are just criminals.

    • whoops

      (deleted by poster)
    • Yes, Thanks Community for fixing this promptly after a half dozen years

      This underscores the myth that "many eyes" result in "quality". You know what improves Quality? A concerted, considered approach to Quality with code review and regression testing.....Not "throw it out there and hope a good guy notices the vulnerability before a bad guy does."
      Your Non Advocate
      • You know what improves Quality?

        "A concerted, considered approach to Quality with code review and regression testing"

        And where do you find such an approach? certainly not from microsoft.
      • QA teams


        And, you would be wrong. Microsoft has an exemplar QA process. Read up on it. If not, you can see that in the maturity of their IDE.
        Your Non Advocate
      • Microsoft has an exemplar QA process

        Oh really? we are talking about that same swiss cheese OS known as windows right? let me guess... you happen to work for microsoft.