Local Root Exploit in Linux 2.4 and 2.6

Anonymous Coattails writes "Summary from the advisory: 'Locally exploitable flaws have been found in the Linux binary format loaders' uselib() functions that allow local users to gain root privileges.'"

Comments

*sits back*

[Anonymous Coward]

*awaits justifications and explanations of why this is nothing like Microsoft*

Re:*sits back*

[ackthpt]

*awaits justifications and explanations of why this is nothing like Microsoft*

Because in this case Linus Torvalds is our new overlord, and I for one, welcome him.

Re:*sits back*

[BobPaul]

Well, it's only a local exploit for one thing, so good like getting rampant Blaster style viruses based on it..

Second, it'll probably be patched rather quickly.

Third, it's one of a few holes, compared to the one of many holes found in windows...

Re:*sits back*

[Anonymous Coward]

Second, it'll probably be patched rather quickly.

I can only laugh out loud. Read this story for example.

Re:*sits back*

[huge colin]

Because they effect Linux at a rate several orders of magnitude lower?

Re:*sits back*

[Lodragandraoidh]

"We are sorry, all circuits are busy..." - Microsloth Help Desk

"You can download the fix

• here

..." - Any Linux website within a days (perhaps hours) of the report.

Re:*sits back*

[Neil Blender]

Ask and you 'll receive:
as said another poster before, it's _locally_ exploitable. But you know, physical access to a machine is not far from having all privileges.
You can log on as root without knowing the password.

Anyway I agree it's a bug. But not exactly the same sort.

Tell that to the brute force attacks happening against my one box that is open to ssh every fucking night. (and every night is from a different IP address) Oh wait, don't tell me, tell someone with weak passwords, like a stupid ISP.

Re:*sits back*

[CypherOz]

Yup! This IS NOTHING LIKE M$ (Proprietory Closed Software)...

1. Problem is published (often not at all for PCSW)
2. Problem is published in a timely fashion (like thats happens with PCSW)
3. Fix is published in a timely fashion, your fav distro has online updates, or you can fix it yourself (Cant do that with PCSW)

As a result the opportunity to exploit the problem is orders of magnitude lower than with PCSW
It is not M$ bashing, it is bashing PCSW model that is important. M$ have chosen a PCSW product oriented business model. The long term future is open service based business models. Even IBM (remember the 70's anti trust - I was there) now derive about 60% of their revenue from services and have started supporting FOSS and opening products (eg. Eclipse, Cloudscape).

Re:*sits back*

[sowdog81]

Because they informed you about the problem and what to do about it?

Re:*sits back*

[andalay]

at poolsize_strategy():
> int len;
^ signed integer
>
> sysctl_poolsize = random_state->poolinfo.POOLBYTES;
>
> /*
>
> /*
> * We only handle the write case, since the read case gets
> * handled by the default handler (and we don't care if the
> * write case happens twice; it's harmless).
> */
> if (newval && newlen) {
> len = newlen;
^ unsigned int converted to signed
> if (len > table->maxlen)
^ comparison of two signed integers
> len = table->maxlen;
> if (copy_from_user(table->data, newval, len))
^ copy_from_user with len possibly > table->maxlen

Is it just me or does newlen > max_signed_int mean len < 0

If so, that would be interesting.

Re:*sits back*

[jacksonj04]

I was awaiting the torrent of "Oh no, another security bug! What is the world coming to?" which usually accompanies any bug article around here.

Oh sorry, forgot that any Linux bug can be explained away with a link and a brief summary whereas any bug in Windows must be ripped apart and Microsoft beaten again.

Re:*sits back*

[spac3manspiff]

or you could RTFA and look at the code.

Were you able to see the copious flaws in windows?

Re:*sits back*

[CanadianCrackPot]

*awaits justifications and explanations of why this is nothing like Microsoft*

Because this was released to the public immediately, will be fixed in a matter of hours and available for patching in the same amount of time. Also this is a LOCAL exploit meaning you have to gain physical access to the machine, or trick a linux user who is usually an informed user to run something with this exploit. Using this exploit is much harder than with M$ which left gaping holes open in the past.

Re:*sits back*

[Jay Carlson]

It's quite a bit like Microsoft in one way.

The uselib() system call is quite old. It was introduced in Linux 0.12 as a quick way to support dynamically loaded, statically linked libraries.

The way shared libraries worked was like this:

libc was compiled and linked like a normal program would be, except that its start address was set to (say) 0x400b0000. printf() would be at (say) 0x400cb110.

Main programs were linked down at 0x08048000 or so, and knew where in memory printf was. The kernel knew how to load your main program and jump to its start. However, there was nothing but a segfault waiting for you at 0x400cb110 initially. So how did the kernel know what shared libraries to load?

Well, one possibility was to put a list of library paths into the executable and teach the kernel to load 'em. Ugh. Didn't SCO do that?

Instead, the linker would add a little assembly language stub to start your main program. It looked a little like:

uselib("/lib/libc.2.so")
uselib("/lib/libm.2.so")

and the uselib syscall would graft the contents of those files directly into memory, in the same fashion the kernel knew how to load the main program. Voila, calling printf at 0x400cb110 will now work.

Eventually, this switched to a single uselib("/lib/ld.so") so we could have search paths and dynamic linking. But it was a pretty good start.

After we all switched to ELF, uselib wasn't such a good idea, as ELF allows some more clever things than just direct-mapping the whole executable at a fixed address. /lib/ld-linux.so switched to using mmap(). If you haven't run an a.out or libc5 executable, it is extremely unlikely your machine has ever invoked this syscall.

As part of the a.out->ELF transition, the uselib() syscall was preserved. It allowed old-style fixed location libraries to be dressed up in new ELF clothing. A few years ago I tried uselib() on MIPS, and had a miserable time trying to get GNU ld to make a library the kernel didn't reject. I gave up.

So how is this bug like Microsoft? The bug is in a mechanism that is a holdover from an older, simpler time. Nobody saw a good reason to take it out. And it didn't get much security scrutiny until somebody said, "hey, what's THAT still doing in my OS? I bet it's got bugs!"

Re:*sits back*

[skinfitz]

Well, it's only a local exploit for one thing, so good like getting rampant Blaster style viruses based on it..

You neglect to take into account the fundamental differences between Windows and Linux. For starters, one is very much more likely to have remote shell access to Linux systems than Windows, as Windows effectively has no remote shell (Yes, I know about Windows 2000 telnet service, which nobody uses) and if it did, what would average users do with it? Windows needs it's GUI to be most effective. Many Linux systems at a school say, may give shell access by default to users with accounts on the system.

Second is the fact this code could feasibly be combined with other remote exploits to result in a remote root.

This is a serious exploit. And I have to agree with the parent - if this were for Windows Servers, the sky would be falling on /.

Re:*sits back*

[Neil Blender]

Also this is a LOCAL exploit meaning you have to gain physical access to the machine

Local means user shell access, not physical access.

Re:*sits back*

[ip_fired]

* When you copy newlen into len, this could cause len to be negative if newlen truly is an unsigned int.

* It all depends what copy_from_user does. Does it check to make sure that len is sane? Is it an unsigned int, or a signed int. If it's signed, then a negative value is obviously not sane and should be rejected.

Where did this code come from? What file please?

Re:*sits back*

[snero3]

I would have thought that answer was simple as obvious, in that

• they told you there was a problem as soon as it is was pointed out
• Linus didn't try to sue the person/s that found out there was a problem
• You can track down the bug in the source yourself and fix it

do I really need to go on or do you get the picture now?

Re:*sits back*

[legirons]

"Second, it'll probably be patched rather quickly."

(a) "probably"? That would be "still unpatched!!!" in Windows parlance...

(b) we don't expect to have to patch kernels - they're expected to be reliable

(c) even if fixed immediately, it will have been

"it's one of a few holes, compared to the one of many holes found in windows..."

How many holes do you need to breach security? Just the one.

"good like getting rampant Blaster style viruses based on it.."

I don't think virus-writers need any more good luck... But local root vulnerability means they can only compromise a few tens of thousands of people at a time (for example university shell accounts) rather than the whole internet (which would need a remote vulnerability.

Re:*sits back*

[zerblat]

Ah, but that's the nice thing about Windows, you don't even have to install a telnet server (or some other remote execution server) to be able to run processes remotely -- have a look at psexec. Extremely handy.

Re:*sits back*

[gbjbaanb]

# they told you there was a problem as soon as it is was pointed out
Yikes. I'd hope they waited until there was a patch available, and practically everybody and his dog had run their up2date, yum, yast, or whatever update program.

# Linus didn't try to sue the person/s that found out there was a problem
Good for him. I don't think Bill Gates ever sued anyone for bugs either. Microsoft the corporation, however... I suppose RedHat hasn't (yet) sued anyone for trying to hack 'their' distro, or IBM, or Novell. Perhaps it'd take a bug to be disclised, then used against a high-profile site (imagine Munich getting hacked. Will IBM's lawyers think once, let alone twice, in suing the reporter for not acting more 'responsibly' by letting them know so they can get a fix in place first?)

# You can track down the bug in the source yourself and fix it
Yah.. right. what if you got it wrong? A badly written fix could be as bad as the original exploit, or worse! You're going to test it too? You're a C-coding security expert? Like the guys who've made the current patch, who were the ones who accidentally let the bug slip through in the first place. No-one's perfect all the time remember.

So, yes, I still really need to get the picture.

Linux isn't a magic bullet against security flaws. Windows isn't an open invitation for hackers. Get the picture yourself? That all this ignorant 'my OS is better than yours, cos it is' posturing is just adolescent bull.

Re:*sits back*

[identity0]

I was going to make a comment about "rounding up workers for underground C mines", but I figured that didn't sound painful enough.

So, I would like to remind Linus that I will be very useful in rounding up workers to toil in the underground Perl mines.

Re:*sits back*

[Cecil]

*awaits justifications and explanations of why this is nothing like Microsoft*

Ok, here you go.

This is: "Oh no, my little brother in his restricted account could gain access to the administrator account"

Microsoft is: "Oh no, some hax0r in Brazil with no account could gain access to the administrator account"

Re:*sits back*

[Vicegrip]

The truth never bothered astroturfing trolls and their friends.

Re:*sits back*

[emseabrown]

as Windows effectively has no remote shell

Wrong. Windows XP offers both Remote Desktop and Remote Assistance.

Windows needs it's GUI to be most effective

Wrong again, WMIC. Which you can find more information about here http://www.microsoft.com/resources/documentation/w indows/xp/all/proddocs/en-us/wmic_overview.mspx

The fundamental difference between linux and windows is FUNDAMENTALS, and not related to how one accesses the fundamentals.

the above line I just wrote makes less sense every time I read it so I think I'll just hit submit now

Re:*sits back*

[andalay]

Its from the article linked in the parents post.

Re:*sits back*

[Rob.Fussell]

** I don't think virus-writers need any more good luck... But local root vulnerability means they can only compromise a few tens of thousands of people at a time (for example university shell accounts) rather than the whole internet (which would need a remote vulnerability. **

I don't think you understand Local Vulnerabities, local vulnerability doesn't mean they can gain access to a "local account" it means they REQUIRE one. For example. if you are at a University and you have a shell account, you personally can exploit this and gain root on the machine your accounts exists for. This does not mean you can get access to your buddies account on some box with the exploitable kernel just because he has a "local shell" not without actually gaining access to a shell can this be exploited.

robf();

Re:*sits back*

[CurlyG]

Wow - that does look amazingly handy. Do you happen to know if there's something similar for Linux and other OS's (i.e., something I can run from my Linux workstation to execute remote processes on the Windows servers that I admin)?

Re:*sits back*

[skinfitz]

I use psexec (and the other excellent pstools) a lot and this question has come up before - Sysinternals give away the source, and they would be wonderful to have on Linux, but I've yet to see them ported.

Re:*sits back*

[gmuslera]

One word: "LOCAL"

The concept of local security is usually ignored in the MS side, that someone already using the machine could access/modify things that he should not.

Most Microsoft related advisories/reports are centered in remote vulnerabilities, things that only have a meaning for a network connected machine accessing services or being accessed from outside.

Of course, a local vulnerability could be exploited if some piece of software (i.e. a web app) have an entry point, and what should be running with the low apache priviledges or in a chroot jail becomes a systemwide security problem.

Re:*sits back*

[EvilAlien]

Compare apples to apples unless you are also willing to count vulnerabilities in all the GNU stuff, other opensource apps included in major distros, etc. There are far more vulnerabilities announced on a frequent basis for Open Source due to its strength: transparency. The actual numbers of vulnerabilities/flaws in Microsoft's closed source code is unknown until a vulnerability is detected and announced. Open Source also has the potential of a vulnerability coinciding with a patch since those who detect can also fix due to the openness of the code... Microsoft relies on "responsible disclosure" to ensure that they are able to release fixes with vulnerability announcements. Closed source means that announcements can be scheduled and planned for monthly "patch day"... open source means that a vulnerability and maybe the fix can be announced at any time, and therefore with greater frequency.

So, as far as the number of vulnerabilities, you can't convince me (as someone in the industry) that Linux "wins". You also can't convince me that the Linux kernel has far fewer holes found than the Windows kernel. The available evidence does not support the claim. However, that doesn't mean that the Open Source development method tends towards greater potential quality than the closed source method.

Also, remember that a local root vuln is only 1 remote non-root vuln away from becoming effectively a root vulnerability. Too many people who think they are responsible admins try to ignore or downplay the seriousness of local root vulnerabilities.

Thats enough rambling for the day...

Re:*sits back*

[displaced80]

Hehe :-)

Nah, but seriously...

My answer's this little thought experiment:

Imagine there is no Windows yet, and there is no Linux either. You're sat in a bar with two guys called Bill and Linus. Bill looks kinda nervous, and Linus has an accent you can't quite place. But that's not important right now. All three of you know enough about programming practices and software design to be able to hold a decent conversation about it.

So anyway, after a few pints of beer, Linus and Bill go on to describe these great plans they have for an operating system. Linus proceeds to describe what we know as a modern Linux distro, and Bill goes into a load of detail about this thing he's planning on calling 'Windows', and describes the architecture of what we'd recognise as Windows 2000 or XP.

Now, whose ideas would sound better to you? Bill's or Linus's? I dunno about you, but I'd agree with Linus.

Sadly, RMS was unable to join the conversation. The doormen wouldn't let him into the bar in the first place. And Bill only bought drinks for himself.

I seem to have wandered OT... Apologies.

Re:*sits back*

[SilverspurG]

I'm a Linux zealot, I admit it.

But, well, no MS exploit is strictly a "remote root exploit" unless it's a local process running with admin privs.

So... take this exploit along with any known exploit (say, libXpm or libtiff) on a user's web browser and you have a remote root exploit.

Re:*sits back*

[ArbitraryConstant]

Because it's broken as implemented instead of broken as designed (eg messaging interface that can give anything admin privs and can't be changed).

Re:*sits back*

[RWerp]

2.2 is not affected by the bug. If you're interested in rock stability, drop 2.4. Some people use 2.0 still.

Re:*sits back*

[Laur]

And dont forget, recompile the kernel!

Then run a different distribution. On Debian a new kernel is just an apt-get away, no compiling required (unless you need something special of course). I'm sure other distros are similar.

Re:*sits back*

[Allnighterking]

For one thing it works. For another we admit it. For a third we don't have to lie about it.

Oh yeah. I've never yet seen a local exploit on Windows. This is true. The number one exploit from Console on Windows is usually turning on the box. Once I do that I really don't care what you've done. I own you and I'm root (Yes even with WinXP SP2 and the supposed user password protection.)

Note too to be fair. ANY box where I am at the console I don't need fancy exploits and code to grab root etc. Once I've sat down in front of the keyboard .... it's mine. Period.

Re:*sits back*

[iabervon]

Is Windows XP even intended to be secure against a legitimate user of the system who hasn't been granted Administrator access? (I actually don't know; I haven't encountered a system set up for this, but I haven't used a system where it would make sense for the intended function)

(Conversely, I have seen only a few Linux machines set up to have remote users who can run arbitrary code as themselves but who don't have root access, but all of the Linux machines I've seen are designed to be secure against such users. It does mean that an attacker who compromises an unpriviledged service can't cause quite so much damage so easily, but most of these machines don't have unpriviledged services which actually belong, either. The real benefit is that an attacker who tricks a user into executing some code is less likely to be able to compromise the system such that it can't be safely cleaned up with legitimate root access.)

Re:*sits back*

[jgrahn]

Ah, but that's the nice thing about Windows, you don't even have to install a telnet server (or some other remote execution server) to be able to run processes remotely -- have a look at psexec.

Oh, yes, that's what the link claims. But of course there's a remote execution server involved. Just like on any other OS, something must be sitting around waiting for the client and letting it in.

The thing that is special for Window in this case seems to be that it isn't ssh, and I'm not sure that's something to be pleased with.

Re:*sits back*

[darc]

Yeah yeah, that's the responsible thing to say. But responsible stuff is sooooooooo boring. I mean, if we were all responsible people that wanted stability, we'd all be running kernel 2.2, Apache 1.1, many year old revisions of programs patched to all heck, never install any packages that aren't yet at least of legal age, and still tout ISA support as a bleeding edge feature.

Hmm. Wait, I think I just described Debian Stable.

*is hit by a gigantic potato from the debian crowd*

(Yes, I am aware that stable is called Woody, and the last version was called Potato. But if I said "is hit by a gigantic woody..." i'd probably get murdered. Oops.)

Re:*sits back*

[Rakarra]

I don't think you understand Local Vulnerabities, local vulnerability doesn't mean they can gain access to a "local account" it means they REQUIRE one.

If one user compromises the system, then all users should be considered compromised. He mentioned university shell access because it's an example of a many-user system still used today where one has an account on the box but the box doesn't belong to him.

Re:*sits back*

[EnronHaliburton2004]

Because in this case Linus Torvalds is our new overlord, and I for one, welcome him.

Dude, he was our new overlord like 10 years ago, get with the program...

Re:*sits back*

[daddymac]

If you have physical access to the machine, there's no reason to exploit it. Best case scenario you edit 1 line in the grub conf anf get root. worst case scenario you steal the hard drives and mount them in your box at home.

Re:*sits back*

[FuzzyBad-Mofo]

Mainly because this is a proactive announcement -- Microsoft does not release security flaw details to the public until they have a patch ready, and/or the issue is actually being exploited. And, since no one else has access to their source, so they might (and probably do) discover flaws like this in their kernel all the time, but no one outside of Redmond would ever know.

Re:*sits back*

[kneeless]

You also can't convince me that the Linux kernel has far fewer holes found than the Windows kernel.

I don't believe it does either. If you really want a secure system, you wouldn't use Linux or Windows, but BSD. I consider Linux more secure than Windows because of its obscurity to viruses and spyware. Ironically enough, it is almost security by obscurity in reverse.

Microsoft relies on "responsible disclosure" to ensure that they are able to release fixes with vulnerability announcements.

Which rarely happens. I know if I found a Windows vulneribility the first place that would find out would be Bugtraq, and then maybe a week later I'd send it to Microsoft. But even if I did give it to Microsoft, people have reported that they don't get back to them, they don't even know if anyone has seen the message. Doesn't sound very encouraging to those vuln. finders. And hey, we've already got a patch for that vuln, a Windows equivilant might have taken months.

Re:*sits back*

[Bitsy Boffin]

Except that by local user exploit they mean that it requires a user account, not that you have to be phsyically at the machine.

There are many ways to get access to a user account through for example holes in a dynamic web site (PHP etc), once you'v got that you're half way to root.

Yes, this is a serious bug, but it will be fixed in a relativly short time. I imagine that would be true if this had been Microsoft as well, although thier definition of "short time" may be somewhat longer than we would want.

Re:*sits back*

[displaced80]

I guess I was trying to think about looking at the differences between Linux and Windows behind a veil of ignorance -- with no knowledge of how these two approaches would actually turn out in real life, no idea that one would end up a monopoly, or even any real detail on how these implementations would actually work out for the user.

My hypothetical Bill & Linus would talk about nothing more than the structure or architecture of their approaches. We, as the (again, hypothetical) knowledgable but independent participant get to think about which we like best.

I'd expect that we'd be able to pick apart Bill's plan much more than Linus's. Sure, IRL, neither guy had it all mapped out from the start. But in this imaginary world, they're describing Windows and Linux as they exist now, even though neither OS exists yet in this alternatice reality.

Isn't Bill's title 'Chief Software Architect' these days? I'd love to witness him and Linus discussing the finer points of OS design over a few beers. From what I (possibly mis-) understand about Bill's role in things, I'd imagine Linus could out-geek Bill any day of the week... so maybe Bill could be replaced by whoever is the OS uberfuhrer at MS.

Hell, let's throw Avie Tevanian in there too...

Re:*sits back*

[vsprintf]

I'm sure you meant to say, "While Bill learned about good user interfaces as developed by Xerox and others since the user interface is going to become so important to the future of desktop computing. On the other hand, Linus was busy plagarizing algorithms from an OS developed over 20 years before without a care at all as to how users might actually interact with the the thing."

Um, no. What I meant to say was that Bill profited by ripping off ideas (and code) while decrying that other computer users did the same. Linus, OTOH, was creating a UNIX look-alike OS understood by many, that worked on x86 hardware. If you can, in your mighty AC stature, provide proof of Linus or Linux "plagarizing", I'm sure you have a ready audience here. Spit it out, clown.

Re:*sits back*

[rpdillon]

Not to take the bait, but...

In all honesty, if someone has physical access to the box and wanted to exploit it, they could, no matter what it's running. So, while interesting, local exploits are no big deal. As the saying goes: "If your enemy has physical access to your hardware, you've already lost."

Oh, and whay is this different than MS? Because all their exploits are REMOTE.

News flash:
Local exploit to gain root: a knoppix CD.

Re:*sits back*

[penguinoid]

*awaits justifications and explanations of why this is nothing like Microsoft*

Quick fix:
This is a non-issue -- the whole root exploit thingie can be avoided by running everything as root. Poof, root exploits are rendered totally harmless.

Re:*sits back*

[fimbulvetr]

man grep

Re:*sits back*

[Minna Kirai]

(unless you need something special of course)

Where "something special" includes such oddities as support for 10-year-old PCI Ethernet cards...

Re:*sits back*

[HiThere]

OpenBSD has a remarkably good record. All the BSDs do. And I'm using Linux anyway.

Linux has thus far been "safe enough" (i.e., I've never been cracked, that I've ever found out [can't prove it's never happened, but neither can anyone else]). OTOH, Linux has had more vulnerabilities discovered than any of the BSDs. Most of them were only local user escalation of priviledge...ugh, and dangerous, but not immediately dangerous. And I haven't gotten tagged.

Also, when something does happen, I patch things quickly. This plus the difficulty a Linux problem has in spreading generally keep things pretty safe. (I'm not about to remove my floppy or CD to make things safer, even though that would prevent some kinds of exploit.)

But if you cared enough about security, you'd be running either a BSD or SELinux. And you wouldn't be hooked up to the net.

Re:*sits back*

[s4nt]

what? i dont like that shit...
i REALLY enjoy to recomplile my kernel

Re:*sits back*

[mikiN]

...10-year-old PCI Ethernet cards...

...perhaps leaking your deepest secrets for others to sniff (i.e. padding short packets with old data)?
Better watch out! :-)

--This tip was brought to you by: a (small) angel whispering in my ear...

Re:*sits back*

[grcumb]

"So, I would like to remind Linus that I will be very useful in rounding up workers to toil in the underground Perl mines."

Actually, they're perl divers.

And before you say, 'Oh, that okay then,' I'd recommend you consider what they're swimming in. 8^)

Re:*sits back*

[sacredchao]

Oh nothing so radical. The threads just immediately turned to discussing Windows exploits instead. It soothes the pain, you see.

Re:*sits back*

[VertigoAce]

In this case, local means you are logged in as a user already. It does not mean you are physically at the machine. This kind of exploit is why Remote User Exploits are actually a serious issue even though they might not give you root access directly. All you have to do is combine an exploit that gives you user-level permissions with a Local Root Exploit to get root access.

Re:*sits back*

[gweihir]

*awaits justifications and explanations of why this is nothing like Microsoft*

This is a local exploit. These are so common in Windows that nobody talks about them anymore. Most reported Windows exploits are remote exploits (exploitable over the net) or application exploits, e.g. in the bundledbrowser or Email apps.

Really no comparison at all

Re:*sits back*

[skinfitz]

as Windows effectively has no remote shell

Wrong. Windows XP offers both Remote Desktop and Remote Assistance.

...and just how are these classed as shells exactly? Have you even used Linux? (Do you even know what a shell is??)

Windows needs it's GUI to be most effective

Wrong again, WMIC.

Ah where to even begin with this one. Firstly you just said I was "wrong" in saying that windows effectively has no remote shell, then claim that a GUI is a shell(?!) and now you are claiming that I am "wrong" for stating the FACT (hint) that Windows needs it's GUI to be most effective? I suppose people are going to be using the special undocumented WMI access to Word or Solitaire now are they? Hello! For me to be "wrong" here means that "Windows machines are most effective from remote access to WMI". Hmm. Good luck attempting to argue that point anywhere.

The fundamental difference between linux and windows is FUNDAMENTALS, and not related to how one accesses the fundamentals.

That makes absolutely no sense.

Re:*sits back*

[sl4shd0rk]

> *awaits justifications and explanations of why this is nothing like Microsoft*

*sigh*... People that choose to cover themselves in shit are the first ones to point when your thumb gets stuck up your ass.

There is a difference between "Mistakes" and "Flagrant Disregard". Figure out which one applies.

Re:*sits back*

[DrSkwid]

"shell" is nothing special for defining the kind of access

it doesn't mean "command line access"

go look up "graphical shell"

http://www.google.co.uk/search?q=graphical+shell

Re:*sits back*

[afd8856]

explorer.exe is considered the shell for windows. It provides manipulation of the file system and launching other software. Even if it doesn't have a command line, it's a shell.

Re:*sits back*

[Tim C]

The actual numbers of vulnerabilities/flaws in Microsoft's closed source code is unknown until a vulnerability is detected and announced.

But that's true of *any* software, including open source stuff - even with the code, the number of vulnerabilities is unknown until and unless you can *prove* that you've found them all. You may fail to find any not because there are none, but because you lack sufficient skill and/or knowledge.

Re:*sits back*

[skinfitz]

...and this is related to quite clearly referring to a CLI with the phrase "remote shell" how exactly?

Semantics.

Re:*sits back*

[skinfitz]

Semantics.

Re:*sits back*

[Alsee]

Potato?? Woody??

Jeez. What the hell are they going to call the next release of Debian stable? Boner?

-

Re:*sits back*

[DrSkwid]

a remote shell doesn't necessarily mean a CLI

You can't get root running an X Server ?

or VNC ?

you wont get a CLI if you do this to root it either :

scp bad_code remote:bin/
ssh remote "chmod 755 ~/bin/bad_code && ~/bin/bad_code"

Re:*sits back*

[Abreu]

Im probably feeding a troll, but...

Debian releases are named after characters in Toy Story

Re:*sits back*

[m50d]

What about where they have alarms connected to the casing? Most systems are 0wned as soon as you have physical access, but in that case it's not so easy. Of course no alarm is perfect, but you'd have to be pretty good to know how to get around the alarm and how to use that to take control of the system.

Re:*sits back*

[m50d]

But combine it with a remote exploit that gives unpriviliged user access - such as the recent cups vulnerability if you haven't patched it - and you have your remote root.

Re:*sits back*

[m50d]

Yes, but the server is running there by default. Wheras every linux distro I've seen will only turn on ssh/telnet/etc if you ask it to.

Re:*sits back*

[m50d]

I'm willing to compare apples to apples, but if you want me to include the major apps installed on linux distros, you should also include lots of external software for windows - some of it third party, since there doesn't seem to be an MS alternative to (for example) the GIMP.

Re:*sits back*

[sgtrock]

Microsoft relies on "responsible disclosure" to ensure that they are able to release fixes with vulnerability announcements. Closed source means that announcements can be scheduled and planned for monthly "patch day"...

If only Microsoft did work this way. From eeye.com:

Windows VDM #UD Local Privilege Escalation

Release Date:
October 12, 2004

Date Reported:
March 18, 2004

Patch Development Time (In Days):

208

and

Windows Shell ZIP File Decompression DUNZIP32.DLL Buffer Overflow Vulnerability

Release Date:
October 12, 2004

Date Reported:
August 2, 2004

Patch Development Time (In Days):

71

and

Microsoft DCOM RPC Memory Leak

Release Date:
April 13, 2004

Date Reported:
September 10, 2003

Patch Development Time (In Days):

216

Three reports to Microsoft from one security vendor. Two of the three critical failures. And patch time is measured in months??????

Re:*sits back*

[skinfitz]

The phrase "remote shell" is colloquially taken to mean a remote CLI. Sure you can bend the definition to fit any form of remote access you want, but you will never hear anyone say "I have a remote shell using VNC / RDP / ICA. They will generally use the phrase Remote Desktop or perhaps even Remote Console.

Windows is generally NOT accessed by people using SSH or Telnet. Period. Yes, I know about the Windows 2000 telnet service (that nobody uses). Yes I know about Cygwin. THE AVERAGE USER DOES NOT ACCESS A WINDOWS SYSTEM IN THIS WAY WHICH WAS MY POINT.

Re:*sits back*

[rpdillon]

Well met...I was under the impression local meant local physical access.

I got it now, thanks.

Now, what's the address for that patch again? =)

Re:*sits back*

[grazzy]

Did you read my comment? The compiling is hardly a problem, its the rebooting buisness you see.

Besides, regardless of what f**king distro i run, exploits will happen. It's just buisness, sadly though.

Re:*sits back*

[Minna Kirai]

AC: Okay, run a descent package management system like Portage then

Package management is completely irrelevant to the capabilities (or lack thereof) in the distribution's default kernel. How exactly would portage fix a shortcoming in network driver support if it can't access the network to download source code?

Re:*sits back*

[drsmithy]

This is a local exploit. These are so common in Windows that nobody talks about them anymore.

So do you have a list of all these unpatched exploits allowing an unpriveleged user to elevate themselves to an Administrator (or higher) ?

Re:*sits back*

[gir_v_2]

Am I the only one who sees this as a reason to keep my roomate away from my comp and not worry about Gates invading my privacy?

Re:*sits back*

[grcumb]

You misunderstand me. I was saying that Perl is good, but is often found buried deep in, uh, gunk.

I wrote perl for a living for years. It's still my favourite language. You say above that it can practically be English. That's true, but the thing I like best about it is that it can practically be poetry, too. 8^)

Re:*sits back*

[DenDave]

Actually I find that most people who insist on compiling a kernel, whatever flavour they run, are overdoing it. I mean really, do you know more about the kernel than the RedHat Kernel team? I don't.. Not that compiling kernels is rocket science but I cannot find a good excuse for recompiling (for production machines) anyway!

I am more than happy to trust RedHat or SuSE for that matter on kernel binaries. As for this discussion about the kernel security, I am sure that there will be mroe issues. The only 100% secure system is one that is turned off and locked in a vault. And for the MS fans who are waving their fingers, enjoy, I for one consider this flaw to be limited in threat, it's rather obscure and will not exploitable on a majority of properly hardened servers. Go ahead and try it, it's actually a pig to make work and the unix user space must have all the goodies present for it to work. Anyone with a user account on my systems is rather locked down into a context rights management.. uh yeah they call that SELinux in kernel 2.6 ... so really this threat is very limited and obscure.

I am convinced that responsible vendors will:

1. Advise proper hardening of systems.
2. Advise enabling and implementing SELinux in 2.6 Kernels
3. Find and implement a solution to the flaw swiftly.

Re:*sits back*

[imroy]

Because even with an entire industry making virus scanners and now adware/spyware removers to cover over the holes in Windows, Linux still has a far better track record when it comes to security? The army of compromised Windows machines spewing out spam should be proof enough of that.

Re:*sits back*

[Equinox11]

There is a large difference between remotely exploitable security issues, and internally exploitable security issues(by internal I mean a local user existing on the box itself, by external I mean something like a FTP or Web user that has no shell access)

With the servers I operate a local exploit isn't really a big deal... Only myself and my staff have access to exploit it... Of course I'd rather they not exist but it just isn't the same as a hole in the web server where a worm can come in :)

Re:*sits back*

[Tassach]

but I cannot find a good excuse for recompiling (for production machines) anyway

I've got two:

1. Because you have hardware which isn't supported by the stock kernel.
2. Performance.

The SATA controller in one of my boxes flat out refuses to work with the stock RedHat kernel; the ONLY way I can get it to work is to compile a custom kernel. I'm sure this isn't a unique situation. The distros try to support the broadest range of hardware that they can, but sometimes you get in the situation where an option that's either needed or harmless on 99% of the machines out there breaks the other 1%.

The second reason to compile a custom kernel is for performance. A stock distro kernel is designed to support the widest range of hardware possible, so it makes a lot of compromises which might not be optimal for your environment. When you compile a custom kernel, you only need to compile in support for your actual hardware and only the features you actually use. Also, you can use a more aggressive set of compiler optimizations than the stock kernel uses.

Re:*sits back*

[mystran]

Actually, the consoles not enough, you need the box itself. And even then, while you can then have the hardware, you can't necessarily have the data. It's possible to encrypt everything after the bootloader, and if you need a password in the bootloader to decrypt the main decryption key used to decrypt rest of the system, you are pretty much back to password guessing.

Now, the only way you can hack into such a box is get unrestricted read access to physical memory without rebooting. That allows you to get the decryption key. If you reboot, then you need someone that knows the password (or one of them) to get the decryption key. Ofcourse your console should always be locked or in login prompt when you can't see it.

This is how you should protect a laptop. It's bad enough that somebody steals your laptop, but at least they can't get your data then.

Sure, you still can install a keyboard logger, modify the bootloader or something similar. But at this point it's not enough to have physical access anymore; you need to have physical access and THEN have someone use it. It might not be that hard, but at least you can't simply steal a box anymore.

Since local login applications aren't usually the easiest way to get a shell on a computer without knowing passwords, you probably have a better chance of simply using a remote exploit to get your shell, and then a local exploit to get r00t and whatever you might want to do.

Re:*sits back*

[DenDave]

Very true very true.. However, in a production environment I use machines that are supported by the vendor. I rarely require hardware that is not on RedHat's supported list. In fact with most hardware vendors I would prefer to order the machine pre-installed and stay within the supported framework. So again, no REAL excuse for recompiling...

Re:*sits back*

[DenDave]

oh yeah, I forgot to address the performance... Considering that the average production machine is running out of the box Enterprise 3, I really doubt that a recompile of the kernel would boost performance noticably. On a P3 450 with 128 MB running in your grandmas closet I agree that you will notice a difference. But to adress whether it is worthwhile? Not ! Considering your time as a cost and the 0.03% performance boost on serious systems... nope, sorry you haven't convinced me...

Re:*sits back*

[EvilAlien]

"But if you cared enough about security, you'd be running either a BSD or SELinux. And you wouldn't be hooked up to the net."

I am running OpenBSD and SELinux, and I don't connect to the internet directly without a highly hardened firewall in between. SELinux is much less of a rarity than most people think... install Fedora Core 3, turn on enforcement, and you have SELinux controls governing what commonly used services can do. For example, the desktop I'm using to post this comment uses SELinux enforcement.

Connecting a patched or unpatched Windows box directly to the net is irresponsible, negligent, and insane. Unfortunately, it is also typical of the big fat portion of the bell curve. And that, in a nutshell, is why we have such a horrible state of end-use security on the internet. Unpatched Windows 2000/XP boxes are thoroughly infected in 20-30 seconds at best. Microsoft even knows better... its PEBCAK.

Re:*sits back*

[fbjon]

Maybe, but that's how it's referred to in the Windows world: a shell. At least in Win 9x you could change it freely by editing the line shell=Explorer.exe in system.ini.

So I guess the question is...

[Anonymous Coward]

Does this exploit run Linux?

Copyright Poo Poo

[Anonymous Coward]

Read down to the Credits on the link and you see this line:

Credits:
========

Paul Starzetz has identified the vulnerability and
performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.

Did I violate you buy hitting ctrl-c and ctrl-v? Yeah copyrights stink even in free and open source realm. Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.

Re:Copyright Poo Poo

[Anonymous Coward]

"Did I violate you buy hitting ctrl-c and ctrl-v?"

Not copyright. Because you copied a mere part of the work, and you did so for the purposes of criticism, and you aren't making any money off it. Almost anybody would classify that as "fair use". Copyright has limits. It does not give the author absolute control in all circumstances and forms.

Re:Copyright Poo Poo

[misof]

As many before you, you put open source and free sw into the same bag. The article is open "source". This means that anybody can read it, understand the bug, help fix it, patch his machine, etc. However, it's not free, because the author wants the credit for his work. I don't see a problem here. Do you?

Re:Copyright Poo Poo

[stecoop]

I don't see a problem here. Do you?

Don't fall into the copyright trap. If somone wanted to steal his work, they would but no one would get away with it and would be flushed out really fast. Imainge if somone had this on their resume, a quick google search would get the facts straight.

Re:Copyright Poo Poo

[_Sprocket_]

Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.

What's interesting is the preface that shows up on several lists:

Hi all,

first of all I must comply about the handling of this vulnerability that I reported to vendorsec. Obviously my code posted there has been stolen and plagiated by Stefan Esser from Ematters. The posting containing the plagiate will follow. Now I have been forced to release the full advisory however another disclosure timeline have been agreed on vendorsec. Sorry for the inconvenience.

Followed by:

Hi all,

first of all I must comply about the handling of this vulnerability that I
reported to vendorsec. Obviously my code posted there has been stolen and
plagiarized in order to put the blame on Stefan Esser from Ematters and
disturb the security community.

I really apologize to Stefan Esser for the inconvenience and thank him
for his cool reaction - the plagiarism did work.

Further steps must be taken to investigate the security leak on vendorsec.

Re:Copyright Poo Poo

[northcat]

Did I violate you buy hitting ctrl-c and ctrl-v?

It's called fair use. But your post does have a point.

There's more where that came from...

[sanityspeech]

I always thought that NAT and bastille would be enough. I never considered the risk of this sort. Worse yet, it seems that the reported exploit isn't the only locally exploitable flaw

What's an admin to do?

from the without-users-this-wouldn't-be-a-problem dept.

*Shudders*

Then, methinks: "I'll just apply a patch..."

It turns out that patches do NOT always fix the problem.

What's an admin to do?

Re:There's more where that came from...

[Marxist Hacker 42]

What's an admin to do?

Hmm- for a local root exploit? How about LOCK THE FREAKIN' DOOR? Turn on screen saver passwords? ENFORCE A ONE-USER-TO-ONE-MACHINE RULE!!!!! The solution to local kernal root attacks is PHYSICAL not CYBER security.

Re:There's more where that came from...

[shadow303]

Silly admin, patch the users not the computers. I figure that a couple of rolls of duct tape per user should be sufficient to protect your system from their filthy paws. You also get the added benefit of them not wasting your CPU cycles while playing Doom 3.

Re:There's more where that came from...

[biglig2]

An admin is to mutter the ancient rule:

"If they have physical access to the box, we're screwed".

Re:There's more where that came from...

[chill]

The solution to local kernal root attacks is PHYSICAL not CYBER security.

Wrong.

And if someone exploits a remote *application* (PHP, Apache, FTPd, Sendmail, Bind, etc.) causing it to give you a shell or pass commands to the underlying system, what then?

Your "local" exploit just became a "remote" exploit. What about ISPs who give shell (SSH) access to certain accounts?

A "one user to one machine" rule is so stupid it boggles the mind. How exactly do you expect to run a server with that rule? The network is more than just that beige box on your desk.

Local and remote, like root, are only states of mind.

-Charles

Re:There's more where that came from...

[Taladar]

Local root exploits can be used via ssh if you have a normal user account on that machine so it is not the same as physical access (in which case you just reboot with init=/bin/bash as kernel parameter or use a livecd to get root)

Re:There's more where that came from...

[compass46]

You have no imagination. What if one of the machine's regular users is malicous? Hopefully they are not but you can't know what is going on in every user's head.

Re:There's more where that came from...

[KarmaMB84]

Yeah, let me proceed to root my major university's systems and cause them to DDoS someone... j/k I don't even remember my login password :O

Re:There's more where that came from...

[Marxist Hacker 42]

I personally enforce JUST such a rule in my own house- NOBODY is alowed to touch my main machine, NO telnet or SSH accounts allowed on the main server, and anybody attaching to my network NEEDS to bring a machine with them. Hardware is so cheap these days, it's not asking very much to enforce exactly this rule.

Re:There's more where that came from...

[Marxist Hacker 42]

And if someone exploits a remote *application* (PHP, Apache, FTPd, Sendmail, Bind, etc.) causing it to give you a shell or pass commands to the underlying system, what then?

Mission Critical machines should not have remote applications running on them without a major firewall between the application and the kernal.

Your "local" exploit just became a "remote" exploit. What about ISPs who give shell (SSH) access to certain accounts?

SSH accounts should ALWAYS be on a different box than a major server- NEVER on the same box. And preferably, not at all.

A "one user to one machine" rule is so stupid it boggles the mind. How exactly do you expect to run a server with that rule?

By taking telnet and SSH off of it and requiring passwords on FTP, of course. For everything else, require an administrator with LOCAL (as in hardware keyboard) access. It's called being paranoid- and it's the FIRST rule anybody trying to run a secure system should know.

Local and remote, like root, are only states of mind.

Only if you allow them to be- same problem Microsoft has with security.

Re:There's more where that came from...

[Marxist Hacker 42]

Thus the rule of each user primarily working on their own machine, and a minimum of data flowing across the network with firewalls protecting ANYTHING that is even slightly vital. NEVER trust a luser to do anything but break hardware.

Re:There's more where that came from...

[chill]

I'm not quite sure where to begin...

Mission Critical machines should not have remote applications running on them without a major firewall between the application and the kernal.

You mean like file sharing servers and print servers? Samba has kernel-level components you can't do without. Apache has kernel hooks and system calls that aren't userland. Are you talking about compartmentalization? (chroot & things like SElinux). This level of PITA is hard to justify in normal business situations.

By taking telnet and SSH off of it and requiring passwords on FTP, of course. For everything else, require an administrator with LOCAL (as in hardware keyboard) access. It's called being paranoid- and it's the FIRST rule anybody trying to run a secure system should know.

This is just plain WRONG. Leave SSH on use SCP/SFTP and get secure transfers. I don't allow FTP at all. All plain-text logins are disallowed on my servers. Even e-mail requires SSL v3/TLS v1 to connect and valid user accounts (SMTP AUTH).

Considering the box is located in a locked cage at an ISP -- and a redundant box in another ISP *ACROSS THE COUNTRY* -- how do you propose to have a keyboard at each? If box #1 does down and I have to monitor/massage the backup in Dallas do you propose all my customers wait until I can arrange a flight?

It sounds like you've never administered a large or geographically diverse network. It is frequently IMPOSSIBLE to admin boxes only locally. SSH is a godsend and it belongs on damn near EVERY box.

-Charles

Re:There's more where that came from...

[dossen]

...a major firewall between the application and the kernal....

Are you a bit confused, or would you like to explain what you mean by firewall between the kernel and the application? Are you thinking of virtual servers? Then how about I just become root in the virtual server? I still have root on a machine in your network, although it might not be running more than one service I can fool around with (until I start my own services).

SSH accounts should ALWAYS be on a different box than a major server- NEVER on the same box. And preferably, not at all.

Maybe users do not need shell access to all servers, but how would you administer a colocated/remote/headless/etc. machine without having (secure) remote shell access for relevant staff? How about users with legitimate need for shell access to the machine (remote working, checking mail (yes, I prefer ssh mailhost mutt over any webmail, anyday - and I and many others would be vastly less effective with webmail (until someone builds a webmail system of similar strength (but then it would need to include most of a terminal emulator/shell anyway)), local preprocessing of big datasets (say you need to do a simple search on a few GB of data - you want me to transfer that over the network (perhaps even to a remote location), or run the search locally and transfer a few bytes of result))?

By taking telnet and SSH off of it and requiring passwords on FTP.

You want to remove telnet, fine go ahead (might want to leave the telnet executable though (but do delete telnetd), it is very handy for diagnostics). But you want to delete ssh and leave ftp? You do know that ssh can be used for more secure filetransfer/remote filemanagement than ftp (scp/sftp)? You know that ssh allows you to setup remote accesses, that can only run the apps needed for that particulary purpose?

...require an administrator with LOCAL (as in hardware keyboard) access. It's called being paranoid...

If you are that paranoid, then your server is not connected to the Internet. If there is a codeinjection exploit in that ftpd you wanted to leave running, I don't need a shell to use a local root exploit (shells are not the only deamons that can exec() you know).

Re:There's more where that came from...

[JonathanX]

Mission Critical machines should not have remote applications running on them without a major firewall between the application and the kernal.

Well, since everyone else is being diplomatic and trying to give you a clear explanation for why they disagree with you, I'll just cut right to the chase...

You don't know what the hell you're talking about and you should probably shut the hell up now rather than embarassing yourself further.

Re:There's more where that came from...

[crazyphilman]

I sure hope this gets patched soon. I'll be downloading that baby the instant it gets made available.

I'm lucky on two counts, though:

1. I usually use Linux as a workstation, and don't have any users or services to worry about; but even if I did,

2. I use Slackware, so I can probably just download and install a new bare.i (I'm using one of the stock kernels).

God BLESS Slackware! I love that system, I surely do...

How the hell

[BoomerSooner]

How do people find this stuff? Amazing. Open source is astounding.

When do I get my kernel update?

Re:How the hell

[PornMaster]

Have you tried kernelupdate.kernel.org?

Oh, wait. This is Linux. You'll have to reply to 5-10 questions before we can offer an answer. :)

Re:How the hell

[BoomerSooner]

I meant when. Whoops!

Re:How the hell

[pasde]

When do I get my kernel update?

No worry. I ve already installed it for you.

Re:How the hell

[iabervon]

Now: patch for 2.6.10. Latest 2.4 release candidate fixes it.

Failed on RHEL

[SuperQ]

I compiled included code at the end of the advisiory, this was the output on RHEL 2.4.21-20

% ./test

[+] SLAB cleanup
child 1 VMAs 65525
child 2 VMAs 65392
[+] moved stack bfff8000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xdf400000 - 0xfe5f2000
Wait... -
[-] FAILED: try again (Cannot allocate memory)
Killed

Re:Failed on RHEL

[ericzundel]

I tried it on a couple of boxes. It tries to exploit a race condition, so it won't necessarily work all the time. However I have tried it a few dozen times and haven't gotten it to work yet. (One RH 7.3 box and one RH 9.0 box)

Re:Failed on RHEL

[ericzundel]

Hmm. right after I posted that, it came through on the RH 9 box:

./elflbl -n2

[+] SLAB cleanup
child 1 VMAs 65527
child 2 VMAs 65527
child 3 VMAs 65527
...
child 18 VMAs 63322
[+] moved stack bfffb000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xdf800000 - 0xfedbb000
Wait... \
[+] race won maps=49205
expanded VMA (0xbfffc000-0xffffe000)
[!] try to exploit 0xe2d25000
[+] gate modified ( 0xffec903c 0x0804ec00 )
[+] exploited, uid=0

sh-2.05b#

Re:Failed on RHEL

[fucksl4shd0t]

[dave@davefancella Projects]$ gcc -O2 -fomit-frame-pointer elflbl.c -o elflbl
elflbl.c: In function `scan_mm_start':
elflbl.c:425: error: storage size of 'l' isn't known
elflbl.c: In function `check_vma_flags':
elflbl.c:545: error: label at end of compound statement
elflbl.c: In function `scan_mm_start':
elflbl.c:425: error: storage size of `l' isn't known
[dave@davefancella Projects]$ cat /proc/version
Linux version 2.6.8.1-12mdk (quintela@n5.mandrakesoft.com) (gcc version 3.4.1 (Mandrakelinux (Alpha 3.4.1-3mdk)) #1 Fri Oct 1 12:53:41 CEST 2004

Mandrake 10.1

Re:Failed on RHEL

[Henk Poley]

Does anybody know if some SE Linux versions are also affected?

Re:Failed on RHEL

[Yottabyte84]

Not working on my Debian box, but it's SMP, and the code says it may require modification for SMP.

Re:Failed on RHEL

[szo]

-I/usr/src/linux/include

Re:Failed on RHEL

[Yottabyte84]

Well, it just hung my box.

Re:Failed on RHEL

[Anonymous Coward]

it was intended for GCC 2.X, never tested on 3.x.

Re:Failed on RHEL

[menscher]

Right... I haven't gotten it to work under RHEL3 or RH9, both using SMP kernels. Note that's true even if there's only one processor (no HT) in the machine.

Re:Failed on RHEL

[fucksl4shd0t]

Didn't work. :( Thanks, though. I did a cursory look through the code, but this is C that's a bit beyond me. Not much of a C programmer these days...

Re:Failed on RHEL

[Anonymous Coward]

$ gcc -o exploit exploit.c -I/usr/src/linux/include/
exploit.c: In function `scan_mm_start':
exploit.c:425: error: storage size of 'l' isn't known
exploit.c:425: error: storage size of `l' isn't known
exploit.c: In function `check_vma_flags':
exploit.c:545: error: label at end of compound statement

gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)

Re:Failed on RHEL

[szo]

sorry, now I see you have 2.6.x . I needed it for 2.4.x

Re:Failed on RHEL

[fucksl4shd0t]

:) I didn't see in the article where it's supposed to affect the 2.6 kernel, but the writeup seemed to think so. I wanted to test all the same.

Re:Failed on RHEL

[awkScooby]

If you're running an SMP kernel then the exploit code may not work. He does have a comment in there about "may need modification for SMP." It might also just be a matter of trying it a lot more times.

Re:Failed on RHEL

[djeca]

This is what you need for kernel 2.6 and gcc 3.x:

--- ./elflbl.c 2005/01/07 23:20:34 1.1
+++ ./elflbl.c 2005/01/07 23:12:28
@@ -422,7 +422,7 @@ retry:
void scan_mm_start()
{
static int npg=0;
-static struct modify_ldt_ldt_s l;
+static struct user_desc l;

pnum++;
if(pnum==1) {
@@ -542,6 +542,7 @@ void check_vma_flags()
signal(SIGSEGV, vreversed);
val = * (unsigned*)(lib_addr + PAGE_SIZE);
out:
+ ;
}

============ end patch =========

Although, I still can't get it to work on my boxes (2.6.9-nitro4 on Gentoo 2005.0) - mmap2 fails with ENODEV, not sure why.

Re:Failed on RHEL

[Winter]

On 2.6 (dont know which version) the structure modify_ldt_ldt_s changed name to user_desc.

try this patch (if slachdot lets it through)

--- test_old.c 2005-01-07 17:47:57.989595093 -0600
+++ test_vma.c 2005-01-07 17:42:18.478142594 -0600
@@ -422,7 +422,7 @@ retry:
void scan_mm_start()
{
static int npg=0;
-static struct modify_ldt_ldt_s l;
+static struct user_desc l;

pnum++;
if(pnum==1) {

Re:Failed on RHEL

[ubernostrum]

I also can't get it to compile on FC3... spits out a bunch of syntax errors and aborts.

won't be exploted here!

[Dominatus]

It's a good thing I've got the patch downloa

Re:won't be exploted here!

[pepsee]

You forgot to add NO CARRIER to your post.

Re:won't be exploted here!

[Alsee]

You forgot to add NO CARRIER to your post.

Maybe it's finally time to upgrade that class of joke from the dial-up era to broadband?

-

Once again...

[Sheetrock]

A2M swapping rears its ugly head. This semaphore system has worked well to date, but perhaps should be mandated (i.e. code will not work unless a semaphore is set.)

They've got a pretty good record. Unfortunately, kernel-level stuff is nasty -- how do you fix embedded devices?

Re:Once again...

[CharlieHedlin]

Embeded devices probably aren't much of a concern. most run everything as root anyways.

Re:Once again...

[grub]

how do you fix embedded devices?

Shouldn't be much of an issue, most embedded devices don't have user accounts.

Re:Once again...

[SmokeHalo]

I know this is OT, but I gotta say it:

1) Your sig quote actually belongs to Yoda, not Spock.

2) Spock (of Star Trek fame) is not a doctor of anything.

Re:Once again...

[GigsVT]

What do programs run as then? All root?

Re:Once again...

[grub]

Shell-less user accounts? You can't log in to them.

Re:Once again...

[GigsVT]

A local privilege exploit still presents a risk to such accounts. Exploit apache running on your self-contained webcam, use the local exploit to elevate to root, and then you can do whatever you want.

Re:Once again...

[grub]

On Linux, sure. On OpenBSD Apache runs chrooted as a non-priv account. Anyhow, that's just one example to thousands of successful running embedded things. Embedded things tend to use small processes to run things. Apache on an embedded webcam is gross overkill when tinyhttp would work just fine.

Re:What, no remote exploit?!?

[Ly0n]

since windows is more "single user" oriented, most local exploit flaws on windows do not get very much publicity.

For instance, shatter attacks are still a very large threat for multi-user windows systems

My gun is ready.

[tirenours]

I'll shoot anybody who come 100 meters close to my machine*.

Now, that's security!

* May not be true

Re:What, no remote exploit?!?

[Anonymous Coward]

This has got me thinking. The bug can only be caused by local users; does this include non-jailed programs like apache and postgresql. these all have non-root user accounts on most systems, could the apache user use this exploit?

Funny you should mention...

[Yaa 101]

I need no exploit to gain root privileges, I just login...

Re:Funny you should mention...

[garcia]

Bah, logging in sucks. I just use the sudo hack to gain root access...

garcia@shitbox:~$ sudo su
shitbox:/home/garcia#

woot, the hack works like a charm. They should really include the C source for the hack so all the kiddies can use it.

Re:Funny you should mention...

[Yaa 101]

lol... you are the only one that understands that I have a Linux machine...

Re:Funny you should mention...

[flokemon]

Ooh and guess what... I Own any Linux box I have physical access to with any Gentoo/Slackware CD I happen to carry with me.

And I don't even need to login!!!11LOL!!!111fucktardsausage!!111

Next?

Re:Funny you should mention...

[wirelessbuzzers]

garcia@shitbox:~$ sudo su
shitbox:/home/garcia#

sudo -s

Re:Funny you should mention...

[nortcele]

I need no exploit to gain root privileges, I just login...

Same here. I 0wn any PC that will boot my Knoppix CD.

Re:Funny you should mention...

[flosofl]

I Own any Linux box I have physical access to with any Gentoo/Slackware CD I happen to carry with me Two words:

encrypted filesystem.

Re:Funny you should mention...

[loucura!]

2 even shorter words: no power.

Re:Funny you should mention...

[m50d]

My lilo is passworded, as is my BIOS which is set only to boot from hd. And my case is alarmed. OK it isn't really, but what would you do if it was?

Re:Funny you should mention...

[someonehasmyname]

reset jumper.

Re:What, no remote exploit?!?

[iabervon]

The linux kernel does very little interpretation of remotely-provided data. There are occasionally remote exploits (e.g. the Ping of Death in '97 or so), but that code has now been pretty thoroughly checked at this point. Most of the code which cares at all about the validity of data is interfaces only accessible locally.

Re:That's why MS will rule the world.

[spac3manspiff]

Mod parent -1 denial.

The score so far...

[schmidt349]

It's a straight fight so far in the Privilege Escalation match in the past year, so let's look in on our contenders:

Windows (all versions) 100
Linux 1

It looks pretty bad for Linux until you consider that this game is scored like golf, and then it's all tears and jeers in Redmond.

Back to you, Cowboyneal.

(NB. I know there have probably been other Linux kernel exploits, but this is the first in recent memory.)

Re:The score so far...

[greppling]

It's a straight fight so far in the Privilege Escalation match in the past year, so let's look in on our contenders: Windows (all versions) 100 Linux 1

Sorry, this "1" is so much off-base it's not even funny. I hope you are not responsible for patching any Linux system. I don't think last year was a good year wrt linux kernel security.

lets hope no-one discovers

[Anonymous Coward]

su

Re:What, no remote exploit?!?

[Michalson]

Because Linux is a kernel, with no real knowledge or direct interaction with outside (remote) sources, while Windows is a kernel plus a GUI plus a ton of other services. Remote exploits aren't found in the Windows kernel, they're found in the application/service part of Windows, on the Linux side these buggy, infinitely exploitable services are given individual names like "sendmail" and "bind".

Re:What, no remote exploit?!?

[zaffir]

I don't see why not. Local roots are used for privilege escalation. If someone had access to the apache account on the machine, they could then gain root access.

Re:What, no remote exploit?!?

[Richard_at_work]

Because 'Linux' exploits are kernel exploits, because Linux is a kernel, as people are so fond of pointing out, which actually has very little to do with remote entities other than the well looked at TCP/IP stack. Windows on the other hand is an Operating System, which includes things other than the kernel, including system daemons/services, user interface code, web browsers, and a whole host of other things.

Long story short, while it may be shoddy, MS Windows is a LOT bigger than Linux, and thus theres more to exploit. If you look at something like Redhat, which is a distribution, you have more of a comparison, and you will find remote exploits.

Re:What, no remote exploit?!?

[csnydermvpsoft]

Linux is just a kernel. A more accurate comparison is Linux distributions vs. Windows. Bugs are discovered all the time in application software that is bundled with many distributions. The difference, however, is that if there's a bug in a Linux app, you can uninstall/disable it until it is fixed, while many of the apps shipped with Windows can't be easily removed.

This could help

[datadriven]

... if I forget my root password.

Re:This could help

[datadriven]

not uless you're a local user on my machine.

Re:This could help

[Taladar]

Just use a livecd, mount your harddisk linux install, chroot to it and use passwd to set a new password (assuming you use the root account of the livecd)

Re:This could help

[mnelson]

Just use a livecd ...

Slightly OT, but why bother with a live cd? At the lilo/grub menu, edit/add "init=/bin/sh" to the kernel parameters. This will boot the system, and bypass everything the init program usually runs, dumping you to a root prompt. (it actually starts a shell as root, thinking it is the init program ;) Remount the root fs r/w, chroot to it, change password.

Some security levels/configs may prevent this type of thing, but it is well worth a try before reaching for a live cd you may not have handy...

Re:This could help

[flosofl]

Of course, if you have EFS and forgot that password (which, let's face it, is pretty damn likely if you forgot the password for root!), you've just been fucked without being given dinner first.

That's why I have a password safe on my Palm Pilot (AES encrypted - strong passphrase). Of course if I forget that passphrase.. I'm pretty fucked :)

Re:This could help

[catscan2000]

Or, if you have physical access to the machine, boot up into Single User Mode by adding a 1 to the end of the kernel bootup parameters.

If you're using Fedora, for instance, press A at the Grub screen, press the Space Bar, type in the number 1, and press Enter.

If you are using LILO, it will look something like this, plus or minus:

boot: linux 1

This will tell init to start up in runlevel 1, which drops you into root without the need for a password.

Re:This could help

[I_redwolf]

It could also help me if I forget your root password.

Re:This could help

[mvdwege]

Booting into single user does not automatically give you a root shell. Some distros (I use Debian, for example) require the root password before giving you a shell in runlevel 1.

Booting with init=/bin/bash (or any shell you know is available from the root fs) will work however.

Mart

Re:This could help

[m50d]

I think the best you can do is leave your password in a bank safe deposit box. Not 100% security, but if you can't trust your banker who can you trust, and it's better than forgetting your password and losing everything.

dude

[toiletmonster]

dude i'm not going to read all that crap. give me a freaking summary.

Re:dude

[Anonymous Coward]

Summary for the lazy ones: These are four of the probably uncounted bugs which are known for months (if not years), reported to the maintainers but are still unfixed. Yes, we're speaking about the Linux kernel.

Re:dude

[Curtman]

i'm not going to read all that crap. give me a freaking summary.

• 3 weeks is a sufficient amount of time to be able to expect even a reply about a given vulnerability. A patch for the vulnerability was attached to the mails, and in the PaX team's mails, a working exploit as well. Private notification of vulnerabilities is a privilege, and when that privilege is abused by not responding promptly, it deserves to be revoked.

Re:Interested

[Anonymous Coward]

its difficult to compare windows vs linux. in a scientific fashion atleast:

Do you include the bundled software on your average linux distro...

Kernel to kernel would be interesting.

Local Access is always a trump card

[Delusional]

Is there ever a time when you can consider your systems secure against an attacker with physical access?

Re:Local Access is always a trump card

[Wyzard]

"Local exploit" just means you need an account on the system, not physical access. You could log in over a network using SSH or Telnet and exploit this.

Re:Local Access is always a trump card

[rjstanford]

Well, yes and no. There's a difference between being vulnerable to those with physical access (pretty much always true, but very limited) and vulnerable to those folks with the ability to run something on your machine locally (fewer than true remote users, but much higher in number than those folk with actual physical access). All you need for this exploit is a way to run unpriv. code on the machine. Note that using a network exploit to run said code is a great way of gaining access - suddenly the fact that your webserver is running as "nobody" doesn't really matter any more.

Re:Local Access is always a trump card

[cnettel]

Is there ever a time when you can consider your systems secure against an attacker with physical access?

No, but combine any buffer overflow with arbitrary code execution exploit, running as a low privilege user and any local-only privilege elevation exploit...

As this exploit is mainly at load-time, I imagine a buffer overflow to use it would be in a few steps:

Get your code loaded through the remote exploit.

Download another file with the privilege elevation code and the real nasty stuff you want to set up.

Call system or exec with your newly created file.

?????

Profit!

The only good thing about this is that we surely could claim that this is enough of a derivative work upon the kernel that the source for the exploitation code should be published!

Of course, this requires the exploitation code to in a small space find out some place where the user is allowed to write a binary and give it execute permission. "~/" should generally work and chmodding isn't that hard...

Re:Local Access is always a trump card

[SComps]

If I read this correctly, one doesn't really need physical access to the device, but only local access, telnet, ssh or anything else that will put them at a command prompt, with the ability to compile/execute code of their choice.

I do agree though, anyone sitting at my server's keyboard is either invited, or cruising for a very serious head injury.

Re:Local Access is always a trump card

[torinth]

This needn't involve physical access.

Consider: you download a suspicious binary--a game, perhaps--with Firfox. Being a good *nix user, you run it as a user that has limited access rights to the system and your personal data. Sadly, you later learn that the binary contained this exploit, has escalated its priveleges to root level, infected a bunch of other files on your computer, and sets up a spam relay.

These kinds of exploits completely nullify the huge security benefits of multi-user systems, and leave you in the same vulnerable position as the windows user who always log in as Administrator.

Re:Local Access is always a trump card

[oni]

in this case, local access means, "has an account on the machine." Not necessarily, "is standing in front of the machine." So basically we're talking about shell accounts.

Re:Local Access is always a trump card

[arose]

Local as in "need user level access" not "need screwdriver level access".

Re:Local Access is always a trump card

[MichaelSmith]

Is there ever a time when you can consider your systems secure against an attacker with physical access?

Short of having DRM, no. But this is an issue if your users ssh into your box. You grant priviliges to their account but this is no good if they can use an exploit to get more

Re:Local Access is always a trump card

[mslinux]

too bad that nobody's shell on a smart person's box is /bin/false

Re:Local Access is always a trump card

[rjstanford]

That won't necessarily save you, I'm afraid. If the machine is running any software that through feature or an exploit allows a remote user to run uploaded code, you're screwed. That's because as soon as you're running that code, it can use this type of hole to grant itself full root privileges. Once its done that, what makes you think that its going to be nice enough to check /etc/passwd and spawn a requested shell (not that that would be terribly useful for this type of remote exploit). At that point, the sky's the limit I'm afraid.

Re:Local Access is always a trump card

[Taladar]

But still two steps are needed compared to a remote root exploit (basically all Windows exploits that work without user intervention) where one step is enough.

Re:Local Access is always a trump card

[STrinity]

Is there ever a time when you can consider your systems secure against an attacker with physical access?

This is why I encrypt all data on my hard-drive and store the key on a USB drive that I carry in my underpants.

And people think I'm paranoid! Bwa ha ha ha ha ha ha ha!

Re:Local Access is always a trump card

[archen]

I'd think it would be smarter to use /sbin/nologin. I used to set shells to /dev/null (although FreeBSD would bitch about it not being executable) until someone pointed out that you would probably want to KNOW that someone had tried to use that account, and see it in your logs...

Re:Local Access is always a trump card

[op00to]

Not just a command prompt! If you have crappy php scripts like the vulnerable versions of phpBB, it is trivial for a cracker to gain access, download its rootkit, and own your machine.

Re:Local Access is always a trump card

[hobbesx]

You might try a hole and cement?

Re:Local Access is always a trump card

[jonadab]

> Is there ever a time when you can consider your systems secure against
> an attacker with physical access?

In the phrase "local root exploit", the word "local" doesn't mean local in
the sense of physically present, but in the sense of needing to already have
user-level access. If you combine it with a non-root remote exploit, the
two together add up to the equivalent of a remote root exploit.

In other words, this is definitely something we want to fix.

As far as securing a system against physical access, that's a whole nother
kind of hard. At bare minimum you need an encrypted filesystem with a key
that isn't stored and so has to be entered by an authorized user every time
the filesystem is mounted, and then on top of that if you make sure that the
machine, if left unattended, suspends running processes to disk and then
unmounts the filesystem, and if you're both paranoid, obsessive, and tireless
when it comes to bughunting, you potentially could develop a system that has
a reasonable degree of security against an attacker with physical access --
but "a reasonable degree" does not mean "impenetrable" -- there are still
hidden cameras, keyboard logging devices, and the like, to say nothing of
rubber hose cryptanalysis.

Re:Local Access is always a trump card

[John Whitley]

"Local" != "Console". This isn't about physical access. Kernel privilege escalation attacks are like gold to someone trying to take over a system. It allows any non-root remote exploit to be turned into a remote root exploit. To really spell it out:

Step 1: Attack any non-root remote exploit, establish a non-root shellcode "beachead".
Step 2: Run this attack on an unpatched system.
Step 3: There is no step 3; the box is 0wned.

This is a *very* serious problem. Linux folks, patch your systems ASAP.

Re:Local Access is always a trump card

[arose]

1. Steal underpants
2. Identity theft
3. Profit

Re:Local Access is always a trump card

[Gojira Shipi-Taro]

Excellent point. However I do employ an important element to local system security. I make it quite clear to anyone that might attempt to comprimise my systems from the console that they could concevably "disappear". Fortunately, my cats do not appear to be too unnerved by the severity of my policies...

Re:Local Access is always a trump card

[m50d]

Anything suspicious should be run in a chroot as well. But yes, it is a serious exploit.

Re:What, no remote exploit?!?

[the_mad_poster]

It can be exploited by any user or process that can compile and load executables on the machine.

Re:Wow...

[BlurredWeasel]

except you know, when you have users...

Re:What, no remote exploit?!?

[proverbialcow]

It should be simple enough - if you have remote access to the machine already (i.e. you want to r00t a machine at school or whatever.) Log in, run the exploit from the shell, bingo bango bongo - you're root.

It's not like the code magically runs on your machine at home...

Re:Hear that sound?

[Triumph The Insult C]

s/fanboys/Vice Presidents/

Re:What, no remote exploit?!?

[EnderWiggnz]

you mean to tell me that people have found exploits in bind and sendmail?

no way - they're perfect open source programs. model programs, so to speak.

next, you'll tell me that x is a crufty, inefficient kludge.

Local vs. Remote

[Gherald]

Obviously if it is local if it is exploitable from the console. But can it be exploited remotely through ssh if one already has a user account?

Re:Local vs. Remote

[rewt66]

In this context, that's what "local" means: That you have a local account, even if you are accessing it with telnet or ssh.

A "remote" exploit is one that can be used by someone who has a network connection to the machine, but no account on it.

Re:Local vs. Remote

[John Courtland]

Yes. Once you're on the terminal, and if you have the proper rights to run this exploit, you got root.

Re:Local vs. Remote

[temojen]

Or know of a remote vulnerability in an unprivileged service.

Re:Local vs. Remote

[Bloater]

yes, local normally means user-space software running on the system can exploit it. That means any program you type in, compile, and run from a physically attached keyboard, or through ssh, or even any code that a local daemon or client program is tricked into using. That means possibly one of those old libpng buffer overflows can be used to insert code into mozilla and eventually get root - you have patched those seemingly unimportant security announcements haven't you?

To be limited to a physical access exploit, it would need to be a bug in the keyboard driver, the input layer, or possibly a user-space program that uses raw keyboard entry. I don't think screwdriver level access counts, since you can lock your machine up. Filesystem bugs could be exploitable via usb drives, floppy disks, cf drives, etc... Those are physical exploits rather than local.

Re:Interested

[gnuLNX]

I would wager that if the world switched to linux tommorrow then next week we would see a fairly large number of new exploits. Would it be as many as windows...or would they be as damaging? I don't know. But I do believe that being open source would allow the said exploits to be fixed within a couple of weeks of discovery and certainly the next kernel release would be much safer. just my guess tho.

This proves it... Windows has better networking!

[scsirob]

I mean, just look at it... Windows gets exploited across their network facilities. Linux never does.

Who's smiling now, eh?!? ;-)

Embedded devices?

[rewt66]

How do you fix embedded devices? Um... you mean how do you update/patch the code on the embedded device so that a local user can't escalate to root?

First of all, for many embedded devices, this isn't an issue. I mean, if you're an attacker, what are you gonna do once you get root? If the owner can't patch the OS, you probably can't install a rootkit either. Sure, you can DOS it, but if you're physically at the device, you can DOS it just by hitting the power button.

However, manufacturers of all embedded devices (not just Linux-based!) should definitely put a mechanism in place for updating the program code.

Re:Embedded devices?

[Alsee]

If the owner can't patch the OS, you probably can't install a rootkit either.

manufacturers of all embedded devices (not just Linux-based!) should definitely put a mechanism in place for updating the program code.

Errr, doesn't your second comment sort of defeat the first one?

-

Re:Stop posting exploits.

[Anonymous Coward]

Troll or not, not posting will just end up with more vulnerable boxes.

Short-term vulnerability in retrun for media coverage and quick patching, or long-term vulnerability while those "in the know" freely exploit.

Former, please. :)

Only in select modules?

[Leadhyena]

Doesn't this only work if you compile the ELF and a.out support into the kernel, or am I mistaken? If so, it's just yet another reason to be VERY CAREFUL what you enable in the kernel when you compile it, lest you enable something that you don't need and is yet exploitable.

I should mention that enabling ELF format is still highly recommended (after the patch for this is released of course) and unless you do special programming work in linux then enabling a.out format is not recommended.

Re:Only in select modules?

[jnik]

Doesn't this only work if you compile the ELF and a.out support into the kernel, or am I mistaken?
What exactly would one do with a Linux system that has neither ELF nor a.out support?

Re:Only in select modules?

[NoMercy]

Oh come on, Insightful *slaps people about* Funny perhaps, I actually forgot to enable this once when starting with a blank set of kernel options, Kernel panic, can't load Init... I was stumped for a while :)

Re:Only in select modules?

[ajaxxx]

Since ELF is the native binary format on linux, you don't really have much choice in the matter. You could compile it out if you wanted, but you'd never make it to /sbin/init.

Good try though.

Re:Only in select modules?

[NullProg]

I should mention that enabling ELF format is still highly recommended (after the patch for this is released of course) and unless you do special programming work in linux then enabling a.out format is not recommended.

1996 Called, Tux want's his a.out back.

Re:Only in select modules?

[op00to]

Run a kernel-mode webserver? :)

Re:Only in select modules?

[m50d]

Read his post again - he's claiming it only works if you compile a.out *and* elf in. I don't have any need for a.out support in my kernel, and you may well not either.

Re:Only in select modules?

[jnik]

Run a kernel-mode webserver? :)
Wow, you're right! I tried booting a kernel with no binary format support and it worked until it tried to pull up init. So the ELF/a.out option is only for the kcore format (it was phrased differently back in the 2.0 days, which is why I was confused). Not sure how you'd make the kernel not try to run init, though.

making APIs secure takes time

[jeif1k]

"uselib" is a Linux-specific extension, and, as a result, has received much less real-world testing than traditional UNIX system calls. Keep in mind that the traditional UNIX system calls have received millions of man-years of real-world testing in large user communities likely to attempt both remote and local exploits. It is not surprising that Linux-specific extensions are at a much greater risk of containing serious security problems.

Re:making APIs secure takes time

[cnettel]

IMHO, this seems more related to the internal process management data structures/memory management. Naturally, there are interfaces that are more inherently unsafe because they are complicated to implement or synchronize, but this just seems to be a bug that would be just as likely to happen in any part initializing memory mapping data.

The fact that the functionality hasn't been there all of the history of Linux could be a reason to trust it less, but then we should probably avoid using anything above 2.2 (or 2.0, or...) at all. The fact that some function signatures mimic those of original UNIX and some don't seems quite irrelevant to me.

Re:making APIs secure takes time

[Taladar]

Not entirely wrong but you forget that the Linux versions of the traditional Unix System Calls are still new implementations of the same call which means they can contain bugs other implementations of the same calls do not.

Re:making APIs secure takes time

[photon317]

And also that the traditional unix system calls have been re-implemented, patched, tweaked, and re-implemented all over again by numerous vendors. The code under the hood in officially licensed unix implementations isn't always much better than linux in terms of maturity and widespread testing.

Re:making APIs secure takes time

[Alan Cox]

No this was just a dumb locking bug. You could reasonably argue that some of the kernel API's for do_brk were less than well designed but thats more historical accident.

Its fixed by 2.6.10-ac6 along with the setsid crash and some other corner case bugs Coverity found.

Re:making APIs secure takes time

[FullMetalAlchemist]

Or, one can simply say that implementing own API standards suck ass because it benefits no-one and promotes platform lock-in.
The second fact is, that API's are abstract implementations which means that, for example, same API call ore most oftenly exploitable on one platform but not on another; there are of course exceptions, like not having lenght parameters in functioncalls for c strings.

Re:making APIs secure takes time

[dossen]

In this case it would be rather hard to go old enough to avoid the system call. It is the original shared library implementation, from 0.12 (yes _0_ dot _12_). Source: http://groups-beta.google.com/group/comp.os.linux/ msg/648f904b7e22ea21

Re:making APIs secure takes time

[cnettel]

Ooops.

Then I guess my parent had no point at all, there is no inherent lesser safety in code that uses a new interface unless the interface is really broken, compared to reimplementing an old and "proven" one like the great function strcpy! (Not insecure in itself, but...)

Distribution restrictions

[cperciva]

COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.

Is it just me, or is this mind-bogglingly stupid? A security advisory which can't be redistributed freely? Imagine if the same approach was taken to important warnings in the real world -- "There's a tsunami heading towards you... but you're not allowed to redistribute this warning to all the people around you without my permission."

Security advisories should be in the public domain.

Re:Distribution restrictions

[Anonymous Coward]

Nah...this is smart. Copyright the exploit code, and then once a worm is spread, he can sue everyone for copyright infringement.

Re:Distribution restrictions

[Jerf]

Is it just me, or is this mind-bogglingly stupid?

It's irrelevant anyhow. If you didn't sign a contract to keep it secret, they have no grounds to gag you. They can copyright their exact words and can (and probably should*) control the distribution of those words, but copyright does not give them any protection of the facts contained within. And neither does anything else.

For the same reason, when you are accidentally mailed something with one of those "you must delete this immediately if you are not the intended recipient", unless it is actually and literally classified, you have no obligations. It's just to scare people.

The legal system has a ways to go before you can be obligated by an email out of the blue, or a random announcement on a webpage taking rights not granted to them by copyright but implementing no real access control (i.e., attempting to obligate you after you downloaded a page; it might work if you make it a condidion of reading but not just out of the blue, after the fact).

*: Reputation is important. One of the reasons copyright should not be straight-out abolished is its usefulness in making sure that words are correctly attributed and can be quality controlled, a virtue you are so used to you may never even think about until it is gone.

Re:Distribution restrictions

[cperciva]

They can copyright their exact words and can (and probably should*) control the distribution of those words, but copyright does not give them any protection of the facts contained within.

In my capacity as part of the FreeBSD Security team, I often receive emails -- including security advisories -- and forward them to other security people. I don't want to spend an hour rewriting the advisory; I just want to forward it.

*: Reputation is important. One of the reasons copyright should not be straight-out abolished is its usefulness in making sure that words are correctly attributed and can be quality controlled, a virtue you are so used to you may never even think about until it is gone.

The right to be identified as the author of a work (and equally, to not be identified as the author of a work that you did not produce) is quite separate from the right to restrict redistribution.

Re:Distribution restrictions

[Jerf]

Copyright is a lot of rights. I spoke against those who just want to reflexively abolish the whole lot without thought, not those who have thought about it.

Typical biased Slashdotter numbers

[Anonymous Coward]

Right, let's compare the flaw in a single kernel versus the ENTIRE OPERATING SYSTEM of Windows, GUI, shell, and associated apps like Internet Explorer as well as user-ran executable attachments in Outlook, which have nothing to do with Microsoft.

What happened to all the "Linux is just the kernel" stuff? Oh, that's right, we were bashing Microsoft.

Besides, if you mean "past year" as 2005, then this means Linux is first out of the gate.

Re:Typical biased Slashdotter numbers

[Elwood P Dowd]

Typical biased Slashdotter numbers

Whatever. You need to browse at a higher threshold. The +3 comments are all totally reasonable.

Re:Typical biased Slashdotter numbers

[IceAgeComing]

I've read plenty of -1 posts that deserved to be +5 but were simply a minority opinion that the moderators happened to disagree with on that day.

How do you know they deserved to be +5, because you liked them? If so, you're no better than the moderators you're complaining about. Ever think about that?

Re:Typical biased Slashdotter numbers

[Libor Vanek]

Show me some user-space program in Linux, which could gain you root? THAT's the main reason, why UN*X are generally more secured then Windows - absolutely clear separation of user rights. In Windows there lot of SW has to run at insanely high priorities so any bug in them leads in machine hacked. In Linux if there is bug e.g. in Mozilla, all it can do, is delete your documents but can never "attack" any other installed SW. Of course - there are some setuid SW in Linux, but there are only very few and they don't evolve much (no new features+bugs ;-)))

Re:Typical biased Slashdotter numbers

[IthnkImParanoid]

I've read plenty of -1 posts that deserved to be +5 but were simply a minority opinion that the moderators happened to disagree with on that day.

I get mod points fairly regulary. Link to some. I just browsed through the top level -1 and 0 posts on this story, and they were garbage.

Re:Typical biased Slashdotter numbers

[Elwood P Dowd]

You misunderstand my point. The dude is carping that great-grandparent is posting bad numbers (agreed) and that this is reflective of a pervasive bias on /.

But the dude is languishing at +2, while all the highly modded comments are totally reasonable. So right now, the story that /. is telling is COMPLETELY FINE. His carp is full of shit.

Re:Typical biased Slashdotter numbers

[archen]

His post is naturally tainted because of his terminology of "Windows" and "Linux". Windows IS the GUI, the shell and all that other crap that is installed by default. Any problem with anything installed by default is a hole in the OS.

Linux is just a kernel, taking vulnerabilties in "Linux" is irrelevent. You need to look at a distribution, and all distributions are different, and many FORCE you to choose options (even if you don't want to).

From my memory this is the first "Linux" privelege escalation I recall for quite a while, but it is also local. Windows has had probably about 10-12 in the last year, and many of those were remotely exploitable. (note those are vague ballpark estimations) But again you have to use the context of a distro for comparison.

Re:Typical biased Slashdotter numbers

[IceAgeComing]

Apparently, there are a lot of people like you who believe otherwise, supporting a pseudo-fascist opinion state where anybody who disagrees with the talking points are flushed out of the system.

So would you disagree with a moderator who marked this latest post of yours as an inflammatory troll? :-)

Re:Typical biased Slashdotter numbers

[possible]

Clearly you don't know what you're talking about. Exploitable software doesn't have to be setuid for someone to gain root. All the exploit has to do is modify your ~/.profile and modify your PATH to include a trojaned version of su or sudo or ssh or telnet that captures passwords. There's more to safe computing than simply choosing Linux and crowing about it.

Re:Typical biased Slashdotter numbers

[Elwood P Dowd]

And now it's not. But it's definitely not the official opinion of /., and it's definitely not the most popular opinion in this discussion.

Re:Typical biased Slashdotter numbers

[Libor Vanek]

You did not understand what I was talking about.

NEWS: "New local exploit in Linux kernel"
ORIGINAL POST: "1 local exploit in Linux kernel vs. 100s in Windows"
REPLY: "Do not compare Linux kernel and WHOLE Windows OS"
MY REPLY: "Bug in 99% of user space SW will not lead to root compromise of local machine. That's why we can compare (a sort of) Linux kernel and Windows OS"

Of course that having security bug in user-space program is problem but it's not so critical as bug in kernel but still critical enough. The issue is that if you care a bit about security, you can easily avoid this ~/.profile hack - just use full paths and you are 100% sure that you'll not use the trojaned version.

Re:Typical biased Slashdotter numbers

[justsomebody]

su, sudo, gdm, kdm, evidence????

Sorry, just trying to be funny:)

Re:Typical biased Slashdotter numbers

[attobyte]

Okay and Linux should be faulted for the smart design why? Linus says he likes the quote from Newton that says if I was able to see further it was only because I was standing on the shoulders of gaints. So Microsoft changed the OS design/research from 1960 and called thier OS better. I think they have shown they made a mistake.

Re:Typical biased Slashdotter numbers

[Quixote]

Whose fault is it that Microsoft decided to include the GUI, shell, Explorer, etc. into the "kernel" ? Can you have a WinXP machine without the GUI? I know I can have Linux box with Gnome/KDE/X11.

As long a Microsoft insists on throwing the kitchen sink into the "kernel", the comparison with the Linux kernel is fair.

Re:Typical biased Slashdotter numbers

[m50d]

No, we are comparing root exploits with root exploits. As someone else said, show me a root exploit in one of the other linux apps.

Re:Typical biased Slashdotter numbers

[owlstead]

Because, as they said themselves, they have INTEGRATED Internet Explorer in the kernel. Not the complete GUI of course, but a lot of the software that does matter. And Outlook uses Internet Explorer to (pre)view messages. In other words, from Outlook you can gain super user rights without many problems, as many virii already have demonstrated. Microsoft forgot the layered software idea, and therefore destroyed security.

Re:What, no remote exploit?!?

[lakeland]

Incidentially, the finding of exploits found in bind and sendmail has really slowed to a crawl.

It seems that, even though they were written in different times and without security as the first concern, a sufficiently large number of bug fixes will eventually result in code that is almost as secure.

Who has access to the systems...

[Vague but True]

True that some systems will be vunerable at a locally/physical level. But look at how difficult it is to gain access locally to that machine.

If we look at a standard office, the servers are normally under lock and key. If we look at a machine in your house, you probably lock your doors when your not at home.

All in all, this is not even close to the problem MS has with their exploits.

Re:What, no remote exploit?!?

[EnderWiggnz]

i thought that the reason the bind and sendmail bugs have driopped is because any sane sysadmin had stopped using them.

sudo?

[bsd4me]

The parent was modded as funny, but I have always wondered about a trojan that exploited sudo, possibly through a too-permissive NOPASSWD rule, or something that exploits the window where sudo doesn't prompt for a password.

Re:sudo?

[grumbel]

While it is true that 'sudo' can make it much easier for a hostile programm to get root, I don't consider it to much of an additional problem since for most uses getting access to a user account is already more then enough to cause serious damage. I can use up all the machines CPU and might even be able to crash it[1], I can delete the users files, I can send spam mails, I can spy and crack passwords (yppasswd), etc. no need to become root for any of those.

[1] simple shell one-liner ala: ":(){ (:&);:;};:&" is enough for that

Re:sudo?

[archen]

Well really you don't have to directly exploit sudo. You could for instance change the users path and point it at YOUR sudo which intercepts the password before passing it along to the real sudo (so the user isn't aware of what happened). Since the process is already running under the user's context that means the bad sudo can also use sudo to do whatever it wants to (I think that's how sudo works anyway)

Re:sudo?

[LuSiDe]

[...] since for most uses getting access to a user account is already more then enough to cause serious damage. I can use up all the machines CPU and might even be able to crash it[1], I can delete the users files, I can send spam mails, I can spy and crack passwords (yppasswd), etc. no need to become root for any of those.

You can do that when you have SSH access on your friend's desktop/server/router Linux computer residing in his mother's basement on a so-called broadband connection. A computer which is seriously configured and on which users have (shell) access to do Real work, you won't be able to do several or all of the above and even if you were able to do it then your account would be suspended and/or you'd be in trouble quite quickly.

For example, its easy to restrict outgoing connections or more specific restrict outgoing connections to any IP port 25. Actually, who says you're allowed to start a connection to anything? You assume you can use the computer to connect to 'the Internet' but perhaps it only accepts SSH to connect to it and HTTP to connect from it (either by root on that computer or some higher power). Or that and a connection to the corporation's SMTP server (which may or may not use a NIDS as well, which may or may not even detect wether you're spamming or so). Its easy to use something like SGI's CSA to restrict a user on a computer. Deleting a user's files is a laughable one. Anyone who takes himself seriously creates backups. Finally, YP is legacy. Really, the point is that home computers are of little concern and a majority but in serious environment you'll have to try better and there this matters.

Re:sudo?

[grumbel]

### You can do that when you have SSH access on your friend's desktop/server/router Linux computer residing in his mother's basement on a so-called broadband connection.

Yes, which is exactly my point. Sure you can protect the computer better, have it behind an intrusion detection, have multiple accounts, etc. however must people just don't do it that way.

### Anyone who takes himself seriously creates backups.

Just because you have backups doesn't mean that delete files is a non-issue, it just means that you can easier recover from it, you still will lose at least 12h of work or so, since most people will at most run their backups daily.

### its easy to restrict outgoing connections or more specific restrict outgoing connections to any IP port 25

Just use the machines sendmail, no need to start an own smtp server.

### Really, the point is that home computers are of little concern

How are they little concain? People store years of digital photos and them and other information that might be VERY important to them.

I personally care little about so called 'serious' environments, when the rest of the 99% people out there are stuck with more or less the defaults installs of the distros which are all pretty vulnerable even with only a user account (didn't Mandrake do 'xhost +' for a while at default?!).

Sure you can configure anything quite secure depending on how much workforce you put into it, most users however put exactly zero work into it.

Re:Wow...

[grahamlee]

Strong passwords won't help against the disgruntled-employee-h4x0r who knows one of the strong passwords, nor against the insecure getpwpit() function.

Re:What, no remote exploit?!?

[mm0mm]

where as every nearly every Windows flaw is remotely exploitable?

Don't you think it's more convenient for you to be able to hack multiple machines over LAN? Another reason to choose Windows over Linux.

I'm safe!

[ferratus]

It doesn't work on my Gentoo box running 2.6.9 so I'm safe. This machine will not be hacked.

It's a good thing I have telnet running on that box so that I could try it remotly though.

Re:I'm safe!

[Se7enLC]

Wouldn't work? or wouldn't compile?

I can't even get the example code to compile on my gentoo 2.6.9 system

Re:I'm safe!

[mattwarden]

You are falling prey to a confirmation bias. You can't simply try it once and assume you're safe. It exploits a race condition. See other comments above from people who had to try it 10 or 12 times in order to get it to work.

Re:I'm safe!

[gzunk]

It compiled first time on mine. I'm running it in a while true loop in bash at the moment, and it's not managed to succeed yet (>300 attempts so far)

Re:I'm safe!

[gzunk]

Well he may have tried it once, but I'm running it an a while true loop in bash on Gentoo 2.6.9 and I've got to 500 so far without a succesful exploit.

Re:I'm safe!

[hobbesx]

You are falling prey to a humorless bias. You can't simply read this post once and assume it's serious. It exploits an irony condition. See comments below from people who also only read this post 1 or 2 times in order to get it to unfunny.

Re:Failed on RHEL, Failed for gentoo

[bprice20]

./test

child 1 VMAs 0
[+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xdf800000 - 0xfee67000
Segmentation fault

Re:Failed on Debian 3.1 / 3.0

[Anonymous Coward]

Same compile errors, tried with gcc-2.95 gcc-3.3.5 gcc-3.4.

Re:Interested

[rewt66]

For purposes of this comparison, do you include IE as part of the Windows kernel?

This isn't just a slam at Microsoft's statements in the antitrust trial - there are architectural reasons to consider it part of the kernel. (Of course, those architectural changes seem to have been made solely in order to be able to make those statements at the trial, they seem insane from any reasonable perspective...)

Re:Interested

[COMON$]

How did this get modded flamebait....I just wanted to see the numbers.

Re:makes me chuckle.

[Anonymous Coward]

God your a loser. Nothing is perfect, that is if you define perfect as something that can in no way be improved upon. If however you take a more realistic view of perfect, such as perfect for the task, then many things can be perfect.

The idea that 'Once Linux gains enough momentum and is deployed on a meaningful percentage of business users desktops, hackers will deem it worthwhile to devote time to exploit it', while having some merit, is far too simplistic. Sure more "hackers" might attack Linux if it had more market share, but that doesn't mean that more exploits would be found, especially if the system is inherently more secure.

In addition, just because Windows is the most wide spread OS and likely to receive the most attention, does not excuse MS from its poor programming and implementation.

Re:Interested

[COMON$]

I am not sure, it would be interesting to see a full comparison between the two. Just lay out the numbers without people getting all up in arms about it.

Re:What, no remote exploit?!?

[Dr.Zap]

" Why is it every nearly Linux flaw is locally exploitable, where as every nearly every Windows flaw is remotely exploitable?"

That would be Microsoft's superior networking ability, along with it's user (or abuser) friendly interfaces!

yep

[cavemanf16]

This really does work!

1) Login with your userid
2) type 'su' at the command prompt
3) fill in root's password
4) ???
5) proceed to screw up your flaky linux install

Re:What, no remote exploit?!?

[fitten]

You are pretty much right... if no one uses something, it's probably pretty secure :)

I don't know of anyone who uses either anymore.

Big deal?

[t_allardyce]

Was linux ever even ment to be secure locally? You can stick it in single user mode, or just nick the hard-drive. Meanwhile IE is counting its 80th root exploit...

Re:Big deal?

[t_allardyce]

Ah was always taught local ment physical, sounds like a bit of a dodgy definition?

Re:Big deal?

[cnettel]

Meanwhile IE is counting its 80th root exploit...

How many IE exploits can you enumerate that gives you root if it's run as a limited user? Some have been discovered, but most are not and never have been. I would say that the general IE bug is one or two levels; spoofing your site identity as a trusted site to the user or the browser itself; from that trusted site download code and run it in the user context of the user running IE. From there on, a local root explot can come in handy to give you root.

Disclaimer: I know this is not the only way, but it is quite common.

Re:Big deal?

[I_redwolf]

Where do you people come from? It's like you enjoy talking giberish just to hear yourself speak.

"How many IE exploits can you enumerate that gives you Administrator if it's run as a limited user?"

Are you serious?

Disclaimer: No is this kid really serious?

I don't think you understand what local means

[Trepidity]

Local means "has an account on the machine". It does not mean "physically at the computer". This can be exploited remotely by anyone with a login account on the machine who can login via ssh or telnet. If you're running, say, a university's Linux server, this is a major problem, as now all your students and professors have root.

Re:I don't think you understand what local means

[Marxist Hacker 42]

Which is why you don't allow anybody to have ssh or telnet access to a mission critical machine. Doing so is a HUGE security risk to begin with.

Re:I don't think you understand what local means

[flosofl]

Which is why you don't allow anybody to have ssh or telnet access to a mission critical machine. Doing so is a HUGE security risk to begin with.

So, I'm gonna have send some poor schmuck from chicago to miami whenever I need to update my machines (for MySQL updates or something similar)? Why don't we just unplug the damn things from the network?

Perhaps that should read "...don't allow just anybody to have ssh..." When you have a systems admin, part of it is that you implicitly trust him/her to NOT run exploits on the machines - why would he/she anyway? They alreay have root. If you feel you can't trust them, they never should have been given that position.

Ssh is not a HUGE security risk, as you say. Allowing unfettered access to the machine is. However I do agree with the telnet issue. NEVER use anything that sends/authenticates in the clear on a mission crit system (really on ANY system - too many people use the same passwords on both pre-production and production systems). Telnet/FTP and others should NEVER be used. If you authenticate via a web server ALWAYS use SSL. Use TLS for SMTP. And son on. This is where a proper security dept comes into play - whether you call it TRM, InfoSec, Network Security,etc...

Re:I don't think you understand what local means

[Marxist Hacker 42]

So, I'm gonna have send some poor schmuck from chicago to miami whenever I need to update my machines (for MySQL updates or something similar)?

KISS- why not just have the machine in CHICAGO to begin with?

Why don't we just unplug the damn things from the network?

You mean you're running MySQL without a firewall between it and the internet to begin with?

Perhaps that should read "...don't allow just anybody to have ssh..." When you have a systems admin, part of it is that you implicitly trust him/her to NOT run exploits on the machines - why would he/she anyway? They alreay have root. If you feel you can't trust them, they never should have been given that position.

Reasonable- as long as they choose a very strong password and you have MAC filtering in your SSH to prevent other computers from logging in.

Ssh is not a HUGE security risk, as you say. Allowing unfettered access to the machine is. However I do agree with the telnet issue. NEVER use anything that sends/authenticates in the clear on a mission crit system (really on ANY system - too many people use the same passwords on both pre-production and production systems). Telnet/FTP and others should NEVER be used. If you authenticate via a web server ALWAYS use SSL. Use TLS for SMTP. And son on. This is where a proper security dept comes into play - whether you call it TRM, InfoSec, Network Security,etc...

And any security group that is worth their salt- will indeed be very paranoid about just any joe logging in.

Re:I don't think you understand what local means

[flosofl]

There is a machine in Chicago, and one in Miami, and one in Berlin, and one in London... (actually more than one at each location for load balancing). Part of the reason for having redundant machines in disparate locations (other than network load reduction - not insignificant) is for DR. If I lose the building with ALL my mission critical servers in it (say it burns to the ground), we're dead. I need to have hot sites available to get back within hours (well, minutes really) or we've potentially lost tens of millions in transactions (a LARGE international bank). In addition, if we were to move all our servers to a central location they would require a building all to themselves. Even just the critical systems would take more than one floor (and actually do). Now if I had a smaller shop (1000-2000 users) and I could take a couple days to get a offsite location up and running, I might choose to centralize the physical systems. But I can't and our executive staff would get nailed by due care liability from all the investors, creditors, and depositors.

Also, I never said it was accessable to the Internet. This is all internal (firewalled internally as well - with MAC filters, IDS, ACL, etc..). All of our servers (mission critical) are inaccessable from the Internet (and most of the internal network segments as well). That's why we have things like Frame Relay and ATM. Hell, we have a 10 person group whose only task is to keep track of the physical topology of the network.

I will agree with you that just by being networked at all makes them vulnerable. This is where Risk Assesment comes in. You have to balance risk with ease of use for end users and front-end systems. Part of that is how to recover quickly in case disaster. Part of it is how easily can the rest of the business units (the one's that actually make the company money) perform their jobs. What you try to do is minimize that risk by imposing some order of safeguards. That means following best-practices, implementing a rigorous patch test/release cycle, seperation of duties, etc... While there is risk in allowing ANY access to systems, I find selectively allowing SSH access to certain systems is a minimal risk that we as a business are willing to assume.

Don't get me wrong. I am not saying you are wrong at all. Your method is better than mine and many times I've wished I could do things that way (it would reduce my job complexity by an order of magnatude). Unfortunately, due to the nature of my business I do not have the option of centrally locating physical systems (my security operations are mostly centralized - it's easier to control and keep track of it, and make sure everyone is on track). Because of load and DR (and other reasons I haven't even touched on), I need to do things this way. While I AM at risk (the only secure system is one that's turned off and locked in a vault no one has the combo to), I do what I can to mitigate that risk and still be able to support the various business units in the company.

Re:I don't think you understand what local means

[Craig Davison]

'User' doesn't mean a logged-in human. It could also be, for example, the www or nobody or apache user that your webserver runs as. Combine an exploit that gets you rights as the webserver user with this exploit, and you have root.

Re:I don't think you understand what local means

[Marxist Hacker 42]

You mean you actually run your webserver on the same box that you keep more important data on?

Re:I don't think you understand what local means

[Marxist Hacker 42]

There's no need to worry about security on anything that isn't mission critical- if it's not mission critical, keep offsite backups on non-executable media and be done with it.

Re:I don't think you understand what local means

[Craig Davison]

No. Did you read what I wrote? I said the attacker could get root.

That means they could setup a warez server, launch other attacks, create a spam relay or any number of other things. It's disastrous even if your data isn't at risk.

Re:What, no remote exploit?!?

[canuck57]

Why is it every nearly Linux flaw is locally exploitable, where as every nearly every Windows flaw is remotely exploitable?

This is because there are so many holes in Windows command line it would be impossible to find them all. This is not a joke, if you can get any kind of executable access on Windows you can get admin.

isec.pl's guys rule

[diegocgteleline.es]

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

Re:isec.pl's guys rule

[gbjbaanb]

Perhaps someone should offer a job to those guys so they can audit parts of the kernel better

Yeah, lol. Microsoft.

Oh sorry, I though you meant, 'someone should offer these guys a job so they can audit the kernel better to find *more* exploits, allowing MS to publicise all these anti-linux holes' ;)

Re:isec.pl's guys rule

[LuSiDe]

Really? I'm not so sure on their way of acting in this one. I was looking in the text file and didn't find anything which said: "Linux kernel maintainers have been contacted" or "Workaround is X" or "Patch is under way". Nothing. Only about the problem but not about anything related to the solution. Since it seems like they're releasing a half-baked advisory with exploit in the wild while a patch or workaround ain't there it also seems to me more like a blackhat manner to me. Note that that's not due to Linux being the target, because i'm well aware they've made advisories for all kind of OSes. I'm merely noting what i described.

Re:isec.pl's guys rule

[diegocgteleline.es]

And why on earth do you think that they should give you answers to your doubts in THAT text file? What about subscribing to some security mailing lists?

In full-cisclosure they were accussed of not wanting to be "full disclosure" because they asked people not to release exploits for the vulnerabilities for a couple of weeks (the fix was already available, they was asking to give time to users to upgrade)

Re:isec.pl's guys rule

[LuSiDe]

And why on earth do you think that they should give you answers to your doubts in THAT text file?

Simple: I consider that part of the research. I consider it part of fill disclosure. Do A, do B. If not then no A+ but B-. This smells blackhatish.

In full-cisclosure they were accussed of not wanting to be "full disclosure" because they asked people not to release exploits for the vulnerabilities for a couple of weeks (the fix was already available, they was asking to give time to users to upgrade)

So? There's no corelation. If there was a Solution (preferably theoretical and practical) then i'd have no problems with the question of wether there's an Exploit, or not. I'd prefer the Exploit to come out after the Solution though.

Re:isec.pl's guys rule

[zCyl]

Linux is having too many kernel-level vulnerabilities

Having, or fixing?

Re:isec.pl's guys rule

[Alsee]

Only about the problem but not about anything related to the solution.

I am not familiar with the exactly what is going on behind the scenes in the bugged code, but assuming the person who wrote the security alert does fully understand it and is accurate in his descritions then I can follow exactly what is going wrong and why, and they *have* implicitly stated an almost trivial fix.

It is a race condition, something critical is being done in the wrong order. In a multi-tasking systen an attacker has a slim chance of being able to jump in in-between those two steps and abuse that incorrect in-between state.

The vulnerable code... mmap_sem is released prior to calling do_brk()

The problem/solution is do_brk() must be called with the mmap semaphore held.

If I *had* to attempt to guess and write a patch myself, I would simply move the line up_write(mmap_sem) down below the the do_brk instruction. That might not be exactly the right solution, but to whoever manages and understands that block of code, the fix is going to be absolutely obvious and equally simple.

I guess you have a point that he probably should have explicitly stated the exact patch so that pretty much any competent programmer could patch their own systems, but it does seem to me that he has implicitly told the kernal maintainers how to trivially fix the problem. You can probably already download a fixed kernal if you check with your distro maintainer.

-

Re:isec.pl's guys rule

[diegocgteleline.es]

both, which is good, true :)

Re: bugs in code

[Obliviously]

I remember recently reading that commercial software generally has several bugs (usually minor, not necessarily security holes) per 100 lines of code (line being terminated with ;). I also recall reading a long time ago in PC World Win 2K was about 16 million lines of code. XP being more or less a facelift to 2K we can assume there maybe is 18-21 million something lines of code. Based on 18 mil. and a very generous 2 bugs per 100 lines, in theory, Windows has approximately 360 000 bugs and holes of varying severity. Good job M$!!!

Its funny how all the 0.x versions of open source software I am running never seem to crash and burn like Windows (and commerical Windows software...3rd party developers make buggy software too)

Re:What, no remote exploit?!?

[andalay]

For instance, shatter attacks are still a very large threat for multi-user windows systems

Haha, I read that as "shatner" attacks.

Re:What's truly funny

[Anonymous Coward]

STFU! You should be posting these kinda things AC, like me!

not a physical exploit

[Trepidity]

This is exploitable by anyone with a local account on the machine, which includes those who can login over ssh. This affects literally thousands of servers. Now everyone with access to your Beowulf cluster has root on your Beowulf cluster. Every student that can login and use pine to read their email on your university's Linux email server now has root on the email server. Etc.

Re:not a physical exploit

[VB]

Then what's wrong with firewalling (or portsentry-ing) port 22 and just giving them webmail? Is there something else local users would need to do on the box that requires a shell?

Re:not a physical exploit

[BenjyD]

How do you suggest I log onto the cluster downstairs , compile and run my simulations without shell access? There are many thousands of servers out there which require ssh access to unprivileged users out there.

Re:not a physical exploit

[polysylabic psudonym]

Is there something else local users would need to do on the box that requires a shell?

I've got one user with access for (as far as I can tell) playing moonbuggy.

/me flips off isec.pl

[htmlboy]

why did they release exploit code before a fixed kernel was released and mirrored throughout kernel.org? and on a friday afternoon?

i'm not too impressed with the timing of this announcement, and i have to wonder what their motives were. it doesn't hurt their cause that slashdot is advertising for them.

please, people. there's no reason that a situation like this should ever happen.

Re:/me flips off isec.pl

[AKnightCowboy]

Agreed. People that release security announcements, especially a root exploit on Friday around 5pm should be shot. Now I need to wait around for 2.4.29 to come out so I can update my shell server. Son of a bitch.

Re:/me flips off isec.pl

[_Sprocket_]

why did they release exploit code before a fixed kernel was released and mirrored throughout kernel.org? and on a friday afternoon?

Check out my earlier post. Looks like someone leaked the exploit ahead of the "responsible disclosure" schedule.

Re:/me flips off isec.pl

[bob beta]

Whoops. It looks like 'security through obscurity' has again failed.

Re:/me flips off isec.pl

[WareW01f]

While I agree that it would be a good idea to give someone a heads up on the kernel team (an maybe even suggest a fix while you're at it) via say, personal e-mail, things are a bit different in the open source world than say Microsoft where it's easier to keep things behind closed doors. Besides that, for me at least, Friday at 5pm is about when I'd get to even worry about fixing something like this. So the timing works for me.

Personaly I say more power to people that are taking the time to find flaws in Linux and make them public in a manor other than letting a worm rip out. On the including the code, it looks like this is a tricky one to exploit. If someone finds an issue with my code, I thank them for showing me where it fails and how to reproduce it. It saves me time.

That and I think we need a little rattling now and again. Simply having the belief that you are running a secure system can lead to bad things. Reminds me of progs like AirSnort. Thinks like this are too easily brushed off as 'theoretical' until someone puts out code to prove it.

Re:/me flips off isec.pl

[hazah]

I would imagine that it's a good thing. This way someone with just a little incentive can look at the problem directly and fix it. I bet there are a lot more willing people to do that than use the exploit to do anything harmful. If we get a virus before a fix, I'd be surprized.

Re:/me flips off isec.pl

[MooseGuy529]

Um... isn't this how most security holes work? When's the last time Microsoft fixed a hole before you heard about it? Sure, it's nice not to have people trying exploits at all, but sometimes knowing about the hole in a timely fashion is more important than having a fix.

Re:/me flips off isec.pl

[wolfi]

From http://www.securityfocus.com/archive/1/386436:
first of all I must comply about the handling of this vulnerability that I reported to vendorsec. Obviously my code posted there has been stolen and plagiarized in order to put the blame on Stefan Esser from Ematters and disturb the security community. I really apologize to Stefan Esser for the inconvenience and thank him for his cool reaction - the plagiarism did work. Further steps must be taken to investigate the security leak on vendorsec.

Here's the exploit (-;

[MacJedi]

#!/bin/sh
echo "1|nux r007 3xp10|7 by 1c4m7uf"
cd /tmp
cat >ex.c <<eof
int getuid() { return 0; }
int geteuid() { return 0; }
int getgid() { return 0; }
int getegid() { return 0; }
eof
gcc -shared ex.c -oex.so
LD_PRELOAD=/tmp/ex.so sh
rm /tmp/ex.so /tmp/ex.c

Re:Here's the exploit (-;

[Erich]

For those not so versed in the way things work, here's what this does:

getuid() and geteuid() get the "user ID" and "effective User ID". This scripts makes a library that makes these functions return 0 -- signifying that you are the superuser. It doesn't actually make you the superuser, but it implements functions that pretend you are.

Anyway, then it compiles these functions into a library and tells the loader to link that library first. So when you start up a shell, it will call getuid() to figure out your userid, and your new library will tell it that you are userid 0. The shell prints out the root prompt instead of the regular one.

But this in no way actually gives you root privs, if you go to edit /etc/passwd you will not be able to.

Pretty funny joke, though, kind of like telling everyone that they can ftp to 127.0.0.1 using their own regular userid and password and find all the porn they could ever want...

Re:Here's the exploit (-;

[gnuman99]

On Debian, people can just use `fakeroot`

Re:Here's the exploit (-;

[nossid]

Excellent.

However, I propose an addition to the "exploit". Insert the following in the source:

int unlink() { sleep(100);return 0; }

Now get your "root"-prompt, run id to verify your user id to the unknowing victim and proceed to run rm -rf /, but try to keep a straight face, at least for a few seconds. Hilarious.

Wrong

[MXK]

It's not a bug... it's a feature.

Re:What, no remote exploit?!?

[flokemon]

Still, if you want to be fair, the most flawed application in Windows is by far Internet Explorer. Which I cannot UNinstall, and which is a full part of Windows. I can choose not to use it, but it remains in my system.

If any major Linux application had so many exploits, well I'd just remove it and use another one, end of story.

900+ lines PoC

[TheSurfer]

$ wc -l elflbl.c
906 elflbl.c

Wow... this is not your average vulnerability: a 900+ lines PoC :/
Guess this will take some time to fix.

Re:900+ lines PoC

[ryandlugosz]

there could be a quick patch that removes the uselib function unless the user has built in kernel support for something other than ELF binaries. From what others have posted, this is a legacy function that has long gone out of vogue.

Re: bugs in code

[AceCaseOR]

3rd party developers make buggy software too

And when some third-party developers write buggy code, they really write buggy code. Remember "Return to the Pool of Radience: Ruins of Myth Drannor". Now that was a buggy game!

Re:Interested

[MichaelSmith]

I would wager that if the world switched to linux tommorrow then next week we would see a fairly large number of new exploits. Would it be as many as windows...or would they be as damaging?

Probably now because unix software collectively has been around a lot longer than Windows and most of the exploits which were there originally have been fixed. Linux is a relatively new unix variant but it still benefits from the experienced gained in older variants.

When windows NT is 20 years old it will be much less buggy

Linux is soo insecure... *sigh*

[Azul]

It is surprising that, even though we are constantly finding local security vulnerabilities in Linux, some people still claim it is a relatively secure operating system.

These are exploits in the most basic portions, against which a sysadmin can do nothing other than keep on patching things. It's not like you could have tunned this system to make it very secure, no, no matter how carefully you (or your distributor) set it, bang, a local exploit seems to be found every month or two.

I'm seriously considering going back to BSD (maybe Debian GNU/NetBSD?), which seems to have a much much much better security track.

Re:Linux is soo insecure... *sigh*

[DashEvil]

Why Debian GNU/NetBSD instead of NetBSD itself?

Re:Linux is soo insecure... *sigh*

[Azul]

No particular reason other than me liking Debian a lot, I suppose. But you're right, maybe I should run the real NetBSD.

Re:Linux is soo insecure... *sigh*

[NullProg]

Have you considered running your server services in UML? Compromise the virtual environment all you want, but leave the host system pristeen.

Just a suggestion.
Enjoy.

what's that sound I hear?

[Trepidity]

It's the sysadmins of University email and webservers across the country going apeshit as suddenly the entire student body potentially has root...

Re:what's that sound I hear?

[scottking]

I wish there was a +1 Used 'Apeshit' in a sentence modifier.

Re:what's that sound I hear?

[DiscoOnTheSide]

meh, it just means I get to bitchslap anyone who tries this out of the university :)

Re:what's that sound I hear?

[trisight]

LOL yah I would vote for that :-D

Re:what's that sound I hear?

[woah]

Actually, my university and at least two others use linux on their servers.

And get this, my university has got around 100 x-terminals conected to a server running 2.6.9. :)

Re:What's truly funny

[BobPaul]

and anyone who disagrees will get modbombed by trolls.

That's not true. I still pretend that Linux and Mozilla are perfect and that windows is the only operating system with security flaws, and my post that states something to that effect is currently moderated troll...

Linux is not invulnerable

[Azureflare]

Linux is not invulnerable to exploits, as we all know. Therefore, why are people making such a big deal out of it?

It is important to know about, in my opinion. But that's just so we know we need to patch our kernels. Simply the fact that a root exploit has been found does not mean we should go about reposting the same types of stuff that has been posted endlessly before in similar articles on slashdot.

I prefer linux because it's free. It's also pretty stable and secure, which is nice. But I just like linux for what it is. I fear we are getting sidetracked in the "my OS has less exploits then yours, nanananaaaaa" childish type of fights.

I look forward to the updated kernel which will fix this issue for my distribution. Until then, I'm going to do some much needed maintenance on my box and barricade my room so no one but me can get in.... just kidding.

Re:Linux is not invulnerable

[donutz]

Linux is not invulnerable to exploits, as we all know. Therefore, why are people making such a big deal out of it?

You're new here, aren't you?

Re:What, no remote exploit?!?

[lakeland]

Sadly, no. You might be right that admins knowing what they're doing are not using them, but admins who don't know what they're doing are.

Most people in North America use RedHat products, and for whatever reason they default to bind+sendmail. Few of these people change off these defaults, so a lot of people are installing and running bind and sendmail.

Seems crazy to me, but RH must have a reason. And I hope it isn't just politics...

Fix is merged in mainline already

[spurious cowherd]

See the message on The kernel mailing list

raw diffs to for those brave souls who want them

Re:makes me chuckle.

[Canuck in Seattle]

ahhh, flamed by an anonymous coward. I was referring to the fact that it is incredibly easy for others to point fingers at the poor programming and implementation that you mention occuring over in Redmond. Last time i checked they recruit some of the brighest minds in the world (heck i didnt make it past lunch in my interview ;) and spend more on research and development than any other company in the world. I believe that their intentions are coming from the right place, however in practice they have issues (much like communism) since their ultimate goal is to appease shareholders by making money. Sacrifices (it seems) are made to get product out the door. The sheer infrastructure and process needed to build, deploy, and distribute, not to mention maintain software (specifically operating systems) would bring the linux world to it's knees in about a month should every MS product in the world dissapear. bet on it. I am by no means a large MS fan, however i find the holier than though attitude adopted by a large number of the linux crowd hysterical. This of course, is just my humble opinion. -R

here's a patch

[antonakis]

...though a bit big. www.openbsd.org

Yawn!

[erikharrison]

What news is this? There have been local exploits in the Linux kernel before, and there will be again. This is less news than the Debian break in a while back - that was worth mentioning because a major Linux installation was comprimised with an unknown kernel vulnerability. But come on! The last few 2.4 kernels (IIRC) have included patches to fix local root exploits. Marcello didn't even rush those out the door. This exploit certainly doesn't seem especially unusual nor was there an exploit in the wild.

Newsflash kids! Linux isn't perfect! Certainly not Linux specific API extensions like uselib. Move along, this isn't the kernel vulnerability you are looking for.

Re:FreeBSD

[sp0rk173]

See, I run FreeBSD because it feels like a more cohesive system than any other linux distribution i've used (Debian, Redhat, Fedora Core, Slackware, SuSE, Gentoo...which comes the closest..., Ubuntu, Mandrake), and it's a more responsive desktop than any linux distribution i've used as well. The whole...mature code with very few exploits...that's just an added bonus. It also feels the least kludgy on my opteron box. But, you know, don't tell anyone that. FreeBSD isn't supposed to run on modern hardware. So, we'll just keep that our little secret.

Major Difference

[Tony]

Why is using MS update any different than downloading this new linux fix?

First and foremost, the terms to which you must agree before you download and install. The MS downloads and patches often come with "interesting" end-user license agreements. Meanwhile, with the Linux kernel download, you can do whatever you like, including (*gasp*) fix it yourself, if you have the ability.

Secondly, when you use Microsoft update, you don't know what is getting installed. With many things, like XP service pack 2, you get a lot of cruft that is useless.

As far as popularity being the #1 indicator for available exploits: if that were true, Apache would be the most-exploited web server, since it has 65%+ of the market. Unfortunately, that's not true. IIS has many more published exploits, in spite of the fact that the code for Apache is available for inspection by the black-hats.

There *is* a such thing as "being more secure." Yes, we can't be perfect. (In fact, I don't believe there is a such thing as perfection.) But that doesn't mean that one OS can't be objectively better than another.

Re:Major Difference

[paranoidgeek]

Businesses only use IIS because they can buy it ( and get things like techs who have a certificate from MS [ yeah i know those "qualifications" are a joke ]).
Seriously do u think the head tech for a 10mil company would use something that didnt cost anything ?

I am currently building a CMS for a company, and the scripts are made to run on apache and PHP not IIS and ASP, why ? Because it doesnt matter to me whether it costs anything or not, but instead i look at other thinks ( like being about to run it on my 100MHz server at home while the site is being developed [ in the end it will be running on a two ~1GHz cpus ] ).

Anyway why dont we see worms that use an exploit in apache ? Even if all 65% is teenagers blogs they are just as suitable as zombie hosts ( *cough* blaster *cough*).

Re:Major Difference

[m50d]

Surely in that case you'd expect apache to be exploited even more, since its admins are likely to be less competent?

Re:What, no remote exploit?!?

[Beowabbit]

"A toy operating system, for the price of a real one!" (Shatner did some commercials for the Commodore VIC-20 where his line was "A real computer, for the price of a toy." Of course, the VIC-20 was pretty close to a toy, with its 22-column display and 5k RAM.)

Re:Interested

[scatter_gather]

This seems to be a common theme in the last few months, and the meta-mod system is failing in this regard. I have seen a LOT of posts that fail the rabid Linux fanboy test instantly get modded flamebait. Its sad to see since there are a lot of thoughtful ideas that never see the light of day once they get the curse of flamebait. Its harder to get rid of than gum on your shoe since lots of moderators seem to think that once they see the first flamebait label hit a post they need pay no further attention to it.

Combined with another flaw, it could be bad.

[khasim]

All that this needs is to be combined with a vulnerability that grants remote access to a machine and you have a serious problem (provided that the remote access allows them to exploit this).

All flaws need to be fixed. Even ones you don't think are very important because they could be exploited together.

It doesn't matter how many holes Windows has compared to Linux. The exploits are usually scripted and tied to a port scanner. If you're vulnerable, you will be cracked.

That's why multiple levels of security are a Good Thing (tm). Defense in depth is the only way to go.

Re:Combined with another flaw, it could be bad.

[sloanster]

All that this needs is to be combined with a vulnerability that grants remote access to a machine and you have a serious problem (provided that the remote access allows them to exploit this).

- and if we had some ham, we could make ham and eggs, if we had some eggs... seriously, we could play "what if" games all day long, but let's not blow this issue all out of proportion. It is what it is and nothing more, and at the end of the day it will have resulted in none of the sort of disasters we see on a regular basis with the microsoft platform...

Re:Combined with another flaw, it could be bad.

[killmenow]

A local root exploit is a serious issue even on single user machines. Now, you could argue that Linux users are more savvy and would not run unverified code...but I say that's only guessing and we have seen repeatedly how a little social engineering can get people to run unknown content.

I keep seeing posts here about somebody setting their grandma up to run $DISTRO but nobody will admit then that said grandma might be easily duped into clicking that link in that e-mail to get the latest cookie recipe (or some other nonsense) and woops! there goes a local exploit and now her box is Pwn3d!

It sounds like you're saying this isn't such a big disaster because there aren't that many Linux users...and that strikes me as a ridiculous point of view.

Re:Combined with another flaw, it could be bad.

[sloanster]

I keep seeing posts here about somebody setting their grandma up to run $DISTRO but nobody will admit then that said grandma might be easily duped into clicking that link in that e-mail to get the latest cookie recipe (or some other nonsense) and woops! there goes a local exploit and now her box is Pwn3d!

This sort of thing is not as easy as you suppose - in the windows world one can write a quick vbscript to cause all sorts of nonsense, but on a unixlike platform such as Linux there would be a considerably higher barrier to the success of such shenanigans.

It sounds like you're saying this isn't such a big disaster because there aren't that many Linux users...and that strikes me as a ridiculous point of view.

I see you've failed to understand my statement. I'm at a loss as to how my meaning could have been contorted from "a potential local exploit isn't going to cause the sorts of internet disasters as we see regularly with windows" into the bizzare statement "hardly anybody uses linux" - (strokes beard thoughtfully). We can put the lie to that sort of thinking by simply considering the apache webserver, it's market share, and security record, compared to the microsoft iis web server, it's market share and it's security record. And by "security record", I don't mean "counting the number of advisories from all linux vendors and comparing them to the number of advisories from microsoft", which is a meaningless comparison. No, I mean "compare the frequency, scope and severity of the security incidents associated with the two platforms", which would be much more telling.

Re:Combined with another flaw, it could be bad.

[miu]

Seriously, we could play "what if" games all day long, but let's not blow this issue all out of proportion

Dangerously wrong. It is incredibly common for web applications to have holes that allow execution of arbitrary programs. A "local only" vulnerability is the other half of the weakness an attacker needs to turn a simple coding or configuration error into a root exploit.

Re:Combined with another flaw, it could be bad.

[sloanster]

What is possible with "a quick VBScript" that is not possible with a "a quick Perl script"?

(shrugs) I could spend a lot of time and effort presenting to you the details how unix-like OSes handle security, but how about this: you go ahead and try to whip up a "quick perl script" to spread like wildfire through the linux systems on the net, and report back on your success, OK mr anonymous coward? That frustrating and fruitless effort will be a better education than I could ever give you.

Re:Combined with another flaw, it could be bad.

[Minna Kirai]

: you go ahead and try to whip up a "quick perl script" to spread like wildfire through the linux systems on the net, and report back on your success, OK mr anonymous coward?

The reason that's not possible TODAY is security through obscurity, which isn't something you should be proud to rely upon. The only thing you can prove through that line of argument is that Linux has no significant desktop marketshare.

In a future where Linux desktops dominate, it's entirely possible that an email client exactly as insecure as the current Microsoft Outlook will also become widely used.

Re:Combined with another flaw, it could be bad.

[ArtStone]

On vacation Christmast week?

The Santy worm -is- a perl script that exploits the hole found in the phpBB software. It copies files to /tmp (Windows doesn't have a /tmp directory, does it?) and then proceeded to spread to other *nix servers using Google to find likely targets - and destroy the contents of the *nix web server. Estimates are that 40,000 *nix servers were infected.

Even in the unlikely event a Windows web server had perl installed and and was running the phpBB bulletin board software, there is no wget command in Windows, and no /tmp directory.

Re:Combined with another flaw, it could be bad.

[sloanster]

The Santy worm -is- a perl script that exploits the hole found in the phpBB software. It copies files to /tmp (Windows doesn't have a /tmp directory, does it?) and then proceeded to spread to other *nix servers using Google to find likely targets - and destroy the contents of the *nix web server. Estimates are that 40,000 *nix servers were infected.

Actually, the webserver id does not have the rights to "destroy the contents of the *nix web server" on any web servers which I have access to (admittedly mostly SUSE, and quite standard). The concept of "least privilege" is an example of the unix way of doing things, and mitigates the damage that can occur when 3rd party applications have security holes like this. While it's possible to set up an insecure application and give it way too many privileges, that's not how the vendors ship the OS, so don't try to pin that on linux.

Even in the unlikely event a Windows web server had perl installed and and was running the phpBB bulletin board software, there is no wget command in Windows, and no /tmp directory.

So the fact that windows lacks common unix facilities somehow becomes a plus? LOL, windows lacks a lot of things, e.g. a standard email facility, but the virus writers quickly got around that by bundling their own smtp engines, thus we have by some estimates 80% of the spam on the internet sent by swarms of worm-ridden windows nt/2k/xp PCs. The lesson there is that lack of features is no guarantee of security!

Re:Combined with another flaw, it could be bad.

[sloanster]

The reason that's not possible TODAY is security through obscurity, which isn't something you should be proud to rely upon. The only thing you can prove through that line of argument is that Linux has no significant desktop marketshare.

I don't think you understand what security through obscurity is, and your reasoning is the same old joe sixpack thinking that we've heard before, that linux has a better security record only because it has a smaller user base than microsoft windows. By that same logic, apache should have a horrible security record - and yet, although the apache source code is open to the world, it has both a significantly higher market share, and a better security record than the closed source iis.

Re:Combined with another flaw, it could be bad.

[TobiasSodergren]

+1 insightsful

Re:Combined with another flaw, it could be bad.

[m50d]

The point is we do now have some eggs. IIRC there was a cups exploit a couple of weeks back which would do for the ham. So if a cracker had this vulnerability 2 weeks ago, he would have a remote root. And realistically, given the amount of servers there are, he probably does have a remote access vulnerability in *something*, giving him a remote root.

Re:Combined with another flaw, it could be bad.

[m50d]

Getting the email client to run it in one click. Also, thanks to setuid binaries and a long term security model granny can actually use linux without knowing the admin password, which is simply not possible on windows due to things like CD burning and lots of win9x apps that need write access to the registry. (If you can socially engineer her into chmod +xing your perl script, I can socially engineer her into entering her admin password when I ask for it)

Re:Combined with another flaw, it could be bad.

[IamTheRealMike]

That's not true at all, try creating a .desktop file that looks like a Word document but which actually runs a program then attaching it to an email in Evolution.

Re:Combined with another flaw, it could be bad.

[Minna Kirai]

I don't think you understand what security through obscurity is,

Ah, an early contentder for the 2005 Twirp-Pudge Award for auto-crimination.

"Security through obscurity" means that you survive because nobody's attacking you. Keeping closed source is one way to temporarily stave off attacks (only functioning until someone gets the motivation to reverse engineer), but having a low user base is another.

I can have the buggiest, hole-ridden code imaginable, published under the GPL, and as long as only 2 or 3 people use it on the entire internet, it's safe. Popularity will destroy that obscurity more effectively than open source ever would (although it's also a factor, but at a ar lesser scale)

that linux has a better security record only because it has a smaller user base than microsoft windows.

A huge proportion of Window's effective flaws- the ones that are actually exploited to in rapid, worldwide blowouts- are mostly due to inept users clicking on things that should obviously be suspect. What we often call "Windows vulnerabilities" are usually not actually in Windows (the OS), but applications hosted on Windows. The motivation for stupid people to run bad applications won't go away if they move to Linux.

By virtue of being non-default, Linux is only used by users who've already crossed a high threshold of attentiveness and involvement (or who are under the care of a pro-active administrator). Popularity will take all that away.

I've seen flaws in Linux mailreaders just as bad as anything in Microsoft Outlook, yet there were no devastating epidemics- and the reason really was smaller target population.

Re:Combined with another flaw, it could be bad.

[Lost Race]

Actually, the webserver id does not have the rights to "destroy the contents of the *nix web server" on any web servers which I have access to (admittedly mostly SUSE, and quite standard). The concept of "least privilege" is an example of the unix way of doing things, and mitigates the damage that can occur when 3rd party applications have security holes like this.

And that is exactly why local privilege escalation bugs (you know, what this entire discussion is really about) are so important! Remember how you pooh-poohed the issue, calling it a string of unlikely "what-ifs"?

http://linux.slashdot.org/comments.pl?sid=135324&c id=11292553

Just clip a privilege escallation exploit into a web server worm, and *voila* your box is fully-0wned even with httpd running as nobody!

Re:Typical anti-slashdot bias

[KarmaMB84]

So you live in Ballmer's fantasy land when posting? If so, then you'll have to admit that the GPL is viral and encourages Communism and software piracy. YEAH!

2.6 kernel

[beattie]

I am running 2.6.10 and I just get a segfault when running this. Anyone else get it to work?

Re:What, no remote exploit?!?

[Taladar]

This is simply a bad design decision. Running everything (including GUI and other things where this is totally unnecessary) as root/Admin is not a good design. Running as few things as possible with maximum rights (and everything with minimum rights necessary) is the best design from the security point of view.

Re:What, no remote exploit?!?

[Dahan]

Yeah, those guys running the root DNS servers are mad crazy insane!!

$ for l in a b c d e f g h i j k l m; do
> printf "${l}: "; host -c chaos -t txt version.bind ${l}.root-servers.net | tail -1
> done
a: VERSION.BIND text "VGRS2"
b: VERSION.BIND text "8.4.1-REL"
c: VERSION.BIND text "8.4.2"
d: VERSION.BIND text "8.4.4"
e: version.bind text "9.2.3"
f: version.bind text "9.3.0"
g: Host version.bind not found: 2(SERVFAIL)
h: version.bind text "NSD 1.2.3"
i: version.bind text "contact info@netnod.se"
j: VERSION.BIND text "VGRS2"
k: version.bind text "NSD 1.2.4"
l: VERSION.BIND text "named-8.4.1"
m: VERSION.BIND text "8.4.5-REL"

Looks like about half of them are running BIND.

P.S. I run BIND and sendmail on a server at the office, and BIND and postfix on a server at home.

Re:What, no remote exploit?!?

[sydres]

only if the apache account had gcc rwx accesswhich it should not have

Re:telnet is *not* safe

[mattwarden]

Welcome to humor. It might take a day or two for you to become sufficiently acclimated.

Just be an honest professional-not a biased Zealot

[EraserMouseMan]

Yep, a security flaw allowing unauthorized root access is undeniably embarrassing. It also seems that us Linux zealots suddenly have a life this weekend and aren't able to submit too many biased excuses for this /. news item. Oh wait, maybe our Firefox browser got hacked and we're just downloading/installing patches. A lot of bad Open Source news for an otherwise good weekend. Oh well, no OS is perfect.

How do universities, etc. deal?

[achebe]

So how does a university or comparable large organization with hundreds or thousands of users with shell access deal with a situation like this?
There is no patch for this yet right?

Re:How do universities, etc. deal?

[xenocide2]

You kid right? Typically, Linux is treated as a lepper colony by the University administrations. They usually get a good deal on Solaris systems so that's what they use for mainframes. Certainly a few CS/IS professors may use Linux as a testing ground for some sort of reserarch, perhaps something like extensions to MOSIX. But those workstations running linux probably already have eight local vulnerabilites. Just try pulling up a shell and running uname -a on it. How out of date is your kernel?

But what do you want them to do? Kick you off every time a kernel exploit is found so they can patch it? That can't be fun.

Re:How do universities, etc. deal?

[JonMartin]

Well, it's Friday at 1730 as I type this. I'm about to download 2.4.29-rc1 (which has a fix). Then I'll shoe horn some oddball patchballs into it (they haven't applied cleanly in a few kernel revs), config, make and test. If all goes well I'll be rolling it out and rebooting our ~150 Linux boxes by 1900.

In short, this one is too big (too exploitable, too public) to wait until Monday.

My life would be so much easier if profs didn't have such a hard on for Linux and let us admins install OpenBSD. Good thing I get paid overtime. Oh wait, I don't.

Re:How do universities, etc. deal?

[caluml]

If I thought for one second that users on my boxes would try this (or even know about this), I would change sshd_config so that only I could log in, restart it, and kill off everyones sessions. I would also take steps to avoid people being able to run commands on the system via other means. I would just tell them on Monday that in the interests of security, I had to do it.

Thank God...

[mackman]

Thank God I run Firefox!

Gentoo Ebuilds?

[gururise]

I'm running Gentoo.. Where can I get the ebuilds for this?
=)

Re: bugs in code

[stecoop]

I don't know what sigma level Microsoft is at but with 2 defects per 100 is 360000 per 1,000,000 lines of code. That puts them at a sigma level between 3 and 4. The Majority of software makers are below that. Yet if MS were six-sigma (they sell software that tracks it) they would have only 61 defects for those 18 million lines of code. NASA isn't six-sigma as there are only a few companies in the world that can achieve that kind of quality. Its like purifying gold - it gets exponentially tougher and tougher the purer you try to achieve.

Re: bugs in code

[archen]

Windows has approximately 360 000 bugs

Well based off of what you say, software is never improved nor fixed. Generally I'd say mature and tested software will have significantly LESS bugs than what you say. Note that a lot of crap qualifies as being a part of windows 2000, notepad, telnet, and a slew of other stuff know one knows what to do with. Some of this stuff has been drug along since NT4 or earlier, so I would say that the core windows os has much less than 360,000 bugs, even if you do coun't the garbage with it. I'm also wondering if those bugs cover logic errors where all code is correct, but there are still problems between layers and modules. God knows windows' complexity breeds enough of that...

this could be bad

[sydres]

if a virus writer wrote a virus; oviuously. that used this exploit to raise its permissions to root

Re:What, no remote exploit?!?

[aardvarkjoe]

I can choose not to use it, but it remains in my system.

So? It's not like IE can be exploited if you don't use it anyway. Whether or not those bytes on your hard drive happen to be a copy of IE is completely irrelevant as for as your security is concerned.

Maybe.

[jd]

It depends on how secure you want your system. Intel's new chips with built-in DRM, for example, would allow you to have a system where you couldn't remove the hard drive and install it elsewhere, or reboot into something that'll give access, using a live OS CD.

Atmel, amongst others, produce encrypted RAM. If you don't have the key, you can't read the memory. That's pretty secure, if you ask me.

Any OS with B1 (or better) security has comprehensive mandatory access controls, so that if you DO find an exploit somewhere, it is still not possible to access other parts of the system. (B-class and A-class OS' do not "need" a system admin account, since you can define specialised pseudo users that can do exactly what is needed for a given task and no more.)

Then, there are systems like OpenBSD which have been audited to hell and back. OpenBSD has had one provably-usable exploit in living memory.

Then, you've various security software that's out there. eg: Using OTPs w/ S/Key or OPIE for passwords, enforcement of strong passwords, IPSec w/ strong host authentication on all network connections, etc.

In theory, there is nothing to prevent someone from combining all of these elements to produce a hardened OS that is impervious to both physical and logical attacks, both locally and remotely.

In practice, nobody would spend the time and/or money on that level of security for normal use. Ok, the NSA might, but that's not strictly "normal use". It's also unlikely they'd make such an OS readily available. (They've done wonders with SE-Linux, and the declassifying of Skipjack and SHA has made a world of difference in cryptography, but that's not quite the same as Open Sourcing a bullet-proof system.)

Re:Maybe.

[babyrat]

In theory, there is nothing to prevent someone from combining all of these elements to produce a hardened OS that is impervious to both physical and logical attacks, both locally and remotely.

Well actually, in theory it is impossible to make an OS that is impervious to both physical and logical attacks, both locally and remotely. Best you can do it make it unfeasible to penetrate - ie take longer to get to the information you want to hide than matters - who cares if someone can decrypt your algorithm if it takes them 4 billion years...

Re:Maybe.

[ConsumedByTV]

Did you just say encrypted RAM?

For those who say "just a local exploit..."

[erroneus]

This means only that it must be used in conjunction with a process that is exploitable. Let's say, for example, apache was running and there was an exploit available to it. Well, most people would say "oh well.... can't trash the whole machine, the apache user doesn't have the rights." Well once apache is compromised, they can likely find a way to inject the local exploit code for the apache user to run. Once that's accomplished, apache user becomes root user. From there, the machine is 0wned to borrow a word.

Yes it's serious but I expect a fix shortly...

Amazed...

[windex82]

Wow, I'm quite amazed at the ammount of people who post here that don't know what is ment by a "local" exploit.

But I guess the good news is for every post who dosn't get it there are 4-5 people correcting them.

Re:Amazed...

[The_Chicken_205]

But I guess the good news is for every post who dosn't get it there are 4-5 people correcting them.

The same 4-5 people? :D

Re:What, no remote exploit?!?

[gothfox]

If you look at something like Redhat, which is a distribution, you have more of a comparison, and you will find remote exploits.

This comparison is not very fair. Linux distributions are much more modular and a lot of alternatives for critical software like MTAs are available.

If you use Windows you are stuck with a lot of stuff you can't dispose of. Good, solid, exploit-proof stuff like mshtml engine and various RPC-based services.

Re:telnet is *not* safe

[Trixter]

Who's the moron who modded this up as Informative? Guys, the OP was kidding.

Re:I'll give you one

[nofx_3]

You are just giving support to all the linux zealots out there. So what you are saying is that its worse to have a kernel exploit, than to have an os which can be crashed and seriously exploited from userland programs? I don't think so, linux tends to be pretty good at prevent user space programs from accessing or exploiting the kernel and thus crashing the system, windows has serious problems with this... like why are the web browser and user interface directly tied into the kernel.

-kaplanfx

Test for 2.6?

[BoldAndBusted]

Is there a similar test for this vulnerability for 2.6 and gcc v3.4.* out there yet?

Doesn't work on 2.6.10-gentoo-r2

[hakr89]

child 1 VMAs 0
[+] moved stack bfffc000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xdf800000 - 0xfedc9000
Segmentation fault

Re:Doesn't work on 2.6.10-gentoo-r2

[WanderingGhost]

Same for Debian sid running linux-2.6.10-bk6 (pristine from kernel.org).

child 1 VMAs 0
[+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000Segmentation fault

Is this real?

[agurkan]

May I recommend that Do not run this code if you can not understand what it is doing.
For all we know, this is a social engineering trick to spread some malicious code. Let's wait until some official folks eg. CERT, or your vendor/distribution responds. Are the people who released this code have some credibility that can be verified independently?

More vulns?

[EdMcMan]

Grsecurity and PaX report vulnerabilities

Fixed kernels

[unixmaster]

2.4.29rc1 ( http://www.kernel.org/pub/linux/kernel/v2.4/testin g/patch-2.4.29-rc1.bz2) and 2.6.10-ac6 ( http://www.kernel.org/pub/linux/kernel/people/alan /linux-2.6/2.6.10/patch-2.6.10-ac6.bz2) fixed this exploit.

I know of at least another 10 holes discovered...

[diegocgteleline.es]

I just wrote down them on this commentary on the thread above...http://linux.slashdot.org/comments.pl?sid= 135324&threshold=0&commentsort=0&tid=172&tid=106&m ode=thread&pid=11291472#11291873

XP has had much less holes in the kernel. Most of the Windows holes are in the system services or in the apps - not in the kernel.

Re:What, no remote exploit?!?

[Foolhardy]

Shatter attack

It's a problem with Win32 messaging if windows aren't secured properly. It's possible for a process to send windows messages (the ones inherited from Windows 1.0) to another process, regardless of what account the processes are running as. There are a few messages (WM_TIMER esp.) that, as a parameter, take an address for the owning thread to jump to. You can also fill the contents of a text box with a message.
Process A is a privilieged service running as SYSTEM. Process B is a malicious program running as a restricted user.
A creates a window on the interactive desktop (a big no-no) with a textbox in it.
B fills the textbox with exploit code with a message and then sends a WM_TIMER or similar to A with the exploit's address. A is now executing the exploit code.

First, there are ways to divide the window handle space into seperate parts, each securable with desktop and window station objects. Both of these are kernel object types with ACLs: you can't send a message to a window unless you have access to the conaining desktop.
Also, the JOB_OBJECT_UILIMIT_HANDLES flag for Job objects will prevent messages from leaving the job.
MS guidelines specifically forbid the use of windows from a priveleged process from appearing on the interactive desktop, since NT 3.51, for this reason. This doesn't stop many third-party app developers from creating insecure apps (virus scanners esp.) that do just that.
Winlogon's windows (press ctrl+alt+delete) are safe because they are on a seperate desktop that normal users can't send messages to.

Re: bugs in code

[hostyle]

What is this? A troll fight I'm presuming. Have either of you ever examined MS source code?

Unfortunately not the only one...

[greppling]

LWN article about some more local security holes in Linux published today. The advisory does contain some harsh words about Linux security as well.

I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version.

And given his description of how he found these problems, plus his frustration about getting Linus and akpm to reply, his tone is even somewhat understandable.

Re:Unfortunately not the only one...

[Anonymous Coward]

From TFA:

Between December 15th and today, Linus has committed many changes to
the kernel. Between January 2nd and today, Andrew Morton has committed
several changes to the kernel. 3 weeks is a sufficient amount of time
to be able to expect even a reply about a given vulnerability. A patch
for the vulnerability was attached to the mails, and in the PaX team's
mails, a working exploit as well. Private notification of
vulnerabilities is a privilege, and when that privilege is abused by not
responding promptly, it deserves to be revoked.

Yawn.. oh well. I'm sure someone will point out how this is MUCH faster than the turn around that M$ will give. But hey.. this is Slashdot after all.

Re:Unfortunately not the only one...

[Pastis]

Linux receives way too much more mail to pay little attention to the ones not coming from his lieutenants.

Maybe if he was using the correct channels to report security, he would get listened?

Like going through Debian or any other distribution?

And second, end of December is perhaps not the best time of the year to be listened to, don't you think?

Furthermore, sending this message into the open on a Friday, don't you think that's not acceptable?

And to those who run applying the fix, shouldn't you be waiting for an official patch.

Damn LKML-CNN reporting.

Re:Interested

[bob beta]

There isn't even an architectural reason to consider the Win32 subsystem as part of the NT kernel. The laywered model of Windows NT means that almost nothing that is directly manipulable is in the kernel.

Get. A. Clue.

Unpatched, but protected

[grasshoppa]

I am unpatched ( at the moment ), but ultimately protected.

Why? My system has many different partitions, most of which have the no-exec flag set on mount. So, unless you are able to log in as someone other than yourself, AND that other account has some area to run executables, my system is safe. Not that I'm not going to patch it anyway.

Re:What, no remote exploit?!?

[shaitand]

Windows is a distribution, an operating system IS a kernel.

Semantics aside however, your right, comparing apples to apples gives a better comparison.

The minimal windows install versus a minimal redhat install is a better comparison and there aren't many linux distros in which you'll ever find remote exploits in the core minimal install.

It's still not perfect though, pretty well everything can be stripped from a linux box to harden it. A windows box cannot be hardened since most remote exploits are in core services and you can't remove or replace them in windows (the most famous example being IE).

What cracks me up is that 2K/XP are touted as being an excellent step toward security and yet it's NT based systems which suffer from the most severe viruses and exploits.

Human make errors

[clamothe]

If you are paranoid, go with OpenBSD. Those guys rarely have exploits. If you're not paranoid, go with FreeBSD, linux, or whatever. Human's coding can result in bugs/exploits. Since Human's code all Operating systems, there are going to be bugs/exploits. If you are paranoid, but don't want to go out of your way to be it, use FreeBSD or Linux, and remember to recompile your kernel (30 minutes maybe?) whenever there's a bug you're worried about.

Re:What, no remote exploit?!?

[AndroidCat]

Shatner attacks are scary indeed.

Re: bugs in code

[archen]

And my post is trolling how?

Yes I've looked over MS code and no I didn't find anything good or bad about it - mainly because I don't care.

Re:Interested

[rewt66]

Right - "part of the OS" is not the same as "part of the kernel".

My bad...

Re:What, no remote exploit?!?

[julesh]

Shatter attack

It's a problem with Win32 messaging if windows aren't secured properly. It's possible for a process to send windows messages (the ones inherited from Windows 1.0) to another process, regardless of what account the processes are running as. There are a few messages (WM_TIMER esp.) that, as a parameter, take an address for the owning thread to jump to.

I thought MS issued a hotfix for this a couple of years ago, around about the time XP SP1 was released, I thought.

You can also fill the contents of a text box with a message.
Process A is a privilieged service running as SYSTEM. Process B is a malicious program running as a restricted user.
A creates a window on the interactive desktop (a big no-no) with a textbox in it.

You're right that that _is_ a big no-no. MS's documentation has always told people not to do that. When installing services you have to specifically instruct the system to allow them to interact with the desktop; by default they do not have permission to do so. The API documentation states "Services running in an elevated security context, such as the LocalSystem account, should not create a window on the interactive desktop, because any other application that is running on the interactive desktop can interact with this window," and (IIRC) did so clearly even before this exploit was made public.

So why, when security flaws are caused by applications doing something that the Windows API documentation specifically instructs them not to do, is this considered a flaw in Windows?

your wait is over.

[twitter]

*awaits justifications and explanations of why this is nothing like Microsoft*

While I can't justify the difference, I'll tell you that there is one if we don't see any regularly recurring network born auto-root that's so bad it threatens the top level domain servers. It's not like someone cracked kernel.org and owned it for three months injecting whatever they pleased into the codebase. One good explanation of the difference is that Marketing dorks who do little more than buy other's code can't maintain it properly.

Re:your wait is over.

[dedazo]

It's not like someone cracked kernel.org and owned it for three months

No, just GNU.org http://uk.builder.com/manage/work/0,39026594,20277 728,00.htm

Re:your wait is over.

[ArbitraryConstant]

The difference is simple.

A local root exploit gives anyone root on a Linux box until it's patched. The interface stays the same.

On Windows, the messaging interface allows any program to gain admin privs at any time. It can't be disabled or changed without breaking compatability.

That's the difference.

Re:What, no remote exploit?!?

[shaitand]

This would be false. It's not the gui front end most people recognize as IE that is the problem. It's the renderer and trust model behind it.

The same flawed engine is used to display your folders (turn on the location bar and type in a url, see what happens), your desktop, and your email in Outlook express and even most 3rd party apps. If you use AOL, it uses IE to render web pages. When you view a help file, guess what it's IE. It is impossible to avoid IE on a windows system.

By choosing a browser which uses it's own renderer and an email application that does the same, you ARE at least reducing the opportunity for 3rd party sources to access the renderer and it helps a great deal. The problem your left with then is that apps like firefox are still dependent on IE's trust model (the entire trust model of the OS is built around it) when running on windows. This is why almost every major "exploit in firefox" only affects firefox on windows.

There are plenty of other broken pieces in windows, but I've tried to stick to examples of why simply not using IE still leaves you vulnerable on windows.

On windows your best bet is to run as an unpriv'd user as much as the OS allows, use 3rd party email and browser apps (that use a different renderer). And don't forget to stick it behind a firewall that isn't running windows or better just keep it off the network. Also never put a disk in a windows box that came from outside your network unless it is from a known publisher and you've scanned it for viruses on a disconnected machine. Aside from that, you really just have to pray.

None of that is saying any particular other OS is secure, that's another matter entirely. I'm just saying that clearly windows is NOT and you CANNOT remove the components needed to lock it down.

Re:I'll give you one

[idiotnot]

It's not like BSD is immune from kernel exploits.

I use both linux and BSD. They both have problems from time to time....kernel-level problems. Admittedly, user-space programs are easier to fix, but there's problems everywhere. I also kind of laugh when I go to netcraft and see a FreeBSD box with a gazillion-day uptime. It would probably be pretty damn easy to root one of those boxes.

Slashdot summary

[DugzDC]

no time to RTFA, still at work. Can someone give me a technical summary of how this works. Just interested. Plus, you guys usually offer more useful/terse/comedic info than the bulletins.

Re:Failed on Slacware

[Technetium Web]

compiled cleanly with 2 warnings
rootexploit.c: In function `check_vma_flags':
rootexploit.c:530: warning: deprecated use of label at end of compound statement

./elflbl

child 1 VMAs 0
[+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xff400000 - 0xffffd000
[-] FAILED: open lib (/dev/shm/_elf_lib not writable?) (Permission denied)
Killed

what does this mean?
there is nothing in /dev/shm, should there be?

Re: bugs in code

[hostyle]

And my post is trolling how?

The lack of any actual facts, merely lots of conjecture, by both/all of you.

A fix for this in 2.4 has been published

[TimFreeman]

The change log for 2.4.29-rc1 says it has a fix for this.

I can't find an analogous note in the 2.6 changelogs.

Mod up: +1 Informative and interesting.

[Ayanami Rei]

Re:FreeBSD

[Anonymous Coward]

You need clever people to find an exploit on FreeBSD.
You just need a kid to crash your Linux box several times in several different ways.

Yip!

[jd]

You might want to take a squint at Atmel's "CryptoMemory" products. (Atmel is, I believe, the company that produces the space-hardened version of the LEON, which is the ESA's GPLed Sparc64 clone.)

A lot of the companies involved in space hardware do really cool stuff. (No pun intended. :) Atmel are not the cheapest company around, but then they sell stuff to the ESA and NASA, so why would they need to care? Even so, I wish they were a bit more geek-friendly.

The university system lacks /dev/shm support.

[Ayanami Rei]

Change the location of _elf_lib to /tmp instead. That'll work.

SELinux

[jgardn]

I'm glad I upgraded to Fedora Core 3, and left SELinux running, despite the problems with MySQL. Even if you can get a root account, if you don't have the right roles, you are still locked in a tiny little box without a key.

Re: bugs in code

[ClosedSource]

"NASA isn't six-sigma as there are only a few companies in the world that can achieve that kind of quality."

So which companies are six-sigma and what do they produce? IMHO any software "quality" standard that certifies companies rather than products is inherently flawed.

Doesn't work on Gentoo 2.6.9

[Kupo]

Of course the exploit sample code specifically says only tested on 2.4... [joshuaa@nemo joshuaa]$ uname -a Linux nemo 2.6.9 #1 SMP Tue Nov 30 15:21:17 PST 2004 i686 Intel(R) Xeon(TM) CPU 2.66GHz GenuineIntel GNU/Linux [joshuaa@nemo joshuaa]$ gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs Configured with: [abbreviated] Thread model: posix gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) [joshuaa@nemo joshuaa]$ make test gcc test.c -o test test.c: In function `check_vma_flags': test.c:545: warning: deprecated use of label at end of compound statement [joshuaa@nemo joshuaa]$ ./test child 1 VMAs 0 [+] moved stack bfffd000, task_size=0xc0000000, map_base=0xbf800000 [+] vmalloc area 0xb5c00000 - 0xffffd000 [-] FAILED: open lib (/dev/shm/_elf_lib not writable?) (Permission denied) Killed

Re:Doesn't work on Gentoo 2.6.9

[Kupo]

So much for missing the Preview button...

[joshuaa@nemo joshuaa]$ uname -a
Linux nemo 2.6.9 #1 SMP Tue Nov 30 15:21:17 PST 2004 i686 Intel(R) Xeon(TM) CPU 2.66GHz GenuineIntel GNU/Linux
[joshuaa@nemo joshuaa]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs
Co nfigured with: [abbreviated]
Thread model: posix
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
[joshuaa@nemo joshuaa]$ make test
gcc test.c -o test
test.c: In function `check_vma_flags':
test.c:545: warning: deprecated use of label at end of compound statement
[joshuaa@nemo joshuaa]$ ./test

child 1 VMAs 0
[+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xb5c00000 - 0xffffd000
[-] FAILED: open lib (/dev/shm/_elf_lib not writable?) (Permission denied)
Killed

Re:Microsoft Commits $3.5 Million to Indian Ocean

[benna]

Only 3.5 million? Don't they have tens of billions in the bank? They should donate maybe half a billion.

Re:Failed on Debian

[ecliptik]

I got it to compile and run on Debian Sarge with gcc version 3.3.5, kernel 2.4.25-1-386, and it says it succeeded, but I'm still my normal UID, just drops me into a bourne shell:

micheal@jezebel:~/dev$ gcc -v
gcc version 3.3.5 (Debian 1:3.3.5-5)
micheal@jezebel:~/dev$ uname -a
Linux jezebel 2.4.25-1-386 #2 Wed Apr 14 19:38:08 EST 2004 i686 GNU/Linux
micheal@jezebel:~/dev$ ./elflbl -n5

[+] SLAB cleanup
child 1 VMAs 65527
child 2 VMAs 65527
child 3 VMAs 65527
child 4 VMAs 28849
[+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xcbc00000 - 0xd77c0000
Wait... \
[+] race won maps=40880
VMAs reversed
expanded VMA (0xbfffc000-0xffffe000)
[!] try to exploit 0xcc98c000
[+] gate modified ( 0xffec90b0 0x0804ec00 )
[+] exploited, uid=0

sh-2.05b$ whoami
micheal
sh-2.05b$ cd /root/
sh: cd: /root/: Permission denied
sh-2.05b$

Re:Copyright Poo Poo -- This isn't a hole!!! WTF?

[shashir]

This is not a hole! This is wheel... if user is in wheel, of course he can access root... ppl don't put ppl on wheel for no reason... that is stupid... Paul startetz wants a lot of attention... wtf... a hole? That is stupid.

*raises hand*

[marcello_dl]

errm...

SElinux?

(don't even get started on the easyness of setting policies for selinux, you get offtopic: post the link of a MS equivalent else you lose the argument :D )

Patch available (testing)

[zCyl]

Second, it'll probably be patched rather quickly.

There is a preliminary patch in testing for the 2.4 series.

Look here.

The file is patch-2.4.29-rc1.bz2

Note that it's in TESTING, because it probably needs testing yet. But if you're desperate to patch it up quickly at your own risk, then there you go.

Re:Patch available (testing)

[flatface]

If you don't want a potentionally unstable kernel, grsecurity 2.0.2 on 2.4.28 doesn't allow for these kinds of shenanigans.

flatface@flatface flatface $ gcc isec-0021-uselib.c -o isec-0021
isec-0021-uselib.c: In function `check_vma_flags':
isec-0021-uselib.c:545: warning: deprecated use of label at end of compound statement
flatface@flatface flatface $ ./isec-0021

[+] SLAB cleanup
[-] FAILED: get_slab_objs: fopen (Permission denied)
Killed
flatface@flatface flatface $

Re:Failed on Debian

[ecliptik]

Something similiar to th parents reply, I didn't become root, but after about the 20th time of running it it crashed the machine, there goes 60 days of uptime.....

Not vulnerable

[karmatic]

It's nice to see that a little planning can go a long way.

I've got a hardened gcc compiler on my main server, so I compiled on a unpatched machine (stock RedHat 9) and moved it over. Although the RedHat 9 exploit worked fine, my production machine was completly unaffected.

The solution? Grsecurity. Besides the fact that
compiler access is restricted (can't compile exploits), and normal users cannot write anywhere executables are allowed to run (can't copy exploits from other machines), the address-based overflow protection and other protections work like a charm.

== Output ==
cyt0plas@www cyt0plas $ ./sploit

[+] SLAB cleanup
[-] FAILED: get_slab_objs: fopen (Permission denied)
Killed
== End Output ==

I'll still apply the appropriate patches to my source tree, but it's nice not to need to do it _now_.

Re:What, no remote exploit?!?

[Tanktalus]

I'm also kinda curious ... if I have a root terminal open on my desktop, can a malicious program running as me do something similar?

If not, then it's a security deficiency in the Windows API for allowing it. If this can be done on X too, then it's a security deficiency in both.

You don't get security points by leaving a door unlocked and a note on it saying, "Please use other door."

Re:What, no remote exploit?!?

[mark-t]

A local user could convert this into a remote exploit if they have the ability to make cgi's on the system's webserver.

Doesn't work?

[andfarm]

Segfaulted in sys_mmap2 when I tried it on a couple machines. For what it's worth.

Re: bugs in code

[archen]

And since when is conjecture trolling? Unless using terms such as "Generally I'd say" and "I'm wondering" elude to "These are absolute facts". These statements are simply my opinion that the parent is probably not accurate based on my perceptions. Maybe windows has 360000 bugs, maybe 10 billion more - I highly doubt it and I doubt there are any facts to prove or disprove it either.

MAC filtering has problems too.

[bobbuck]

Reasonable- as long as they choose a very strong password and you have MAC filtering in your SSH to prevent other computers from logging in.

ssh postgres@target
Access denied for MAC 12:34:56:78:90:ab
>ip link set eth0 address ba:09:87:65:43:21
>ssh postgres@target
Access allowed for MAC ba:09:87:65:43:21
Password> *********
Ta Da!

Re:MAC filtering has problems too.

[drsmithy]

So how did you manage to break into the building and get onto the local network segment ?

Re:MAC filtering has problems too.

[bobbuck]

WIFI, baby.

Re:What, no remote exploit?!?

[Foolhardy]

I thought MS issued a hotfix for this a couple of years ago, around about the time XP SP1 was released, I thought.

Sending unsolicited WM_TIMER messages to another process has been blocked, but there are still other messages that can cause arbitrary code execution. The messaging model was inherited from versions of Windows way before security was considered. Sending messages (even the unsafe ones) to other processes can't be blocked or it would break way too many things. No security isn't an option in NT, so the solution is to break the environment into sandboxes. Inside each sandbox, however, there is no security; all the security is at the front door.

So why, when security flaws are caused by applications doing something that the Windows API documentation specifically instructs them not to do, is this considered a flaw in Windows?

It's not, but that doesn't stop some people from blaming Windows anyway. It also doesn't prevent 3rd party developers from writing insecure apps, that (when trusted by an admin) can break the system. Notice that Microsoft threatens to stop supporting interactive services in the docs, to try and get developers to clean up their act, but they will never do it, as Microsoft has compatibility as too high a priority.

Failed on Gentoo too

[Quattro Vezina]

[quattro@zeta:pts/4 ~]$ ./elflbl

child 1 VMAs 0
[+] moved stack bfffd000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xff400000 - 0xffffd000

[-] FAILED: try again (Cannot allocate memory)
zsh: killed ./elflbl
[quattro@zeta:pts/4 ~]$ cat /proc/version
Linux version 2.6.9-gentoo-r13 (root@zeta) (gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)) #1 Tue Jan 4 19:49:48 CST 2005

Re: bugs in code

[Obliviously]

You failed to notice reference to two separate articles I had read in the past. I used the example of Microsoft Windows simply to demonstrate the amount of bugs that are possible in large scale projects.

I too doubt that Windows has 360 000+ bugs (I have no information to prove or disprove this). But even if Windows had 1/4 of the 2 bugs per 100 lines of code it would still be a significant amount. The point being that any large scale programming project will have more bugs than could possibly be patched (or even discovered) before the software is retired .

I see now.

[slapout]

That explains all the dupe stories on slashdot...

Re:What, no remote exploit?!?

[Foolhardy]

I'm also kinda curious ... if I have a root terminal open on my desktop, can a malicious program running as me do something similar?

On Windows, console windows aren't vulnerable (I don't think). If you did have a vulnerable window on the same desktop as a malicious program ready to exploit it (without using a job object to contain it), the malware could take it over. This is a bit of a problem with RunAs.

If this can be done on X too, then it's a security deficiency in both.

X on UNIX is like GDI on Windows. The issue is in Win32.USER, the window manager. Although X isn't vulerable, certain window managers could be; it depends on how messages are sent between windows.

Congratulations, you've just been expelled. ^_-

[Ayanami Rei]

no root account...

[coma_bug]

... no root exploits. Try these:

• Plan 9
• Inferno
• EROS

Re:no root account...

[downbad]

or you could just delete the root account.

No, think about it ...

[Seraphim_72]

Actually copyrighting the exploit is kinda cool. Say you are a admin, and some kid gets fresh and tries this out. "Hey kid, not only am I nailing you to the wall for this, but I am turning you over to the guy who "owns" it and you get to pay him a nice fine." No, I think that is it pretty hilarious that the code is copyrighted.

Sera

Re:No, think about it ...

[Alsee]

copyrighting the exploit

Everything is automatically copywrited the instant you wrtie it down. Hell, your post is copyrighted.

Oh, and you can't copyright the "exploit", you can only copyright that implementation of it. If a programmer understands what is going on in that code, he can read it, and then write his own non-infringing version.

Which is all aside from the fact that you would probably be end up losing money paying lawyers to persue a civil suit against some kid that is presumably broke paying lawyers for felony criminal proceedings.

-

Re:No, think about it ...

[*weasel]

If you register the copyright, you can then sue for punitive damages. If you do not register the copyright, then while your work still is automatically copywritten, you can only sue for earnings the infinging party earned from your work.

Not that you'd be getting anything out of said script kiddie anyway. And, as you point out, it'd be trivial to rewrite a non-infringing version.

Re: bugs in code

[archen]

Fair enough, point taken. =)

I'm still not sure if I buy the 2 lines per 100 though. Because after you reach a certain point of complexity, it's hard to say if application 'x' has a function that calles 3-4 routines deep if they all do "what they're supposed to" and there was faulty logic in the model of the program itself. So I'd say it's hard to base bugs off of a raw code count. But then again I don't know because really understanding how a million lines of code is pretty far over my head.

Re:Failed on Slackware 10 (2.6.8.1 Kernel)

[Xerp]

rebel-base:~$ ./elflbl child 1 VMAs 0 [+] moved stack bfffe000, task_size=0xc0000000, map_base=0xbf800000 [+] vmalloc area 0xff400000 - 0xffffd000 [-] FAILED: try again (Cannot allocate memory) In the end a did a quick script and kept it running for 10 minutes. Always FAILED.

How the hell does uselib() work anyway?

[nagora]

Uselib() takes a string which is the name of your library. Fair enough. But it just returns a flag. How do you know where the library was loaded so you can actually call anything in it? This has bothered me before while I was hacking in assembly and this story's just reminded me. How do you use it?

TWW

Re:What, no remote exploit?!?

[xanadu-xtroot.com]

Of course, the VIC-20 was pretty close to a toy, with its 22-column display and 5k RAM.

Not at that time. Granted I started (well, got more serious) with a C=64, but I did play around with a VIC-20. All I had before that was an Atari 2600 (and played with a Sinclair and a luggable Compaq in there somewhere, I for get the exact time line). The VIC was superior to anything that was remotely available (read == affordable) at that time.

That's the IE way

[diegocgteleline.es]

That's the IE way, not nice

That's right! Stick with 2.0.36

[Tom7]

That's why I've been sticking with 2.0.36 all these years. I haven't seen a security advisory for it in ages.

Re:That's right! Stick with 2.0.36

[m50d]

Why is this funny? Sticking with 2.0 is the way to go if you want real stability and security.

Re:That's right! Stick with 2.0.36

[Kjella]

2.0.40:

o__Security-fix__: fix local LCALL7(taken from 2.2.23)
crasher
o__Security-fix__: made mmap of(me) /proc/*/mem a config-option,
disabled by default
o__Security-fix__: fix ICMP data leak(Philippe Biondi, me)
o__Security-fix__: Fix ethernet(backported from 2.2.24)
padding data leak

...and I don't bother to dig up what happened in 2.0.36 -> 2.0.37 -> 2.0.38 -> 2.0.39 releases.

If you don't want to read the security advisories, it doesn't matter what kernel you're running. :) So even if you are serious, you are still wrong.

Kjella

Re:Microsoft Commits $3.5 Million to Indian Ocean

[benna]

Of course they don't. But they should do it anyway.

Re: bugs in code

[ClosedSource]

I've never bought into this Marketing argument. MS's marketing has about as much dazzle as Bill Gates' personality.

On the other hand, look at Apple. Jobs is charismatic and a master media manipulator.

If marketing was the key factor, Apple would be the one with the 90% market share instead of MS.

Re:What, no remote exploit?!?

[duffbeer703]

Every desktop Linux distribution contains a bind caching nameserver and a sendmail engine.

Re:Failed on RHEL, Failed for gentoo

[cTbone]

i'm getting the same segmentation fault as well.

2.6.9-gentoo-r13

Dangit...

[catdevnull]

All those MCSE dorks down the hall are gonna give me sh*t for the next week.

Reminds me of a punchline to my favorite Scottish joke:
"Aye, lad...ya screw ONE goat..."

Re:What, no remote exploit?!?

[pVoid]

Because the API has a structure: any object running in the current interactive desktop is considered part of that security context. Period. It's not a question of having left the door unlocked. In fact, anyone who defends that "rm -rf /" should not be hidden from the user can have no legitimate protest to this system design.

Consoles apps (not consoles themselves*) are not vulnerable because they are not part of the windowing system, they output to the window via stdout/stdin/stderr.

As for X, I don't know the structure of the windowing system, but the basic problem is not that apps are broken into, the problem is that any window sitting on your desktop is assumed by the OS to be owned by YOU. So, it shouldn't be illegal for a different app owned by you to send it a window message (like typing "rm -rf /").

* A console app is any app like cp or mv that you can invoke from a command prompt. These apps are unaware of windows and its messaging structure and therefor not vulnerable. Cmd.exe itself is probably aware of the messaging system though, since I'm sure it actually implements its own console.

Re: bugs in code

[FireBreathingDog]

I don't know what sigma level Microsoft is at but with 2 defects per 100 is 360000 per 1,000,000 lines of code. That puts them at a sigma level between 3 and 4. The Majority of software makers are below that. Yet if MS were six-sigma (they sell software that tracks it) they would have only 61 defects for those 18 million lines of code.

That's why you should always put curly braces on their own lines, to increase your total lines of code. Helps achieve a more favorable sigma.

Re: bugs in code

[Minna Kirai]

MS's marketing has about as much dazzle as Bill Gates' personality.

You are conflating "advertising" with the much broader term "marketing", which includes many more aspects of making a sale. For example, exclusive OEM bundle agreements are one aspect of aggressive marketing.

For high-budget corporate customers, an impression of "dazzlement" can be a negative, as it signals a product meant for artists and radicals.

Exploit uses deprecated GCC extension

[Anonymous Coward]

The exploit has label at the end of a compound expression and doesn't compile in ISO compliant compilers like gcc 3.4.x. Change

__asm__("movl %0, %%esp" : :"m"(old_esp) );
goto out;
}
signal(SIGSEGV, vreversed);
val = * (unsigned*)(lib_addr + PAGE_SIZE);
out:
}

to

__asm__("movl %0, %%esp" : :"m"(old_esp) );
return;
}
signal(SIGSEGV, vreversed);
val = * (unsigned*)(lib_addr + PAGE_SIZE);
}

Boooooring-ness

[cbr2702]

Yes, Debian stable is no fun to run on your desktop. But for your servers and public area machines it's the best choice.

Re:Boooooring-ness

[abertoll]

Too bad, because servers that wouldn't be accessed locally wouldn't have a problem with this security hole.

Re:Boooooring-ness

[cbr2702]

Depends what you're serving; many hosting companies give hostees shell acounts. And my comment was more one of general principle than a remedy for this particular attack.

Re:Boooooring-ness

[nite_warrior]

the only problem is that you have to sacrifice some nice feutures form testing/unstable release... my mail server needed to run on exim4 so it was better to run unstable than stable that came with exim3

Re:Boooooring-ness

[RWerp]

What is the problem with porting exim4 back to stable?

Re:Boooooring-ness

[nite_warrior]

just that is a lot easier to use the package that updates frequently with the distribution, rather than having to compile everytime

Rationale

[acidrain]

I expect they are just covering their asses agianst being sued for helping some kid take down google. If they prohibit modification/distribution then legally they are not providing something you can use in an exploit. If you are going to take down google with this, what the hell do you care about the copyright.

Re:What, no remote exploit?!?

[Daengbo]

Hey, it still beat my US$1000 Model I with 4K RAM. The Vic had color, too.

Local exploit

[gir_v_2]

Am I the only one who sees this as a reason to keep my roomate away from my comp and not worry about Gates invading my privacy?

Re:What, no remote exploit?!?

[Tanktalus]

Ok, maybe I left the description a bit too vague.

I'm running an xterm. Definitely an X-based app. I happen to have a privileged shell running in it. Another malicious application is running on my DISPLAY (whether that is started by me, or over the network via X protocols). Can it send messages to the xterm to cause it to think that I typed "rm -rf /" in that window? Nevermind that finding it would be difficult - finding such a window on Windows would not necessarily be easy, either, IIRC.

Re:What, no remote exploit?!?

[LnxAddct]

The reason is because they are standardized programs. Just about every root server uses bind and most major mail gateways use sendmail. They've been tested and proven and can handle crazy loads, others are nice for personal mail servers and small to medium business, but any larger and you need to bring out the big boy toys. Btw, bind and sendmail aren't as bad as people make them out to be, especially not in this day and age.
Regards,
Steve

setuid(0) is affected by this how?

[adb]

Pls RTFM bfr cmmnt kthxby.

Linux 2.6 compile hint

[Aaron W. LaFramboise]

I had to add the flag -Dmodify_ldt_ldt_s=user_desc to the gcc command line to get this to compile on a Linux 2.6 system with vanilla kernel headers and a vanilla generic glibc 2.3 installation.

Re:What, no remote exploit?!?

[sacredchao]

Ecept that this situation isn't analagous to leaving the door unlocked with a note pinned to it. It's more analagous to giving the building's tenants each a key to the door and saying "Don't leave that door unlocked because then uninvited people can get in."

Re:What, no remote exploit?!?

[zaffir]

Yup, that's pretty much it.

The other response to my post is correct. The apache user itself is a special case, a "normal" user that happens to be running a vulnerable app like you suggest would be a possible way to remotely root a machine.

Re: bugs in code

[gweihir]

Its funny how all the 0.x versions of open source software I am running never seem to crash and burn like Windows (and commerical Windows software...3rd party developers make buggy software too)

I think it is a cultural thing. MS has lowered everybodys expectations far, far to much. Now many developers and users on Windows think that buggy and crashy code is acceptable.

Your sig (Off-topic)

[Mad Marlin]

TANSTAAFI: There Ain't No Such Thing As A Free iPod.

Shouldn't that be TANSTAAFi?

two I've been at switched to Linux

[Trepidity]

The older servers still run Solaris on Sun hardware, but Sun hardware is just so much slower and more expensive than commodity x86 hardware that they've been migrating to Linux on x86.

well, that's the whole point of Unix user accounts

[Trepidity]

The entire point of the Unix account system is that you can give people accounts on your system with restricted privileges. As opposed to Windows, where (until recently) any user could touch anything, on Unix systems users can only touch certain things. Thus, you can safely give people accounts on, say, a compile-farm to run their code. Or a Beowulf cluster to run overnight simulations. All without them all having access to everyone else's accounts, or being able to mess up the server.

Re:What, no remote exploit?!?

[julesh]

X on UNIX is like GDI on Windows. The issue is in Win32.USER, the window manager. Although X isn't vulerable, certain window managers could be; it depends on how messages are sent between windows.

X performs similar functions to both GDI32 and USER32. Specifically, it does perform the USER32 function of passing events to windows, and does include a mechanism that one client can use to generate events that will be sent to another client. This works regardless of the window manager in use.

However, when the destination client receives the event, it can easily distinguish between an event generated by the X server itself and one generated by another client. Many X programs, including xterm, ignore events generated by other clients, thus preventing similar holes from being exploitable.

I also believe that it isn't common practice to pass around pointers to code to be executed in event data structures in X, although my actual X programming experience is limited to a low level "hello world" program using Xlib and a solitaire implementation in QT, so I could easily be wrong.

All in all, I'd say any given X application is highly unlikely to be vulnerable to such a problem, but you may find one or two that are.

Re:whew!

[afd8856]

should I explain this to you? it goes like this: if you have ANY service exposed to the internet, it can potentially be exploited to get the user of that server, then escalated to the root using this exploit. So, potentially, you're not safe either.

Re:What, no remote exploit?!?

[julesh]

I'm running an xterm. Definitely an X-based app. I happen to have a privileged shell running in it. Another malicious application is running on my DISPLAY (whether that is started by me, or over the network via X protocols). Can it send messages to the xterm to cause it to think that I typed "rm -rf /" in that window? Nevermind that finding it would be difficult - finding such a window on Windows would not necessarily be easy, either, IIRC.

No. X does provide a mechanism that allows you to send the events, but it also provides a mechanism that allows the receiving app to tell if the event was a real one or a synthetic one. xterm ignores all synthetic events. I've tried doing this myself, it just does nothing.

Finding the window is trivial, btw, on both Windows and X; you just need to know what its title is.

Re:What, no remote exploit?!?

[julesh]

Consoles apps (not consoles themselves*) are not vulnerable

Note that console windows are _strange_. They don't seem to have been implemented using the standard Win32 APIs; if you try playing around with them they behave differently to other windows.

I can't remember the exact details, but I specifically think they do not react to SendMessage calls. They caused me a fair amount of hassle when I was writing a virtual desktop management program a while back.

Re:I'll give you one

[TheRaven64]

IE is not `directly tied into the kernel'. It is a userland process, which shares a lot of code with the shell and other applications. At no point did MS claim that it was tied to the kernel. They claimed it could not easily be removed, and that was true - both the Windows help system and the default shell share a lot of libraries with IE (of course, there's no reason why they couldn't disable the browser functionality relatively easily, but why bother?).

The user interface component it not tied into the kernel either, unless you are referring to the display drivers which (since NT 4, I believe) are run in ring 0. The same is true of most operating systems - at least some of the display driver is run in kernel mode for performance reasons (see QNX for an exception).

Windows is considerably better at preventing use-space programs from accessing or exploiting the kernel than UNIX derivatives, since it has no concept of a root user. Administrator users in Windows are still restricted - there are some processes they can't kill, and some resources they can't access. Windows also has a finer grained access control model than UNIX.

The reason security holes in Windows are often more serious is that there is no need for a local root hole in Windows. Most software, including the web browser, shell, etc. runs with administrator privileges and hence can do anything an administrator can do. If there is a remote hole in Mozilla on *NIX, then the worst that can happen is that the affected user is compromised, and loses their data. This is not something that should be downplayed, since most important data is owned by system users. If IE has a remote hole then the entire system can be compromised by a user running as an administrator.

In my opinion, the biggest mistake in designing UNIX security was to force processes to run as root if they wished to bind to a port number below 1024. This means that any major server (DNS, HTTP, FTP, etc.) must at least start as root. This means that there is a significant chance of a complete system compromise if a single server is compromised. Windows does not have this problem.

The biggest security mistake in designing Windows was the lack of a su or sudo equivalent (yes, I know about the RunAs service, but it lacks a good UI). This makes it very difficult for users to switch to administrator privileges, encouraging them to run as an Administrator at all times, making security holes a lot more serious.

Re:Did Micro$oft buy out Linux?

[TheRaven64]

And don't forget that when you combine an arbitrary code execution vulnerability (like the one in Mozilla) with a local root exploit, you get a remote root exploit.

Do you hear that sound? It is the sound of a thousand OpenBSD admins laughing in their sleep...

Re:What's truly funny

[Alsee]

Linux and Mozilla are not perfect, but they are a hell of a lot better than Windows and IE.

For your typical Windows exploit all you need to do is feed in too much data and overrun some buffer. An endless string of absolutely trivial and STUPID vulnerabilities.

I'm a programmer. This Linux bug is impressively deep and sophisticated. The sort of bug that is going to exist in Windows as well, but which will simply remain there ignored because there is so much damn low-hanging-fruit of trivial and more dangerous bugs.

It is also "merely" a local priviledge escalation exploit. Certainly a problem, but it is hardly in the same class as the DEVESTATING remote-root exploits we see almost weekly in Windows and IE. The ones where you can just spew packets across the internet and infect machines by the millions. The ones that allow worms, or that can infect your machine simply by visting a website.

When Windows has this sort of vulnerability it doesn't make the front page of Slashdot. Hell, you get "ho-hum" stories off the front page citing like SEVEN new Windows bugs that are similar or more dangerous. One relatively non-dangerous Linux bug is front page news, but a half-dozzen similar Windows bugs PLUS a critical remote root bug isn't front page news anymore, it's a ho-hum same-crap-different-day report.

And the really ugly part isn't simply that Microsoft's code is worse, but that it is often more vulerable as a direct result of Microsoft's own malicious intent. For example most of the IE problems are a direct result of Mircosoft deliberately ram-rodding IE to be a part of the "operating system". An absolutely horrendous "design decision" from a programming point of view. It is something they did as part of deliberately abusing and extending their monopoly, and as a deliberate part of circumventing court prosecution and remedy of their illegal activities. The webbrowser should not be exposing the deep and complex operating system directly to attack by websites.

-

Re:whew!

[TheRaven64]

Remote arbitrary code execution exploit + local root exploit = remote root exploit.

I hope you have updated to the latest version of Mozilla / FireFox...

Won't be exploted here either!

[MuMart]

I'm running windo

Re:Microsoft Commits $3.5 Million to Indian Ocean

[netdudeuk]

I suspect that the shareholders would disagree !

Debian Kernel Caveat

[Nurgled]

Of course, by default the kernel isn't installed from a package so it won't update as part of the normal update/upgrade unless the user has installed a specific kernel image from apt before.

Re:What, no remote exploit?!?

[Nurgled]

cmd.exe is just a Win32 console application. The console you see is provided by the kernel as part of the console subsystem.

You can observe this by running cmd.exe under Wine in Linux; like all Win32 console applications running under Wine, it simply inherits the console of the shell and doesn't create a new window for itself. You can also see it if you directly run a console application from a Win32 GUI app. cmd.exe isn't started, but the standard console window still applies. cmd.exe is also run from the Windows telnet service, with its stdin and stdout attached to the socket, to provide its command line interface.

(Running GUI applications from the telnet prompt can be interesting, since they aren't run in the same window station as the active desktop. They run, but you can't interact with them in any way and you just have to kill the process to get rid of them.)

Actually the next release is Sarge

[TheScienceKid]

Sarge, aka Debian 3.1, is the codename of the next release... and like the other child poster said, they're named after characters in Toy Story.

For example, the development branch is called Sid, because Sid was the kid next door who broke the toys.

If you look at the Debian Archive you'll see old distributions included bo, buzz, hamm, rex and slink.

Ciao,

TSK (611371).

Re:whew!

[m50d]

The average home user, however, is safe.

compare the GNU and M$ cracks?

[twitter]

The FSF has a much better write up of the ftp.gnu.org crack.

There are many major differences between that and the M$ crack. The most important being:

1. The FSF did not hide anything. There were too many independent parties involved for them to be able to lie about any detail. M$ can say whatever M$ wants.
2. A local user was involved with the FSF crack. I doubt there was any relation at all with M$ from the people who cracked M$, in other words anyone could have done it.
3. The FSF ftp site was a repository that could easily be checked by the original developers and from previous GPG signed files and their MD5 sums. Microsoft's site was their holy of holies and I doubt anyone else had coppies that were not compromised or that could be compared as easily, but we will never really know by difference 1.

Please don't try to compare the Microsoft monoculture disaster to free software. You can't.

Re:compare the GNU and M$ cracks?

[dedazo]

The FSF did not hide anything

The FSF didn't know anything was happening for four months.

A local user was involved with the FSF crack

So what you're saying is they're "less worse"? Mmmkay.

The FSF ftp site was a repository that could easily be checked

Of course, assuming you knew it was actually compromised from March to August. Ouch.

Please don't try to compare the Microsoft monoculture disaster to free software

I wasn't, and "monoculture" has nothing to do with it. BTW, I'd recommend revising your use of the "monoculture" term given the latest trojan attack on RedHat users and the PHP/Apache/Google worm making the rounds.

Re:compare the GNU and M$ cracks?

[dedazo]

boa, yes. I bet you write exciting enterprise applications with boa.

Re: bugs in code

[ClosedSource]

"For example, exclusive OEM bundle agreements are one aspect of aggressive marketing."

I'm not an expert so I can't judge if OEM bundle agreements should be classified as marketing. It sounds more like negotiation on the terms of a sale to me.

"For high-budget corporate customers, an impression of "dazzlement" can be a negative, as it signals a product meant for artists and radicals"

As far as advertising is concerned, IBM's services Ads on TV are far more interesting than anything MS has done and high-budget corporate customers are their bread-and-butter.

Re:makes me chuckle.

[Dojo-jojo]

Sure more "hackers" might attack Linux if it had more market share, but that doesn't mean that more exploits would be found, especially if the system is inherently more secure.

Unfortunately, Linux is not inherently more secure. Don't get me wrong. I prefer Linux to M$, but according to MaximumPC, (sorry I can't cite the exact issue and article,) Windows 2000 was the only operating system to meet all of the DoD security requirements. Linux did far worse.

I have my own theories as to Linux's imagined security superiority:

(1) Minority - Linux machines are a minority. Yes, the number is growing everyday but still a minority. Hackers exploit flaws either to steal information for monetary gain or to gain notoriety. The results are not quite worth the effort.

(2) Community - Linux has a strong community. A large percentage of Linux users would report a flaw to the community rather than exploit it.

Re:What, no remote exploit?!?

[Foolhardy]

I stand corrected. I thought more was offloaded to the window manager.

Re:Microsoft Commits $3.5 Million to Indian Ocean

[benna]

I'm sure they would. That's part of why I hate capitalism. No I'm not a communist. I am a libertarian socialist.

Re: bugs in code

[drsmithy]

Good job M$!!!

What's particularly funny here is that you're asserting Microsoft has the "industry standard rate of bugs" and then (from your sarcasm) implying they're worse than average...

Re:I'll give you one

[drsmithy]

[...] like why are the web browser and user interface directly tied into the kernel.

They aren't.

Re:I'll give you one

[drsmithy]

The reason security holes in Windows are often more serious is that there is no need for a local root hole in Windows.

Complete and utter bollocks.

Most software, including the web browser, shell, etc. runs with administrator privileges and hence can do anything an administrator can do.

Note that this only happens if the end user is silly enough to run everything as Administrator, so in reality it's no different to a unix user running everytyhing as root. In both cases the solution is easy - don't run things as a privileged user unless you have to.

If there is a remote hole in Mozilla on *NIX, then the worst that can happen is that the affected user is compromised, and loses their data. This is not something that should be downplayed, since most important data is owned by system users.

False. In a typical system the most important data is generally that which is constantly being modified by end users.

On a scale of rating data from "irrelevant" to "critical", a bunch of OS binaries, libraries and configuration files that can be (relatively) painlessly reinstalled and/or recreated generally sit right at the bottom. Indeed, I can't think of anything on my systems I'd be less worried about if I detected an intruder on them than the "OS files".

If IE has a remote hole then the entire system can be compromised by a user running as an administrator.

Only if the user is running IE as Administrator, in which case the scenario is identical to the user running Mozilla/Firefox/whatever on unix as root.

In my opinion, the biggest mistake in designing UNIX security was to force processes to run as root if they wished to bind to a port number below 1024. This means that any major server (DNS, HTTP, FTP, etc.) must at least start as root. This means that there is a significant chance of a complete system compromise if a single server is compromised. Windows does not have this problem.

This is not a problem, this is merely a *symptom* of the problem (and one easily circumvented by dropping privileges after binding to the port or running things in a chroot or jail environment). The _problem_ is that root on (traditional) unix is all-powerful and impossible to restrict.

The biggest security mistake in designing Windows was the lack of a su or sudo equivalent (yes, I know about the RunAs service, but it lacks a good UI).

Right. Because right-clicking a shortcut is _so_ hard and 'sudo firefox' is much more intuitive than 'runas /user:Administrator firefox'.

RunAs _is_ the sudo equivalent. More importantly, neither 'sudo' nor 'runas' are design issues at all, they're simply methods of leveraging the multiuser aspect of the OS (it's the multiuser part that is the *design* issue).

2.6 kernel information

[MasTRE]

This is a perfect example of /. failing. This thread is next to useless for finding information related to fixing this problem, especially regarding the 2.6 kernel. So let me share (don't ask me why).

What Alan Cox and Linus have to say on the subject:
http://kerneltrap.org/comment/reply/4503

Alan Cox already fixed it in 2.6.10-ac, I assume this to be as of ac6, but you should grab -ac10 (or whatever is the latest):
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/ linux-2.6/2.6.10/
This method is unlikely to make it into the mainline kernel.

grsecurity also fixes it, using do_brk_locked():
http://www.grsecurity.net/linux-2.6.10-secfix-2005 01071130.patch
This method is also unlikely to make it into the mainline kernel, but it should work fine.

Both of these "fixes" present their own set of problems; I am not familiar with the -ac patchset and it would foolish to apply it to a production environment. The grsecurity "secfix" patch is specified for use _after_ applying the main grsecurity patch, so for those that don't use/desire it may pose a problem.

This is rather shameful, that an official patch does not exist days after the advisory was published. This is Microsoft bad, or worse! It makes Linux look like a toy, not a serious contender in the enterprise. SIGH

Re:2.6 kernel information

[MasTRE]

Update: this appears to have been adressed in 2.6.10-bk12. From the Changelog:

ChangeSet@1.2247.2.4, 2005-01-07 15:58:52-08:00, torvalds@ppc970.osdl.org
Fix do_brk() locking in library loader

The regular executable loader path doesn't need the locking,
because it's the only user of its VM. But the same is not true
at library load time. So get the mmap semaphore.

sudo *may* have protection

[warrax_666]

against this type of thing. Anyway, here's what could and should be done to protect against such an exploit:

• Don't accept passwords from any external source (command-line/environment/file descriptor). This opens it up to the kind of exploit you're talking about.
  
• Ensure input is coming from a real interactive terminal before asking for the password. There should be ways of detecting whether a program is running on a *true* interactive terminal (not just a pseudo-TTY).
  Being setuid this cannot be subverted by using LD_PRELOAD or similar mechanisms to fool sudo into thinking it's running on an interactive terminal (or to inject characters into the input).
  
• Always show an attempt number at the password prompt. This (hopefully) alerts the user to the fact that a new sudo has been started (and is asking for the password) after the fake one ran. If they'd just entered the password incorrectly the first time, the attempt counter would increase. IOW, the user knows that the password was compromised and can make sure it's changed as soon as possible.
  

I think that covers everything.

Good luck...

[Kjella]

...if I wanted to use this on an account, I sure as hell wouldn't use my account. How easy is it to get someone else's (standard unprivilidged account) at any school or university? Hint: Really easy.

Depends on how you saw the context of what he said

[Rob.Fussell]

I don't think virus-writers need any more good luck... But local root vulnerability means they can only compromise a few tens of thousands of people at a time

Agreed with your point however he states "virus writers", which refer to one or one group of associated writers can comprimise tens of thousands of people, in the context of "versus" rather than the whole internet, seems to imply 10,000+ machines not "user accounts" given the implicit design of "virii" (or more accurately worms) in their spread..if 10,000 users of one box are comprimised ie, one rooted machine, then a worm/virus obviously is not the method in which this "spreads". It's simply the context in which he stated what he did. My statement suited my view of what he stated. Though I am fully in agreement that one box with X number of users is comprimised, X number of people have been comrpimised since root can see all and use all of those accounts... robf();

OpenBSD has a better track record

[putko]

OpenBSD (and NetBSD and FreeBSD) have a better security track record than Linux or Windows.

When OpenBSD people find a bug, the audit the code and look for other instances of the same flaw. The perfectionist attitude is quite refreshing.

The OpenBSD team is like a bunch of border collies, compulsively working to keep the rest of us safe.

I wish more people prioritized security over rich features and convenience (there isn't any real reason to do so). Thank goodness that the OpenBSD people do what they do! What a thankless job.

*cough*

[TheLink]

Shatter attacks.

Re:*cough*

[drsmithy]

Right. So I guess local exploits for unix must be so common as to not be worth discussing because of "buffer overflows" then ?

I've had people take credit for my discoveries

[SuperBanana]

Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.

A couple years ago I identified that a worm was geting past a lot of virus software simply because it had CF/LF's at the end of each line instead of just CFs; they looked identical, but they were not, and virus software was missing the new "strain".

I emailed a well-known head of a well-known security mailing list, who just so happens to work for a private security firm. He congradulated me, thanked me for finding it. The next day- I found an article where he was interviewed and said "I found..." and then pretty much word for word what I wrote in my email.

I was fucking pissed. The guy stole credit for my discovery, and I began to see why he was such an "expert" in the field.

I understand EXACTLY where this guy is coming from.

Re: bugs in code

[Temporal]

I know it's a joke and all, but the grandparent to your post defined lines as ending with a semicolon. So, where you put your braces wouldn't make a difference.

Re:What, no remote exploit?!?

[Bush Pig]

I can't imagine ever wanting to know enough about Windows to understand this except at a very high level. I hope my next contract (and all the others after that), like my last, are at UNIX sites.

Re: bugs in code

[fbjon]

So how do you actually count lines? One statement = one line?

Re: bugs in code

[fbjon]

Ah, but in that case, just replace all instances of ';' with ";;;;;;;;;;".

2.6 patch

[zCyl]

Alan Cox has a patch up for the 2.6.10 kernel, available here.

The file is patch-2.6.10-ac8.bz2 (or later)

This is also still considered "testing" until merged.

Re:Hear that sound?

[Triumph's Nemesis]

It's the sound of someone wasting valuable worktime reading /.

Re:Interested

[cortana]

Cite please?

Do you really mean what you are saying? I've looked through all the Native APIs listed at http://www.sysinternals.com/ntw2k/info/ntdll.shtml and I can't seem to find any mention of Internet Explorer.