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"

Re:CVE-2008-1105

[Anonymous Coward]

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

[Besna]

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

Oh jeez

[blackjackshellac]

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

<snark/>

Re:Oh jeez

[Thelasko]

exactly what I was thinking.

Re:Oh jeez

[Bogtha]

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

Re:Oh jeez

[Gazzonyx]

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

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

[fluch]

The usual 127.0.0.1. What did you think?

Re:Oh jeez

[Anonymous Coward]

Hah! I've got you now, you idi

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

Re:Oh jeez

[Carnildo]

192.168.0.4 and 192.168.17.26

Re:Oh jeez

[Anonymous Coward]

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

[blackjackshellac]

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

Fscking ACs.

Guess we'll see Apple release 2008-004 soon

[argent]

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

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?

Re:Already Patched

[shamer]

Gentoo is patched as well.

net-fs/samba-3.0.28a-r1

Vulnerability? And how!

[Applekid]

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

Re:Vulnerability? And how!

[kellyb9]

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!

[Applekid]

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!

[Anonymous Coward]

offtopic is what I use.

Re:Vulnerability? And how!

[Mr. Jaggers]

I use judicious quantities of "Overrated".

It's my most favorite-est mod ever.

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

[Besna]

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

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

[Anonymous Coward]

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

Re:buffer overrun ..

[Anonymous Coward]

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

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

[Anonymous Coward]

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

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

Re:buffer overrun ..

[ultranova]

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

[jonadab]

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

Samba isn't Windows

[JSBiff]

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

Re:Samba isn't Windows

[night_flyer]

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

Re:Samba isn't Windows

[rs232]

"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

[plague3106]

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

[Gewalt]

Whoosh!

Re:Samba isn't Windows

[Anonymous Coward]

'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

[mrbluze]

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

[TheCabal]

Samba != Windows

FAIL

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.

Re:smb/nmb filtered by default preventing this

[jawtheshark]

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.

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"

CIFS

[FunkyELF]

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

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

This is why we have SELinux

[FranTaylor]

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

Re:This is why we have SELinux

[pembo13]

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

Re:This is why we have SELinux

[RiotingPacifist]

or PAX lets not forget about poor little pax.

Re:This is why we have SELinux

[timbo234]

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

[timbo234]

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

[Dog-Cow]

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

[ultranova]

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

What's that saying, about security and obscurity?

[Anonymous Coward]

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?

The last major Samba vulnerability...

[rwa2]

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

[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

[tomhudson]

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

[nog_lorp]

http://smithii.com/samba.

Samba's travails

[Rambo Tribble]

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?

MOD PARENT UP

[Anonymous Coward]

MOD PARENT UP, it's a post by Jeremy himself

what manages the managed code ? ..

[rs232]

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