Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security

Possible SAMBA Vulnerability 32

Posted by michael from the apt-get-time-again dept.
veg writes "The samba team have released 2.2.7 following the discovery of a secureity hole in versions 2.2.2 to 2.2.6 that could lead to remote root access. Eeek! Full story on the samba site"
This discussion has been archived. No new comments can be posted.

Possible SAMBA Vulnerability More

Possible SAMBA Vulnerability

Comments Filter:

  • Too much of a good thing (Score:5, Funny)

    by MarkusQ ( 450076 ) on Thursday November 21, 2002 @12:16PM (#4723900) Journal

    The samba team have released 2.2.7 following the discovery of a secureity hole in versions 2.2.2 to 2.2.6 that could lead to remote root access.

    So, basically, they're vacillating on the question of full SMB compatibility?

    -- MarkusQ

  • When (Score:2, Interesting)

    by Bob Zer Fish ( 568540 )
    When was this vulnerability discovered? People are always comparing Microsoft to OpenSource in the speed of the correction of security flaws. I was wondering if anyone knew, so that I could see if Microsoft is *-that-* bad, or if they're getting better.

    • Re:When (Score:5, Interesting)

      by Jeremy Allison - Sam ( 8157 ) on Thursday November 21, 2002 @01:04PM (#4724367) Homepage
      Eloy Paris and Steve Langasek (spelling?) of the Debian
      Samba community were chasing a user reported core dump bug
      and they noticed the problem.

      They reported it to security@samba.org, and I fixed it that
      night (with a perfectly correct CVS comment that also failed
      to point out the security hole :-).

      We then worked with the Linux vendors via the vendorsec
      mailing list to ensure they were all aware of the problem
      and could issue updates at the same time we announced. Once
      we'd tested the release, we pushed the button and released...

      That is a nice textbook case of how Open Source/Free Software
      security can work.

      Cheers,

      Jeremy Allison,
      Samba Team
  • The word "potentially" is used because there is no known exploit of this bug, and the Samba Team has not been able to craft one ourselves.

    So how do they know it's broken again? ;^)

  • typical rant ahead (Score:2, Flamebait)

    by honold ( 152273 )
    "The samba team have released 2.2.7 following the discovery of a secureity hole in versions 2.2.2 to 2.2.6 that could lead to remote root access. Eeek! Full story on the samba site"

    the slashdot team have released a story to the developers section following the discovery of a "secureity" hole in samba that could lead to remote root access

    what does this have to do with developers? it has everything to do with a large base of the slashdot audience. this should be main page news.
    • Lots of embedded systems developers use Samba to provide SMB services.
      • Lots of carpenters use red trucks to deliver tools and supplies to building sites. That doesn't mean that they're the only people who should be informed if there's a fire on the site.

    • Re:typical rant ahead (Score:3, Insightful)

      by xchino ( 591175 )
      I would justify it being posted here. It hasn't been found to be exploitable, even by the samba team. They have, however released a new version to correct this (as well as add a few features and fixes), showing excellent mode of quality control exceeding that which often even proprietary software vendors fail to meet, in an OpenSource model. Just a thought...

  • Funny... (Score:1, Flamebait)

    by malakai ( 136531 )
    funny how this is hidden over here in Developer.slashdot, while the IE vulnerability gets front page billing.

    -malakai
    • That's because there is known working exploitable code to the IE Bug. Even the samba team wasn't able to craft an exploit for this Potential hole. This is more along the lines of developers showing excellent quality control..

    • Re:Funny... (Score:2, Insightful)

      by elno ( 628225 )
      I think is a matter of relevance :
      IE holes come in a "combo meal" Detail Desc + sample + any side item + toy ( If you want to play with the sample code )

      This samba hole on ther other hand does not even have a concrete way to take advantage of.

      From samba.org:
      A security hole has been discovered in versions 2.2.2 through 2.2.6 of Samba that could potentially allow an attacker to gain root access on the target machine. The word "potentially" is used because there is no known exploit of this bug, and the Samba Team has not been able to craft one ourselves. However, the seriousness of the problem warrants this immediate 2.2.7 release.
  • because it'd be difficult to engineer any runnable x86 code with the conversion from one codepage to another. And I imagine most of the opcodes won't be creatable in that fashion. Still, it's a feel-good reason to upgrade.
  • Firewall ports 137-139(NetBIOS...according to ISS [iss.net] port 139 is the "most dangerous port on the internet")...

    This should keep any machine from accessing internal Samba shares from an external connection and makes these kinds of vulnerabilities irrelevant. Unless you don't trust ppl on your own LAN...then you have other problems...

    I can't think of any real reason to leave a NetBIOS port open to "the outside world"...so for those of us that actually firewall these ports, this is already taken care of...
    • Depending on what level of security you strive for ofcourse. There will always be back entryways into your network. A firewall that stops incoming traffic on let say port 137-139 doesnt stop all attacks. Someone might aswell succed in hacking something else on another port and then go on to the samba server from the internal network.

      I also strongly suggest you not to trust inhouse staff completely. Most hackings that really hurts are insiders that rarely gets discovered.
      • Then you have HR problems...

        And internal LAN is only useful if employees have a certain amount of freedom to do what they need...sure, most things should be password protected, remote access should have multiple "barriers to entry"...SecureID, Login, Pass, etc...

        But...your argument could hold true for any amount of security. Certainly you must understand that at some time, you must trust your employees...

        As for most exploits, they are simply too difficult to implement for your average user to "pull off"...for the rest of your users, they're probably too busy to bother...

        Even then, there's going to be a small group of "troublemakers" that could cause problems, but they are probably going to be fired shortly anyhow...

        So, in short...the only "secure" system is an unplugged system.
        • Hey man, ever seen office space?
          • Exactly...there are certainly truths in this film, but what makes it so funny is that they "cross the line"...There are alot of ppl in the situation they were...but there are reasons why ppl simply won't do that...first thing is most ppl don't want to go to federal "pound me in the A$$" prison!!! Then again, there's also something called morals...

            But then again, when your top programmers are all conspiring to befraud the company, there's not much you can do in IT...the only way to deal with that kind of situation is to clean up the mess...

            In reality, HR skrewed up by letting anyone outside of executive staff know before hand (Peter shouldn't have been told till it happened)...But then again, Milton burns down the building...now how could IT prevent that?
    • Speaking of NetBios ports... the latest spam tactic I saw at one day while booted into windows for some strange reason, is to it to do what amounts to a "net send" that uses windows messenger service. I actually got a friggin "net send" message popping up on my desktop telling me how to enlarge my penis! Windows sucks sometimes. And how the hell did they know my penis was small?

Slashdot Top Deals

To stay youthful, stay useful.

Close