Beta
×

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

Thank you!

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

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

RDS Protocol Bug Creates a Linux Kernel Hole, Now Fixed

timothy posted about 4 years ago | from the what-does-the-sky-think-as-it-falls dept.

Security 89

Trailrunner7 writes "The open-source Linux operating system contains a serious security flaw that can be exploited to gain superuser rights on a target system. The vulnerability, in the Linux implementation of the Reliable Datagram Sockets (RDS) protocol, affects unpatched versions of the Linux kernel, starting from 2.6.30, where the RDS protocol was first included." The article goes on to say, though, that "Linux installations are only vulnerable if the CONFIG_RDS kernel configuration option is set, and if there are no restrictions on unprivileged users loading packet family modules, as is the case on most stock distributions," and that Linus Torvalds has committed a fix.

cancel ×

89 comments

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

A local exploit only (4, Informative)

h4rr4r (612664) | about 4 years ago | (#33977158)

They should mention in the summary this is a local privilege escalation exploit only.

Re:A local exploit only (2, Insightful)

jgrahn (181062) | about 4 years ago | (#33977314)

And they should say who actually has this code /installed/. RDS surely falls in the same category as SCTP -- might be useful in the lab at CERN, but not on any normal server, and certainly not on some random Ubuntu user's desktop.

Re:A local exploit only (2, Insightful)

CannonballHead (842625) | about 4 years ago | (#33977350)

Hm. By default? I don't know, but the article mentions testing the exploit on Ubuntu 10.04 x64.

Re:A local exploit only (5, Informative)

tom17 (659054) | about 4 years ago | (#33977694)

It's everywhere. I just tested it on a random newish Ubuntu install (Well, 10.04) and the exploit works. It *does* say in the article that it's set up this way as default.

I'd expect this is a pretty common vulnerability out there.

Re:A local exploit only (0)

Anonymous Coward | about 4 years ago | (#33978492)

Not an issue for debain squeeze apparently the default 2.6.32 kernel has it set to be a module. If you did not load it you are fine. I just checked,

Re:A local exploit only (2, Informative)

Athanasius (306480) | about 4 years ago | (#33978868)

What? No Auto-load of it on trying to use the protocol it utilises? I ask because the workaround is to turn that particular feature off: echo alias net-pf-21 off > /etc/modprobe.d/disable-rds

Re:A local exploit only (3, Informative)

drumbug1 (1140947) | about 4 years ago | (#33978898)

If the system is completely up to date it's already patched in Ubuntu. Details on the kernel package needed for each currently supported release is here: http://www.ubuntu.com/usn/usn-1000-1 [ubuntu.com]

Re:A local exploit only (0)

Anonymous Coward | about 4 years ago | (#33978998)

I wonder why they enabled it by default.

I've never seen anybody using it, and the only references I found indicate that is an oracle-internal thing.

I haven't find any rfc/spec, only the linux source code, a description of the api in Documentation/networking/rds.txt, and some worthless powerpoint slides.

Apparently, it helps being oracle if you want to push untested, un-audited garbage in the kernel.

Re:A local exploit only (1, Insightful)

miknix (1047580) | about 4 years ago | (#33980076)

That's why I like and appreciate user personalization in GNU/Linux. At expense of being modded down, imagine Gentoo Linux for example. The kernel and userspace are built mostly by the user and so, there is a lot of user generated entropy in it. That is good for security since we can't really say for sure if Gentoo is vulnerable to this attack or other attack. The kernel option is there, it depends if the user enabled it or not.

Re:A local exploit only (1)

Kjella (173770) | about 4 years ago | (#33980344)

Seriously, get a grip. Most people will compile it using the default flags unless they got a reason to change it. That it doesn't involve everyone is roughly equivalent to other people on other distros hardening their machine by disabling stuff they dont' use.

Re:A local exploit only (1)

miknix (1047580) | about 4 years ago | (#33980750)

Seriously, get a grip. Most people will compile it using the default flags unless they got a reason to change it

Well.. If everything is to be left defaulted, what is the point of installing Gentoo in the first place? ;)
People installing Gentoo know exactly what they want and want not. Otherwise it is just pointless to go all over the work that is required to install it..
Of course there is always the people initiating in Gentoo, but that happens to be a small and volatile userbase.

That it doesn't involve everyone is roughly equivalent to other people on other distros hardening their machine by disabling stuff they dont' use.

Notice that I never said that. However I think you might agree that people changing the system *a lot* are the exception. For the sake of the discussion, what would be the percentage of ubuntu users running their cooked kernel?
- that is my point. Still in Gentoo the percentage doesn't arrive anywhere near 100% because we have genkernel (to generate config and build the kernel automatically). However in slackware I believe that has to be 100% :)

Please don't just disagree because I gave Gentoo as example, I can just replace the name by sourcemage, slackware, the message works as well..

Re: genkernel is actually quite nice (1)

xiando (770382) | about 4 years ago | (#33981130)

- that is my point. Still in Gentoo the percentage doesn't arrive anywhere near 100% because we have genkernel (to generate config and build the kernel automatically).

I like genkernel, place your custom kernel config for the right version in /etc/kernels (just cp any old one), run genkernel --menuconfig for a quick look if there is anything new if you want and done. I use git-sources on my desktop and change kernel frequently and genkernel saves time when (ab)using a _custom_ kernel. And apparently "# CONFIG_RDS is not set"..

Re:A local exploit only (0)

Anonymous Coward | about 4 years ago | (#33978174)

RDS surely falls in the same category as SCTP -- might be useful in the lab at CERN, but not on any normal server

I don't know about RDS, but I certainly have firewalls that pass SCTP to servers which send and receive SCTP traffic. It's useful for VoIP related activities.

Re:A local exploit only (1)

jd (1658) | about 4 years ago | (#33981006)

There are plenty of situations where RDS or SCTP would be useful but aren't used. Which is a damn shame. What is the point of having a bunch of solutions to the major networking problems of today if nobody uses them?

(And, to be fair, apps don't make much use of these protocols because routers don't often support them. They're good for LANs and extranets, though. However, perhaps that means we should try bullying the router companies into adding support.)

Re:A local exploit only (4, Funny)

synthesizerpatel (1210598) | about 4 years ago | (#33977392)

Listen, not a year goes by, not a year, that I don't hear about some escalator accident involving some bastard kid which could have easily been avoided had some parent - I don't care which one - but some parent conditioned him to fear and respect that escalator.

Re:A local exploit only (0)

Anonymous Coward | about 4 years ago | (#33977796)

Mallrats, classic. Good call, sir!

The video! (0)

Anonymous Coward | about 4 years ago | (#33978562)

Here is the video! http://www.youtube.com/watch?v=5gwGcP8QbH8

Brilliant!

Re:A local exploit only (1)

Aquina (1923974) | about 4 years ago | (#33978744)

Yes, because that's what makes a huge difference!

Re:A local exploit only (4, Insightful)

tlhIngan (30335) | about 4 years ago | (#33978902)

They should mention in the summary this is a local privilege escalation exploit only.

Local exploits become remote exploits througha vulnerable service or bad passwords. Just because something can only be done locally means nothing. It just means all I need to do is gain any sort of access then use the exploit. Instant root. And all I needed was just the ability to run a bit of my code. Or if I've previously gotten access in but not used it because running things as "nobody" isn't terribly useful, now with the ability to get root makes it very useful.

It's the same sort of thing that let that jailbreakme.com thing work - Safari downloads a PDF, the PDF display code tries to display it and fails, and runs the exploit code. Exploit code runs as Safari, uses a priviledge escalation hole to get root access, then does lal the jailbreak stuff as root.

Re:A local exploit only (1)

cheater512 (783349) | about 4 years ago | (#33980216)

Browser based exploits are generally considered remotely exploitable for user devices. They can be placed anywhere on the net.

Good luck getting this one to be exploited via the browser automatically.

Re:A local exploit only (1)

tepples (727027) | about 4 years ago | (#33980326)

Good luck getting this one to be exploited via the browser automatically.

Put it on a web advertisement network.

Re:A local exploit only (4, Interesting)

Oceanplexian (807998) | about 4 years ago | (#33979084)

Only? Only a local root exploit?

That kind of attitude makes me upset because I endure a lot of it where I work. A local root exploit is the hard part of owning a server. Getting
unprivileged access through some vulnerability is comparatively a piece of cake.

No need to worry unless you use shared hosting (1)

judeancodersfront (1760122) | more than 3 years ago | (#33994420)

I guess that means most websites then. Nothing to see folks, move along.

Linux again?! (-1, Troll)

Anonymous Coward | about 4 years ago | (#33977252)

How come Slashdot never has any news about Apple or Google? /duck

Re:Linux again?! (-1, Troll)

Anonymous Coward | about 4 years ago | (#33977296)

Because they are too busy making up excuses [slashdot.org] for why Linux has all these security issues despite the claim that it's InherentlySecure(TM) [tmrepository.com] .

Re:Linux again?! (1)

h4rr4r (612664) | about 4 years ago | (#33977398)

An explanation of what the exploit is, is not excuse.

All modern OS have these problems, the reality is we get speed or security and everyone has chosen speed. Maybe in 40 more years we will have the cpu cycles to waste.

Re:Linux again?! (0)

Anonymous Coward | about 4 years ago | (#33983828)

s/cpu cycles/programmer cycles/g

Bugs don't come from lack of CPU cycles, they come from not having infinite time to do testing and code review.

Exasperated Linus (0, Troll)

BadAnalogyGuy (945258) | about 4 years ago | (#33977268)

It must piss him off to no end when people add broken features like this to his operating system.

Re:Exasperated Linus (1)

Hatta (162192) | about 4 years ago | (#33977584)

If only there were some way for him to control what goes in the kernel.

Re:Exasperated Linus (1)

MichaelSmith (789609) | about 4 years ago | (#33981926)

Perhaps he should write his own version control system.

Now Fixed (0)

Anonymous Coward | about 4 years ago | (#33977280)

Are we going to start putting "now fixed" on all articles where it applies, or just Linux ones? I see how it is.

Cue the "well, nobody uses that" defense.

Fixing a hole where the rain gets in... (5, Informative)

digitaldc (879047) | about 4 years ago | (#33977310)

Reliable Datagram Sockets (RDS) provide in order, non-duplicating, highly available, low overhead, reliable delivery of datagrams between hundreds of thousands of non-connected endpoints."

Gives new meaning...

Recommendation:
Users should install updates provided by downstream distributions or apply the committed patch [3] and recompile their kernel.
Preventing the RDS kernel module from loading is an effective workaround. This can be accomplished by executing the following command as root:
echo "alias net-pf-21 off" > /etc/modprobe.d/disable-rds

Re:Fixing a hole where the rain gets in... (2, Insightful)

h4rr4r (612664) | about 4 years ago | (#33977434)

Better question do any distros ship with this on by default?

They mention 10.04, but do not say if they had to enable it first. I guess I will have to check what modules my desktop has at home to see.

Re:Fixing a hole where the rain gets in... (2, Informative)

tom17 (659054) | about 4 years ago | (#33977710)

It's enabled by default. I tested it.

Re:Fixing a hole where the rain gets in... (1)

dgatwood (11270) | more than 3 years ago | (#33989030)

You see, this is what I don't like about most Linux distros. There's way too much crap turned on by default. This protocol is basically useful only in a cluster computing environment, which represents maybe one, maybe two percent of the installed base of even a frequently clustered OS like Linux (and only because each admin runs thousands of usually identical boxes). Sure, security may ultimately be the responsibility of the users, but it's downright reckless and irresponsible to have esoteric protocols that all of three dozen people on the entire planet care about enabled by default in your kernel. Okay, that's a slight exaggeration. It's probably more like a few hundred people. The point is that for every one person who cares, there are probably thousands who don't, and possibly even millions who don't.

A proper, secure OS distro should provide the bare minimum by default, and should provide a means for the user to easily add features, not the other way around. Every thousand lines of code you add, statistically speaking, you add anywhere from 1-6 security bugs. The Linux kernel has over ten million lines of code, so statistically, it probably contains somewhere on the order of 10,000 to 60,000 security bugs. That number should make your jaw drop. Admittedly, about 95% of that code is architecture-specific or device-specific code, but the fact remains that even 500,000 lines of code means you'd expect on the order of 500-3,000 security bugs just in the core kernel alone. Every module you add is increasing your attack surface for vulnerabilities beyond an already staggering baseline.

Linux distros should, by default, ship without anything enabled except what a grandmother running a web browser on a single hardware configuration would need. If it's too hard to go from there to a fully usable configuration for the average geek, then that's a problem that needs to be solved in a reasonable way, which does NOT mean turning a whole bunch of other crap on by default.

Re:Fixing a hole where the rain gets in... (2, Interesting)

AlphaZeta (1356887) | about 4 years ago | (#33978602)

Just tried on my home machine (Ubuntu 10.04 64 bit) and it couldn't get the root shell. It's running 2.6.32-25-generic.
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
  [+] Resolved rds_proto_ops to 0xffffffffa0bc4860
  [+] Resolved rds_ioctl to 0xffffffffa0bbd000
  [+] Resolved commit_creds to 0xffffffff8108aee0
  [+] Resolved prepare_kernel_cred to 0xffffffff8108b2c0
[*] Overwriting function pointer...
[*] Triggering payload...
[*] Restoring function pointer...
[*] Exploit failed to get root.

Re:Fixing a hole where the rain gets in... (2, Informative)

drumbug1 (1140947) | about 4 years ago | (#33979116)

If the system is completely up to date it's already patched in Ubuntu. Details on the kernel package needed for each currently supported release is here: http://www.ubuntu.com/usn/usn-1000-1 [ubuntu.com] [ubuntu.com]

Re:Fixing a hole where the rain gets in... (1)

hackus (159037) | about 4 years ago | (#33978518)

MMMmmm sounds like a perfect transport layer for a botnet...now if I could just break into the server...

Oh wait.

Nevermind.

-Hack

Re:Fixing a hole where the rain gets in... (1, Informative)

rastos1 (601318) | about 4 years ago | (#33979104)

Preventing the RDS kernel module from loading is an effective workaround. This can be accomplished by executing the following command as root:
echo "alias net-pf-21 off" > /etc/modprobe.d/disable-rds

I hate it when I see an advice like that. Linux is an open system. We should understand what are we doing when running a command like that as root. Running that command means that you tell to kernel module loading mechanism that it should not load module with name net-pf-21. My man page for modprobe says that it reads files with extensions ".conf" in /etc/modprobe.d/ directory. So I guess that the command won't do squat on my system because of missing .conf extension.

Next it also assumes that the particular functionality is compiled in module called "net-pf-21". No such module here. That would probably be the case because Kconfig files nor Makefiles in linux source code mention such module. And all that google returns is the same line that you repeated here. The name net-pf would suggest that the module should belong to "network packet filter", but the patch from Linus is not dealing with packet filter but rather with net/rds/page.c.

I did not deeper analysis but I assume that

net/rds/Kconfig:
config RDS
tristate "The RDS Protocol (EXPERIMENTAL)"
depends on INET && EXPERIMENTAL
---help---
The RDS (Reliable Datagram Sockets) protocol provides reliable

together with

zgrep RDS /proc/config.gz
# CONFIG_RDS is not set

indicates that my system is safe.

Re:Fixing a hole where the rain gets in... (2, Informative)

Anonymous Coward | about 4 years ago | (#33979288)

"net-pf" is a common prefix that refers to network packet families. You have an alias file at /lib/modules/[kernel version]/modules.alias that contains a number of entries like this. This is actually a format that is hard-coded into the kernel:

http://lxr.linux.no/#linux+v2.6.36/net/socket.c#L1196

The workaround is perfectly valid.

Re:Fixing a hole where the rain gets in... (2, Informative)

JesseMcDonald (536341) | about 4 years ago | (#33979584)

The module name is "rds"; "net-pf-21" is an alias, and stands for Network Packet Family #21.

Note to linux devs (-1, Flamebait)

sildur (1383455) | about 4 years ago | (#33977358)

If you release early and you release often, you will release a big piece of sh^H^H code with a lot of bugs.

Re:Note to linux devs (4, Insightful)

Meshach (578918) | about 4 years ago | (#33977426)

If you release early and you release often, you will release a big piece of sh^H^H code with a lot of bugs.

Funny how Microsoft releases late and releases seldom and has the same problem...

Re:Note to linux devs (-1)

Anonymous Coward | about 4 years ago | (#33977490)

This isn't 1998 anymore, check your calendar.

Re:Note to linux devs (2, Informative)

jedidiah (1196) | about 4 years ago | (#33977766)

Nope. The usual Microsoft nonsense is still alive and well in 2010.

Re:Note to linux devs (2, Informative)

DeadCatX2 (950953) | about 4 years ago | (#33978100)

Yeah, it's 2010, and every Tuesday my computer bitches about how I have updates waiting to be installed...

Re:Note to linux devs (2, Insightful)

stagg (1606187) | about 4 years ago | (#33977990)

The same article announcing the existence of the exploit announced the existence of the fix. That's pretty good support if you ask me, and it's hard to be too worried under those circumstances.

Re:Note to linux devs (2, Interesting)

man_of_mr_e (217855) | about 4 years ago | (#33978638)

Of course what you don't know is that this issue has been known by the kernel team and unreported for at least 9 days.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3904 [mitre.org]

Notice the "Assigned" date, 10/12/2010, that's the date the CVE was created for this flaw and it was likely known and reported several days before that.

What this means is that the kernel team knew of the flaw, it was reported in secret, and they kept it a secret while they researched a fix. So people were vulnerabile for almsot 2 weeks, even though there was a known workaround that would have prevented them from being vulnerable if they had known.

OMG! (1)

symbolset (646467) | about 4 years ago | (#33982484)

Nine whole days [geek.com] ?

Re:OMG! (1)

man_of_mr_e (217855) | about 4 years ago | (#33983178)

When someone is claiming the flaw was fixed "overnight", yeah.. nine whole days.. and that's at LEAST 9 whole days.

There is this myth that flaws in linux are fixed within hours and ditributed to everyone instantly and everyone is safe all the time... There is also a myth that flaws are never kept secret and are fully disclosed as soon as found so that people can apply workarounds.

Both myths are wrong in most cases, as most critical bugs are embargoed from publication, sometimes for months. Then it's "announced" with a fix and it appears that it happened overnight, when in reality you've been vulnerable for a great deal of time but didn't know it.

Re:Note to linux devs (1)

richlv (778496) | more than 3 years ago | (#33989208)

supposedly that was requested by the reporter (although who knows with the ac post :) )

http://linux.slashdot.org/comments.pl?sid=1833084&cid=33978900 [slashdot.org]

Re:Note to linux devs (1)

man_of_mr_e (217855) | more than 3 years ago | (#33998020)

Doesn't matter who requested it. It was deliberately kept secret for over a week. This happens *a lot* in open source, and sometimes the time frame is months.

My point is this:

1) Everyone embargoes vulnerabilities, including open source developers. Complaining because closed source vendors do it is the pot calling the kettle black.

2) Too many people believe the myth that bugs in Linux are fixed and distributed "overnight", because few people know that #1 is true.

This is why I stick to older kernels (1, Funny)

Anonymous Coward | about 4 years ago | (#33977446)

2.2.26 is still working great for me, thanks!

Re:This is why I stick to older kernels (0)

Anonymous Coward | about 4 years ago | (#33978536)

How about that S3 virge and 5x86 cpu?

NOW FIXED =/= FIX NOW AVAILABLE (0, Offtopic)

MichaelKristopeit 44 (1919584) | about 4 years ago | (#33977558)

slashdot = stagnated

Re:NOW FIXED =/= FIX NOW AVAILABLE (0)

Anonymous Coward | about 4 years ago | (#33977878)

"Linus Torvalds has committed a fix."

You don't know how git works, do you?

Re:NOW FIXED =/= FIX NOW AVAILABLE (0, Troll)

MichaelKristopeit 13 (1916014) | about 4 years ago | (#33978046)

git doesn't run itself, moron.

ur mum's face don't know how git works

Re:NOW FIXED =/= FIX NOW AVAILABLE (0)

Anonymous Coward | about 4 years ago | (#33978404)

No part of "now fixed" implies that git will automatically pull down updates (though it certainly can...). "Now fixed", means that the bug is "now fixed".

Not exactly rocket surgery.

Re:NOW FIXED =/= FIX NOW AVAILABLE (0, Flamebait)

MichaelKristopeit 13 (1916014) | about 4 years ago | (#33978564)

the exploit pathway still exists on every installation of linux kernels which have not been updated by their administrator...

it is NOT fixed. a fix is simply AVAILABLE.

you're an idiot.

Re:NOW FIXED =/= FIX NOW AVAILABLE (0)

Anonymous Coward | about 4 years ago | (#33978884)

The bug has been fixed. If you choose not to adopt the fix, that's your own issue.

Re:NOW FIXED =/= FIX NOW AVAILABLE (0)

MichaelKristopeit 13 (1916014) | about 4 years ago | (#33979032)

the kernel hole created by the bug is NOT fixed.

my only issue are the liars that write these stories and the idiots that publish them.

Re:NOW FIXED =/= FIX NOW AVAILABLE (0)

Anonymous Coward | about 4 years ago | (#33981708)

In other news, the linux vulnerability talked about here on slashdot several months ago still has not been fixed, because I have a single VM I keep running with an unpatched kernel, just so I can say "linux still has not fixed this bug".

you're an idiot.

Re:NOW FIXED =/= FIX NOW AVAILABLE (-1, Troll)

MichaelKristopeit 24 (1916798) | about 4 years ago | (#33981786)

no one said the bug wasn't fixed... the story title implies the "linux kernel hole" was fixed, when it clearly wasn't. any kernels compiled WHILE THE BUG WAS NOT FIXED are not fixed until the fix is applied.

you're an idiot.

why do you cower? what are you afraid of?

Re:NOW FIXED =/= FIX NOW AVAILABLE (0)

Anonymous Coward | more than 3 years ago | (#33984160)

You're being a dick.

Nobody is going to take you seriously unless you act like an adult. Sheesh.

Re:NOW FIXED =/= FIX NOW AVAILABLE (1)

MichaelKristopeit 12 (1916012) | more than 3 years ago | (#33986534)

you're being WRONG.

who are these bodies you're talking about? are you afraid to claim your identity and make an opinionated statement for yourself?

why do you cower? what are you afraid of?

you're completely pathetic.

the kernel holes created by the bug ARE NOT FIXED... SYSTEMS ADMINS STILL NEED TO APPLY THE FIX MADE AVAILABLE.

Re:NOW FIXED =/= FIX NOW AVAILABLE (0)

Anonymous Coward | more than 3 years ago | (#33993854)

Nobody's going to take him seriously, ever. Sheesh.

Re:NOW FIXED =/= FIX NOW AVAILABLE (0)

Anonymous Coward | about 4 years ago | (#33978052)

Just because a fix is committed doesn't mean it's widely available on all distros.

If it were MS, it would be months later (0, Troll)

Maarek (213279) | about 4 years ago | (#33977700)

Until the fix was sent out to everyone. Even though Apple and MS people find something like this with Linux, the issue is immediately fixed and distributed overnight rather then waiting for a committee from Microsoft to fix the problem months from now.

Re:If it were MS, it would be months later (1, Flamebait)

man_of_mr_e (217855) | about 4 years ago | (#33978698)

If by "immediately fixed" you mean nearly two weeks being kept secret by the kernel team while they worked on it, and you were vulnerable.. and if by "distributed overnight" you mean probably several more days before the various distros make it availble...

This bug was reported to the kernel team on 10/12, not yesterday.

Re:If it were MS, it would be months later (0)

Anonymous Coward | about 4 years ago | (#33979466)

It was reported in December? That's almost a year old.

Re:If it were MS, it would be months later (2, Insightful)

sjames (1099) | about 4 years ago | (#33982572)

And meanwhile, since practically nobody and nothing actually uses that protocol, just disabe it unless/until you apply the update.

Re:If it were MS, it would be months later (1)

man_of_mr_e (217855) | more than 3 years ago | (#33998032)

Yes, that would have been great, had people known about the vulnerability when it was discovered. Instead, it was kept secret for nearly 2 weeks.

Re:If it were MS, it would be months later (1)

hairyfeet (841228) | about 4 years ago | (#33982154)

Oh c'mon! Quit trying to build straw men here! This is NOT about the policies of Apple or MSFT, this is about why they didn't issue the simple workaround instead of sitting on it for TWO WEEKS while leaving users vulnerable! If you think MSFT had pulled the same thing people wouldn't be roasting their nuts here? so why does Linus get better treatment? If you want to compare to MSFT, fine. MSFT often issues workaround for bugs they haven't gotten fixed yet. Considering if the above poster is correct we are talking about a single line that needed to be input would it REALLY have put them out to say "Hey, there is a problem, we're on it. Until we push out the patch run this. Thanks", I mean really? when we are talking about the #1 most popular Linux distro having a hole in the default config I really don't think it is too much to ask for them to issue the workaround. Do you?

Re:If it were MS, it would be months later (1)

LingNoi (1066278) | about 4 years ago | (#33983464)

Saying as such would let criminals know the issue exists before the CVE was even posted. You might as well have just said "hey everyone, there's a security exploit here that we haven't figured out how to fix". What is the point except for giving criminals an extra week to come up with a working exploit.

Re:If it were MS, it would be months later (0)

Anonymous Coward | about 4 years ago | (#33983596)

The point is not the approach, it's the double standard. What you're suggesting is exactly how MS handle this - they sit on the exploits and don't even let people know they're at risk, and they get absolutely blasted. You're suggesting that Linus et al should act exactly the same way, but that when they do it it's somehow a good thing? No, that duck won't quack - people generally use Linux because they like the added security and they're generally happy to take additional steps to plug exploits, but we need to know what the exploits are in order to do that. Security by obscurity might be good enough for the average Windows user, but the average Linux user is expecting more.

moSd 0p (-1, Offtopic)

Anonymous Coward | about 4 years ago | (#33977966)

be treated by your the NetBSDb project,

now fixed? (1)

grikdog (697841) | about 4 years ago | (#33978258)

Was this vulnerability fixed in yesterday's massive security update?

Re:now fixed? (0)

Anonymous Coward | about 4 years ago | (#33978764)

Tested the exploit in a fully updated Ubuntu 10.10 and it doesn't work. That may or may not answer your question.

Re:now fixed? (2, Informative)

TeknoHog (164938) | about 4 years ago | (#33979504)

The fix mentioned in TFA is also in the 2.6.36 changelog. So if you use the latest vanilla kernel, it is already fixed.

Doesn't work for me (0)

Anonymous Coward | about 4 years ago | (#33978418)

I am running the 2.6.36 kernel (issued yesterday). Now I've had a lot of security updates in the past couple of days, but I can confirm that I *do* compile RDS into the kernel:
CONFIG_RDS=m
CONFIG_RDS_RDMA=m
CONFIG_RDS_TCP=m
# CONFIG_RDS_DEBUG is not set ...and so I thought: well, lets try this out, so I got the exploit, and compiled it:
gcc rds.c -o rds ...and then ran it as an ordinary user:
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
  [+] Resolved rds_proto_ops to 0xffffffffa0c7f8a0
  [+] Resolved rds_ioctl to 0xffffffffa0c78000
  [+] Resolved commit_creds to 0xffffffff810771c0
  [+] Resolved prepare_kernel_cred to 0xffffffff81077690
[*] Overwriting function pointer...
[*] Triggering payload...
[*] Restoring function pointer...
[*] Exploit failed to get root. ....and so it didn't work. Just for hoots and hollers I log in as root (Ubuntu normally wants people to use sudo everywhere, but I always get around that in about 20 seconds usually right after install)
so as root I re-ran it:
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
  [+] Resolved rds_proto_ops to 0xffffffffa0c7f8a0
  [+] Resolved rds_ioctl to 0xffffffffa0c78000
  [+] Resolved commit_creds to 0xffffffff810771c0
  [+] Resolved prepare_kernel_cred to 0xffffffff81077690
[*] Overwriting function pointer...
[*] Triggering payload...
[*] Restoring function pointer...
[*] Got root!
# exit
(but I already *was* root, so its not really a 'got it' but more of a 'have it'). ...There were 2 massive security updates yesterday, and I see another set just popped onto the toolbar here a few minutes ago, and I'll probably run them in a sec, they only take a minute and its not like you have to stop what you are doing for them or anything. I wonder if they kept RDS exploits from being any kind of news?

Sheesh (-1, Flamebait)

Anonymous Coward | about 4 years ago | (#33978504)

Every two days another hole in linux, another vulnerabilty, those boys run a loose ship. Lets get this tightened up. Pronto!

Clearing up some questions... (5, Informative)

Anonymous Coward | about 4 years ago | (#33978900)

Sorry for the Anonymous Coward reply, I don't have an account in my name. I'm the researcher who discovered the vulnerability and published it. Just thought I'd clear up a few issues:

1. Stock installations of Ubuntu, Debian, Fedora, Red Hat, Arch, Slackware, and SuSE (and probably more) >= 2.6.30 are (or were) all vulnerable to the issue. Ubuntu has already issued an update, which is why some people can't get the exploit working on their Ubuntu machines. Even if the proof-of-concept doesn't work on your machine, if you have an unpatched machine that compiles RDS as a module, you are vulnerable and should patch.

2. Just because something is "compiled as a module" doesn't mean you have to explicitly have an administrator load it in order for it to be used. Networking protocols can be loaded at runtime by unprivileged users on nearly every distribution, including RDS. This is part of a broader security problem in the Linux world that should be improved.

3. No one should be complaining about the week-long period after reporting before disclosure. The Linux security folks upstream would have published the fix the day I reported the issue, except I specifically requested an embargo period of one week, during which downstream distributions could prepare updates. If I hadn't requested this embargo, then the fix would have been published immediately, but distribution users would have had to wait for their respective distributions to put together updates.

Re:Clearing up some questions... (0)

Anonymous Coward | about 4 years ago | (#33979226)

Stock installations of Ubuntu, Debian, Fedora, Red Hat, Arch, Slackware, and SuSE (and probably more) >= 2.6.30 are (or were) all vulnerable to the issue.

Stock RedHat5.5 runs 2.6.18 with security patches. My guess is that RDS isn't available.

Not reading the entire sentence as usual (1)

dbIII (701233) | about 4 years ago | (#33981902)

Yes, but you can put a newer kernel on it if you really want to, which is why there is the ">= 2.6.30" part in the sentence.

You see what happens? (1)

callmebill (1917294) | about 4 years ago | (#33979338)

goto fallback;
goto repeat;

See? If gotos are outlawed, only outlaws will have gotos.

SELinux (1)

metrix007 (200091) | about 4 years ago | (#33980518)

Would SELinux not protect against this?

Works here (0)

Anonymous Coward | about 4 years ago | (#33980768)

Just tried it on a few of my systems (and a friend's). So I can tell you it works on stock Fedora 14, Fedora 13, Ubuntu 10.10 and Debian sid (kernel 2.6.32). But it did NOT work on Debian 5 (lenny) (kernel 2.6.26).

Consistent with what the article says, but still pretty scary. Again, though, it's a local exploit only.

So there ya go.

"Linux Operating System" (1)

Khyber (864651) | about 4 years ago | (#33983672)

"The open-source Linux operating system"

LINUX IS A FUCKING KERNEL. The distros comprise the operating system.

Until /. can make this distinction and keep it consistent (and totally disavow any article containing the phrase 'Linux Operating System') this site should not be operating as any sort of distribution site.

It's just as bad as Fox with the spouted nonsense in the actual story.

Sorry, Tako (octopus,) you need to lose your geek-cred license for this site until your brain-dead editors can get their shit right.

Some furniture may have aluminum as an (1)

aotian (1915400) | more than 3 years ago | (#34070124)

Some furniture may have aluminum as an accent. If your furniture has aluminum, you can use mild detergent mixed with warm water, as your furniture cleaning solution. nhl jerseys [nfljerseyspub.com] , in an initial day of meetings with China's leadership nfl jerseys [nfljerseyspub.com] , stressed cooperation on pressing economic nba jerseys [nfljerseyspub.com] , security and environmental challenges mlb jerseys [nfljerseyspub.com] , rather than focusing on issues like human rights and soccer jerseys [nfljerseyspub.com] religious freedom that have historically divided the U.S. and MBT shoes [buy2shoes.com] China .Mrs. Clinton announced Saturday that her Chinese counterpart cheap mbt shoes [buy2shoes.com] , Minister of Foreign Affairs Yang Jiechi wholesale ugg boots [buy2shoes.com] , will visit Washington in early March to help coordinate a U.S.-China response wholesale Christian Louboutin shoes [cl-shoescom.com] to the global economic crisis ahead of the Group supply cheap Christian Louboutin shoes [cl-shoescom.com] of 20 summit in April in London.Hillary Clinton attends sell discount Christian Louboutin shoes [cl-shoescom.com] a news conference with Yang Jiechi buy cheap nike tn chaussures [max-tn-chaussure.com] , China's minister of foreign cheap nike chaussures [shox-chaussures.com] Using a sponge or washcloth, dab it with your solution and rub the aluminum legs and arm rests.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?