Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Samba Hit By 'Highly Critical' Vulnerability

timothy posted more than 6 years ago | from the because-people-are-bad dept.

Security 70

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

cancel ×

70 comments

Sorry! There are no comments related to the filter you selected.

CVE-2008-1105 (4, Informative)

xmas2003 (739875) | more than 6 years ago | (#23590785)

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

Re:CVE-2008-1105 (0)

Anonymous Coward | more than 6 years ago | (#23591073)

The Linux kernel has a few scripts floating around online that provide static analysis of the code. Does Samba have such a feature? I figure a few scripts * hundreds of users with different versions of Samba = more bug finding.

Re:CVE-2008-1105 (2, Informative)

Besna (1175279) | more than 6 years ago | (#23591233)

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

Wow, that is vulnerable! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23590787)

So vulnerable that when I tried to read the story the first time it said "not found"!

Oh jeez (5, Funny)

blackjackshellac (849713) | more than 6 years ago | (#23590861)

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

<snark/>

Re:Oh jeez (1)

Thelasko (1196535) | more than 6 years ago | (#23590969)

exactly what I was thinking.

Re:Oh jeez (1)

Bogtha (906264) | more than 6 years ago | (#23591049)

This affects clients too. It says so right there in the summary even.

Damn! (1)

twitter (104583) | more than 6 years ago | (#23591211)

Better go back to the original.

Re:Damn! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23591349)

Hey Mark Lappin. That has to be you. The only young dork on the page of your little computer club Cajun Computer Club [clickers.org] . Too bad Katrina didn't wipe your ass away. BTW are you fucking Faye? nm you're probably a virgin.

Re:Damn! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23591587)

No, actually that's not Mark. Mark did kick twitter off the CCCC mailing list though. Apparently the "M$ Winblows" didn't go over too well there.

As usual twitter just blamed it on Microsoft. Pretty much the same way psychopaths blame the devil and various voices in their heads for their good deeds.

Re:Damn! (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23592067)

Yeah his name is Will Hill and he is married to a tranny.

Re:Damn! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23594697)

He's probably the most popular [clickers.org] member. He reccomends a lot of things. Dissasster, Opps, Reccomend, Coppies, etc. Yeah, that's twitter alright. I can almost imagine him lecturing normal people on how liberated he feels because he doesn't use "Windoze".

...just the mental images.. the embarrassment... oh god

Re:Oh jeez (1)

Gazzonyx (982402) | more than 6 years ago | (#23591129)

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

Re:Oh jeez (4, Funny)

value_added (719364) | more than 6 years ago | (#23591461)

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 (1, Funny)

Anonymous Coward | more than 6 years ago | (#23591749)

Hah! I've got you now, you idi

Re:Oh jeez (1)

fluch (126140) | more than 6 years ago | (#23591465)

The usual 127.0.0.1. What did you think?

Re:Oh jeez (1)

Carnildo (712617) | more than 6 years ago | (#23593541)

192.168.0.4 and 192.168.17.26

Re:Oh jeez (2, Informative)

man_of_mr_e (217855) | more than 6 years ago | (#23592471)

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

What's that saying, about security and obscurity? (0)

Anonymous Coward | more than 6 years ago | (#23593829)

I'll bet all those people using SAMBA are really happy they didn't use Windows servers instead. Teh FOSS community can obviously do a better job!

Looks like SAMBA might need at least one more set of eyes!

Lunix: got r00t?

Re:Oh jeez (0)

Anonymous Coward | more than 6 years ago | (#23593921)

You do realize that there are people just as eager/willing to hack networks internally as there are externally? In my experience there's more of a danger of a security breach from the employees themselves than from the outside.

Re:Oh jeez (1)

blackjackshellac (849713) | more than 6 years ago | (#23598997)

Well duh, you do realize I was joking, right?

Fscking ACs.

Guess we'll see Apple release 2008-004 soon (1)

argent (18001) | more than 6 years ago | (#23590893)

Because there's nothing about Samba in 2008-003.

Already Patched (4, Informative)

Gazzonyx (982402) | more than 6 years ago | (#23590935)

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 (2, Funny)

BiggerIsBetter (682164) | more than 6 years ago | (#23593271)

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?

Re:Already Patched (1)

shamer (897211) | more than 6 years ago | (#23598099)

Gentoo is patched as well.

net-fs/samba-3.0.28a-r1

Vulnerability? And how! (1, Funny)

Applekid (993327) | more than 6 years ago | (#23590949)

I sure know I have a highly critical vulnerability to a pretty Brazillian lady doing the Samba, eh gents?

Re:Vulnerability? And how! (0, Offtopic)

kellyb9 (954229) | more than 6 years ago | (#23591197)

I sure know I have a highly critical vulnerability to a pretty Brazillian lady doing the Samba, eh gents?
I know you can mod something funny, but is there any way to mod something !Funny?

Re:Vulnerability? And how! (1)

Applekid (993327) | more than 6 years ago | (#23592523)

I sure know I have a highly critical vulnerability to a pretty Brazillian lady doing the Samba, eh gents?
I know you can mod something funny, but is there any way to mod something !Funny?
Offtopic seems to be the mod of choice in this case. I always thought nerds like me loved puns. Maybe only good puns, though.

Other unused one-liners:
"When I do the Samba I'm pretty vulnerable to kicks to the knees"
"Samba has always been vulnerable... to arthritis"
"This vulnerability is easily fixed by switching the audio back to a simple 2/4 beat."

Re:Vulnerability? And how! (0)

Anonymous Coward | more than 6 years ago | (#23593971)

offtopic is what I use.

Re:Vulnerability? And how! (1)

Mr. Jaggers (167308) | more than 6 years ago | (#23595737)

I use judicious quantities of "Overrated".

It's my most favorite-est mod ever.

More M$ Vulnerabilities (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23591009)

I don't know why people still use M$ Windoze.

I guess those idiots get what they deserve.

Samba isn't Windows (1, Flamebait)

JSBiff (87824) | more than 6 years ago | (#23591227)

Samba isn't Windows, this isn't a Windows vulnerability. Thanks for playing. Try again.

Re:Samba isn't Windows (1)

night_flyer (453866) | more than 6 years ago | (#23591551)

looks like you were the one who got played....

Re:Samba isn't Windows (1)

rs232 (849320) | more than 6 years ago | (#23591569)

"Samba isn't Windows, this isn't a Windows vulnerability. Thanks for playing. Try again"

Is it a x86 architecture only vulnerability?

Re:Samba isn't Windows (1)

plague3106 (71849) | more than 6 years ago | (#23591761)

No, it's not, but these kinds of things in WINDOWS lead administrators to block those ports and in out of their networks... which would affect this as well. Windows DID have vunerablities in the SMB protocol way back when..

Re:Samba isn't Windows (1)

Gewalt (1200451) | more than 6 years ago | (#23592337)

Whoosh!

Re:Samba isn't Windows (0)

Anonymous Coward | more than 6 years ago | (#23592485)

'Samba isn't Windows, this isn't a Windows vulnerability. Thanks for playing. Try again."

That's probably why this article gets a tiny little mention on the front page instead of a full page blasting like a Windows vulnerability would.

Re:Samba isn't Windows (1)

mrbluze (1034940) | more than 6 years ago | (#23592659)

Samba isn't Windows, this isn't a Windows vulnerability. Thanks for playing. Try again.

Whew, for a minute there I thought Windows MIGHT have a vulnerability for once.

"Thanks for playing. Try again."

You won't make friends by belittling people.

Re:More M$ Vulnerabilities (1)

TheCabal (215908) | more than 6 years ago | (#23591433)

Samba != Windows

FAIL

Re:More M$ Vulnerabilities (1)

tomhudson (43916) | more than 6 years ago | (#23595807)

Samba != Windows

In my neck of the woods, it is. The linux desktops are configured NOT to have any publicly-shared directories. Want to transfer a file over the lan? Use ftp like __DIETY__ intended!

Re:More M$ Vulnerabilities (2, Funny)

nog_lorp (896553) | more than 6 years ago | (#23596331)

http://smithii.com/samba [smithii.com] .

buffer overrun .. (2, Interesting)

rs232 (849320) | more than 6 years ago | (#23591175)

"Boundary failure when parsing SMB responses can result in a buffer overrun [samba.org] "

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 .. (5, Informative)

kvezach (1199717) | more than 6 years ago | (#23591381)

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

Anonymous Coward | more than 6 years ago | (#23592895)

Through there would be no general defense from a dedicated attacker who is actively trying to exploit your system, there are some practical defenses to the most common form of this kind of attack (gcc -fstack-protector-all):
http://en.wikipedia.org/wiki/Stack-smashing_protection [wikipedia.org]

The article describes it fairly well. If someone determined your "canary" the attack could still be made to work. Nonetheless, a remote attacker may have significant trouble learning of this. This mechanism still leaves the software vulnerable to DoS, but it would prevent malicious code execution. Of course, this means that either the vendor/provider compiles the code in this way or that you do.

Re:buffer overrun .. (1)

Besna (1175279) | more than 6 years ago | (#23591393)

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

how about this .. (3, Interesting)

rs232 (849320) | more than 6 years ago | (#23591615)

"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 [uiuc.edu] , dangling pointers, and other memory error vulnerabilities"

Re:buffer overrun .. (2, Interesting)

Anonymous Coward | more than 6 years ago | (#23591543)

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 .. (4, Funny)

kestasjk (933987) | more than 6 years ago | (#23592011)

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

Anonymous Coward | more than 6 years ago | (#23592715)

yes its called EP, Execute Protection. Memory flagged as DATA will not and cannot be executed in hardware. Period.

Re:buffer overrun .. (1, Funny)

Anonymous Coward | more than 6 years ago | (#23593319)

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

Re:buffer overrun .. (2, Interesting)

owlstead (636356) | more than 6 years ago | (#23593985)

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

what manages the managed code ? .. (1)

rs232 (849320) | more than 6 years ago | (#23601575)

"Yes, it's called managed code (Java/.NET)"

Another software solution, which also begs the question, what protects the 'managed code' bits from getting buffer overruns and wouldn't it be simpler to do it in the hardware? Of course the 'managed code' bits are only good in so far as they manage to detect malware all the time. Wouldn't it be simpler to make the kernel immune to these type of bugs as in the SAFECode project. That way when a process fails on garbage collection hooks, exception handling, type safety, array bounds and index checking [msdn.com] , nothing happens.

I remember when there was only two kinds of ones and noughts, code and data and as long as you didn't download and run someone elses code you were totally safe. Another question to raise, and I realize I am crying in the wilderness [bible.cc] here, is there any other way of achieving Web 2 type functionality without sacrificing security. Like, the current security debacle was caused by bad design decisions made years ago, something that is going to cost and is still not fixed, if at all fixable given the current state of 'innovation'.

Re:buffer overrun .. (1)

ultranova (717540) | more than 6 years ago | (#23601887)

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: Java, for example, assuming that the JVM itself doesn't have any bugs. Let the flamefest begin.

Please note, however, that any sufficiently complex protocol can be considered a programming language in itself, and the program using it a virtual machine; and it is impossible to guarantee that the interpreter can't be put into an incorrect state with sufficiently corrupt inputs.

Re:buffer overrun .. (1)

jonadab (583620) | more than 6 years ago | (#23627327)

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

I don't know about "immune" in the absolute sense, but there are certainly things you can do. Writing everything (_everything_, including low-level system libraries) in a very-high-level language that dynamically resizes/reallocates buffers as necessary (e.g., integers automatically promote to bigints if they overflow, writing past the end of a string causes a longer string buffer to be allocated automatically, and so on) would help, but of course that has performance implications. It's less absurd to contemplate that now than it would have been twenty years ago, but it would still mean everything would have to be written that way from the ground up, and legacy code could only be run via virtualization and would not receive the same kind of protection. Taint checking is even better, but again you're now talking about writing everything in a VHLL, so performance is going to be an issue.

Address randomization and NX also help. Not as much as the aforementioned technologies, but OTOH they also have rather less impact on performance.

Tradeoffs. Security is all about tradeoffs.

smb/nmb filtered by default preventing this (3, Informative)

Danny Rathjens (8471) | more than 6 years ago | (#23591603)

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.

Re:smb/nmb filtered by default preventing this (1)

jawtheshark (198669) | more than 6 years ago | (#23592973)

Actually, I'm not on a corporate network and I block every port except the few I really use. That should be the golden standard. At my current client, I just said, "Hey I need port 22 open please". I got it withing 2 minutes and you do know what that means, don't you?

I am frankly more paranoid on my personal network that any network I've been on professionally.

CIFS (0, Offtopic)

FunkyELF (609131) | more than 6 years ago | (#23591717)

I noticed recently that Samba was deprecated in the kernel and that you're supposed to use CIFS. But this is for mounting...what about the servers. Is there a CIFS server for Linux...I know there is one for Solaris.

Re:CIFS (4, Informative)

profplump (309017) | more than 6 years ago | (#23591947)

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 (3, Informative)

Hatta (162192) | more than 6 years ago | (#23591991)

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

This is why we have SELinux (5, Informative)

FranTaylor (164577) | more than 6 years ago | (#23591753)

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

Re:This is why we have SELinux (0)

pembo13 (770295) | more than 6 years ago | (#23594713)

Except for those admins too lazy to make sure SELinux us working.

Re:This is why we have SELinux (1)

RiotingPacifist (1228016) | more than 6 years ago | (#23595707)

or PAX lets not forget about poor little pax.

Re:This is why we have SELinux (1)

timbo234 (833667) | more than 6 years ago | (#23597955)

Except for those admins too lazy to make sure SELinux us working.

Should read "except for anyone who's deliberately hacked their samba configuration to run as root". Considering there's no need to do this, and all distros package samba to create and run as it's own unprivileged uid, this will be pretty much nobody. And anyone who has done that has only themselves to blame.

Re:This is why we have SELinux (1)

timbo234 (833667) | more than 6 years ago | (#23598035)

Oh shit, sorry didn't check before I posted. Seems samba does actually run as root. Anyone know why this is?

Re:This is why we have SELinux (1)

Dog-Cow (21281) | more than 6 years ago | (#23599753)

When you connect as a Unix user, samba will spawn a process that runs as that user. The root process still needs to run as root to be able to do this. All daemons which must assume other EUIDs work this way.

Samba will spawn a process that runs as a configured (by default: nobody) user when the connecting user isn't a local (or NIS, ldap, etc) account. Again, it needs to start off as root in order to do this.

Re:This is why we have SELinux (1)

ultranova (717540) | more than 6 years ago | (#23604199)

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

Unless, of course, someone was so careless as to let a server who's purpose is to grant remote access to the filesystem actually access the filesystem it is supposed to grant access to :).

There is no way to detect the difference between an evil program overwriting an important file with random garbage and a saintly user editing that same file to contain extremely relevant data. Consequently, SELinux doesn't help at all here. Samba simply has too wide a function to effectively restrict it and still let it do its work.

Unless, of course, you have a policy to deny all actions for programs with the evil bit set ;).

The last major Samba vulnerability... (1)

rwa2 (4391) | more than 6 years ago | (#23594903)

... drove me to switch from Redhat 4 to Debian while cleaning up from a remote root compromise. Granted, it was pretty entertaining discovering the rootkit and tracing it back through a few other compromised servers.

Anyway, hoping I won't be driven from Debian to, uh, Gentoo or something.

Re:The last major Samba vulnerability... (3, Informative)

Jeremy Allison - Sam (8157) | more than 6 years ago | (#23595993)

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.

MOD PARENT UP (0)

Anonymous Coward | more than 6 years ago | (#23600977)

MOD PARENT UP, it's a post by Jeremy himself [wikipedia.org]

Samba's travails (1)

Rambo Tribble (1273454) | more than 6 years ago | (#23599833)

All I can say is that the Samba team is going to have to roll in more vulnerabilities than this if they want to really mimic Microsoft. C'mon guys, are you even trying?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>