Linux bug bestows attackers with 'superuser' powers Security researchers have disclosed a vulnerability in the Linux operating system that allows unprivileged users to gain “superuser” rights on target systems. The bug in the Linux implementation of RDS, or reliable datagram sockets, protocol can be exploited by local users by sending specially manipulated packets that write …
Extracted from link in article
The following timeline details Linux's response to the reported issue:
2010-10-13 Vulnerability reported to Linux security team
2010-10-13 Response, agreement on disclosure date
2010-10-19 Fix publicly committed [3]
2010-10-19 Coordinated disclosure
There is also a workaround until you get/compile a new kernel
No one likes people being as smug and childish as you. You really don't help the rest of the Linux community and your attitude only perpetuates the Linux / Windows flame wars.
For every example you can come up with someone else can come up with a counter-example. For instance: http://www.theregister.co.uk/2010/08/19/linux_vulnerability_fix/ There are also many examples of MS fixing security flaws in record time.
The same Tavis Ormandy who was lambasted by people like Graham Clueless, and similar talking heads from the "Chattering classes" of the security press, for the way he released details of the security vulnerability in Windows Help and how to exploit it, after waiting just five days, from notifying Microsoft of it, to going public.
I guess this is only a problem if you can't manage less than five day's turnaround.
It may have been fixed, but if that fix isn't in the repos (it isn't, for CentOS at least, I just did an update) it isn't a very fixy fix, is it?
This is a bit of a problem with Linux, lots of fixes are made within minutes or hours, but they're untested and unstable. These fixes go into the daily unstable releases and then are updated when they find bugs or incompatibilities with other bits of software. After a while these are ironed out and the fix is moved into stable releases, this can take weeks after the initial "fix".
Now, I'm a big fan of Linux, but this misrepresentation does no-one any favours, it makes for a false sense of security which is never a good thing.
....are you?
Never mind the vendor kernels, or the unstable kernels. If you're really worried about this, then you will know how to patch, compile and install a fixed kernel which will hold things until the fully tested stuff appears.
Otherwise you say "OK, only a local vulnerability, I can live with that, I'll just disable RDS for now with a kernel parameter".
Keep it in perspective folks, there will no doubt be other vulnerabilities in your LinMacWin box, and you use that every day without getting worried.
I may well be able to fix my machines at home if I choose, but if I suggested manually recompiling the kernel of our RHEL servers at work the following would happen:
1) Red Hat would stop supporting those servers
2) Everyone would laugh at me
3) My career path would take a hit
In big companies vendor support is crucial, if a problem were to occur with software incompatibilities caused by making a change to server software without vendor approval, they wouldn't help us fix it. So, the point remains, it isn't a fix until the vendor puts it into the repos or publishes a supported workaround.
"If you're really worried about this, then you will know how to patch, compile and install a fixed kernel "
This attitude goes completely against the theory that Linux is ready for the non techies. With 20 yeras of IT, I could have compiled a kernal a few years ago but since I havent needed to in over 5 years, I wouldn't know where to start anymore.
As many people have pointed out : if you are REALLY worried about this than it's possible to do something about it now, or more simply use the workaround. Most people don't have to do anything, just wait for their distro updates (unless their system's security is poor - in which case they have other worries)
As I have pointed out - wait for the update then. There's no problem unless your existing security is lacking.
I also find it hard to believe that you can't apply the simple workaround or remove the module altogether without the vendors says so - if that's the case why have a sys. manager at all ?
The problem was fixed is "warp time" compared to other operating systems. If this were any other operating system, it would have taken MONTHS to find the problem, and probably YEARS to fix it (on a Tuesday), if it is fixed at all.
Of course this is about a feature that probably isn't in the "other operating system".
C:\> NBTStat -A 192.168.1.111
C:\> IFMEMBER /v /l "MyDomain\Administrators"
C:\> mountvol ss64 \\?\Volume\{2eca0889-5cf-43d3-aff8-7e8511f60d0e}\
C:> PORTQRY -n 10.0.0.1 -e 53 -p UDP -i
C:> RUN REGSVR32.EXE wuaueng.dll
Nothing wrong with hacking Hive Keys with 32-bit hexadecimal numbers, for names in RgeEdt, is there? Or error messages which give the exact hexadecimal value, of the paging address, where a memory-sharing violation occurred (singular, in stating exactly what went wrong, while imparting no useful information whatsoever).
What you see above is a method to turn off user verification on machines that permit it.
This is not something you'd want in a GUI app - it's only something to be done by someone who knows what they are doing, and in certain very specific situations (e.g. lost root password). It's not *supposed* to be easy...
Vic.
which seems in this case to refer to persons with actual physical access to the computers in question, as compared to the case of Windows users, in which it seems to mean anyone on the same planet. Or perhaps I have misunderstood - Dan Goodin's article doesn't have a lot to say on this matter....
Henri
The key phrase is indeed "local users", however the key *word* is "user".
This particular attack starts with the loading of a kernel module followed by writing arbitrary data to a specific port, hence the choices of phrase are between "local root" (clearly overkill for an escalation exploit), "local user" (best candidate because the procedure is most easily performed with a shell account), and any remote access (where, due to the extent and complexity of the procedure on a typical box, you'd probably need multiple [other] exploits to exist to get outside-world system service/s to misbehave appropriately).
Is that many of the security compromises you get on hosting platforms - malicious php code, XSS exploits and such, run as a local user - be it 'www-data' or 'nobody' (or even another user is suphp or suexec is used).
While this may not affect your average home linux user, any public facing linux server which has some vulnerable PHP code or exploitable daemon out there is now rootable. Im very much in the pro linux camp and its way orders of magnitude more secure than some other o/s's but local root exploits are very dangerous when combined with public facing servers.
> many of the security compromises you get on
> hosting platforms - malicious php code, XSS
> exploits and such, run as a local user
Yes. But that's not really a problem.
To exploit this vulnerability, you need to call a kernel API on a vulnerable system. You need to find the appropriate value for kernel symbols (either via /proc/ksyms or from System.map, depending on your setup). Then you need to perform an RDS socket operation to effect the exploit.
PHP doesn't support the above - getting the symbol map will be difficult unless you've already exploited the box sufficiently to find it (and that really means already having root access), and PHP doesn't support RDS sockets. Nor does Perl. The sort of compromise you're talking about just wouldn't work.
The real vulnerability is where an attacker can inject and run a binary - but such exploits are few and far between, and obviated by mounting the webroot as noexec.
So whilst this is a real vulnerability, and very embarassing for all concerned, it's actually very unlikely to be exploited unless you have real users with real console logins who want to escalate their privileges.
Vic.
All software has bugs, Linux is not special it has bugs too.
What matters is how many bugs there are, what in-built mitigation there is and how quickly they get fixed.
A lot of "core" open source software, including the Linux kernel has fewer defects per line than some proprietary equivalents, Linux/Unix have a better history of internal mitigation than some desktop operating systems and main open source projects have very quick turn around in relation to security defects relative to some proprietary software.
"open source software, including the Linux kernel has fewer defects per line than some proprietary equivalents"
I can only assume you have some kind of metrics for that, and for something at least marginally more specific than 'some' proprietary software, otherwise it is completely meaningless.
But the basics haven't really changed much.
http://www.wired.com/software/coolapps/news/2004/12/66022
The key paragraph for the sake of this particular discussion is:
"The report, set to be released on Tuesday, states that the 2.6 Linux production kernel, shipped with software from Red Hat, Novell and other major Linux software vendors, contains 985 bugs in 5.7 million lines of code, well below the industry average for commercial enterprise software. Windows XP, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis.
Commercial software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium. This would be equivalent to 114,000 to 171,000 bugs in 5.7 million lines of code."
Does that help make it clearer?
Every month we get the Patch Tuesday list of fixes which often include security fixes and no one much bats an eyelid. We expect these every month, it's not news, every month there's a new list.
On the other hand, when two local exploits in Linux found and fixed it's newsworthy. It's newsworthy because it doesn't happen often. The fact that security flaws aren't often found in something that's open to public scrutiny and are often found in something that's not open to public scrutiny surely tells you something.
Still, it's interesting to watch the fanbois all leaping around making idiots of themselves.
Great, so the kernel team managed to introduce a root bug with their first release of a new feature. Good work fellas. Of course since you are all open and stuff, we wont rag on you the way would if some dumb ass like Microsoft had released code with stupid holes in it. We'll overlook the fact that it ought to have been a no brained to check code that writes to kernel memory.
And because we don't bother to keep up with the constant stream of vulns disclosed on mailing lists, or research forums, or bother to check CVE updates, or have a clue, we'll also pretend that security bugs in Linux software are rarer than rocking horse shit. What's that ? Dozens ? A month ? Lallalalalalalalalalala, see, I've got my fingers in my ears!
“a low impact vulnerability that is only of interest to security professionals and system administrators"
Of course! Like all Linux bugs that can be exploited to execute arbitrary code as root, because everyone knows only good, honest, open, gentle people would know how to exploit Linux!
"Lallalalalalalalalalala, see, I've got my fingers in my ears!"
You sir.... Are a troll.
Linux, Windows, Mac are all great OS's. They all have security issues in the code that get discovered everyday. What I like about Linux is it takes a few minutes to apply updates compared to half hour for MS.
Last security updates from MS borked my .NET Framework 4.0 and told me that "This copy of Windows isn't genuine because there was an unauthorized change to the system. You need to reinstall Windows to fix this"!! It was created by the record breaking amount of updates they needed to secure it. I have heard of similar stories on the Linux side but they were fixed without re-installation.
I do not understand why people act like they have vested interest in any OS??
because of it's design: "it has no design, and will never have a design" - Linus Torvalds.
Linus means that Linux should evolve like in biology: constantly morphing and recreating until a superior species has been mutated. Linux is constantly rewritten all the time. The code is always in beta stage. There is always new code, and when the code matures and the bugs irons out, it will be rewritten again and introduce new bugs.
Linux is constantly in beta stage.
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
