Weekly Edition
Return to the Security page
| |||||||||||||
Security quotes of the week
This has been a public service announcement made necessary by some damn' fool European Commission directive that confused a goal (securing web users' privacy) with a technology (cookies). Film at eleven.
-- Charlie
Stross
Let's say you chose NOT to accept any cookies from bbc.com (most people are going to tend toward a binary decision -- all or none -- not try to micromanage their cookies). The result of blocking all BBC cookies will be that (apparently) you'll be forced to see this banner over and over and over ... and over again. How do you stop it? By accepting BBC cookies of course!
-- Lauren Weinstein
When I helped to develop the open standards that computers use to
communicate with one another across the Net, I hoped for but could not
predict how it would blossom and how much human ingenuity it would
unleash. What secret sauce powered its success? The Net prospered precisely
because governments — for the most part — allowed the Internet to grow
organically, with civil society, academia, private sector and voluntary
standards bodies collaborating on development, operation and governance.
-- Vint
Cerf worries about the future of the internet
Even though humans produce distributions with pitifully few bits of
security, I think passwords will always be with us. As one component in a
system with many layers, passwords can be valuable as a low-cost
authentication mechanism which nearly all people can do with no special
equipment. The important thing is to stop considering them the first and
last step in authentication.
-- Joseph Bonneau
These days I'd argue that multi-user is such a corner case that it's
not worth optimizing for it as far as defaults are concerned. If
you're trying to run a secure multi-user system, you need to be an
expert system administrator, keep up with all security patches, and
even then, good luck to you. (The reality is that these days, no
matter what OS you're talking about, shell == root. And that's
probably even true on the most unusably locked down SELinux system.)
-- Ted Ts'o(Log in to post comments)
Security quotes of the week Posted Jun 1, 2012 7:57 UTC (Fri) by malor (subscriber, #2973) [Link] (The reality is that these days, no matter what OS you're talking about, shell == root. And that's probably even true on the most unusably locked down SELinux system.)That's because you guys suck, and don't give a fuck about security. It doesn't have to be that way, but you guys, through your deliberate ignoring of security, have made it that way. It's YOUR FAULT. Jerks. Linux is not trustworthy any more in a security context, which is most clearly demonstrated by your own inability to provide secure shared access on kernel.org.
Security quotes of the week Posted Jun 1, 2012 12:25 UTC (Fri) by hummassa (subscriber, #307) [Link]
You are SO wrong... The reality is that shell Always equaled root, and it always wil! Only now we have a little bit of awareness of that fact.
Security quotes of the week Posted Jun 1, 2012 13:54 UTC (Fri) by malor (subscriber, #2973) [Link] Only on Linux, and it is utter, absolute bullshit that it always needs to be that way.These guys spit in the face of the security community, and now they've dug themselves in so deep that they no longer can offer secure shared access to hardware. Their kernel is so rickety that they're scared to even try to offer shared access themselves. They won't eat their own dog food, because they have fatally compromised one of the two fundamental layers of Unix-style security. It used to require two exploits to own a box, a user-level exploit and then a root-level exploit, but now it only really takes one. To get any kind of reasonable security at all, we have to turn to extremely inefficient virtualization instead. We have to haul around a whole separate kernel for each user, because these assholes have been trivializing and laughing about security for a decade now. Security is hard, but it can absolutely be done, with the right focus. Sneering at the security community, and then actively lying about patches that fix security problems, is not the way to go about doing that. They're starting to figure out, finally, that their security is SHIT. Now the question becomes, are they willing to step up and fix their mess, or do people die because of security compromises, where people were foolish enough to trust Linux with data that could get them killed? This stuff matters. It matters desperately for a substantial fraction of the world's population. And if they trust Linux with their data, they may end up dead. If the kernel hackers don't have blood on their hands already, they eventually will.
Security quotes of the week Posted Jun 1, 2012 15:24 UTC (Fri) by etienne (subscriber, #25256) [Link]
> Security is hard, but it can absolutely be done
When the owner/defender of a Linux system refuses to pay anything (only beer-free software) and demands every undocumented hardware supported by windows to be supported by Linux for free;
Security quotes of the week Posted Jun 1, 2012 16:50 UTC (Fri) by AndreE (subscriber, #60148) [Link]
What fraction of the world's population needs this work or will end up dead? "Blood on their hands" sounds a bit dramatic.
Security quotes of the week Posted Jun 1, 2012 17:15 UTC (Fri) by hummassa (subscriber, #307) [Link]
> Only on Linux
On ANY Windows OS, privilege escalation is available the moment you log in.
Ditto for MacOSX.
It has been 15 years or more since I have seen other Unices in the wild (where I work nowadays used to be a Windows98 + Slowlaris/x86 shop some ten years ago, but the SunOS part of it was quickly replaced by Linuxes, and it was restricted to the Oracle server at the time).
Security quotes of the week Posted Jun 1, 2012 21:10 UTC (Fri) by dgm (subscriber, #49227) [Link]
What is more important, begin secure or being used? Look at Windows and answer it to yourself in the most honest way you can. And no, it's not a question of trade-offs (they are not mutually exclusive) but of focus.
Security quotes of the week Posted Jun 4, 2012 10:59 UTC (Mon) by jschrod (subscriber, #1646) [Link]
> It matters desperately for a substantial fraction of the world's
> population. And if they trust Linux with their data, they may end up dead.
Drama queen.
A tip: Tone down your hyperbole to a realistic level, and people might start to listen to you. Forecasting »death« for »a substantial fraction of the world's population« owing to their potential use of Linux, reads like paranoia, and not like a serious contribution to a discussion. Not using profanity will probably help, too.
Security quotes of the week Posted Jun 2, 2012 2:05 UTC (Sat) by vonbrand (subscriber, #4458) [Link] I'd like some kind of proof for this "fact"...
Security quotes of the week Posted Jun 2, 2012 10:08 UTC (Sat) by hummassa (subscriber, #307) [Link]
What kind of proof do you want? Formal proof? I don't think it's a problem that was ever solved formally. But I can tell you that: for the last 20+ years, I'm a guy people call when they have problems of the kind "my old sysadmin has gone away and took the root password with him. I need to give a new root password to the new guy without downtime". And this has been possible in all those years, in old unices, in Linux, in Windows and in other OSes. Google "privilege scalation Windows 7". Simple as that. I used to have a diskette box with all the rootkits etc ready for 5+ platforms in the early 90s.
Security quotes of the week Posted Jun 4, 2012 2:24 UTC (Mon) by vonbrand (subscriber, #4458) [Link] And the fact that Windows 7 is vulnerable is relevant for Linux/Unix security because...
Security quotes of the week Posted Jun 4, 2012 14:46 UTC (Mon) by hummassa (subscriber, #307) [Link]
> And the fact that Windows 7 is vulnerable is relevant for Linux/Unix security because...
... it is/was/can be a POSIX system?
... it is widely used in desktops and in servers?
... in this discussion, people keep bringing "you cannot trust Linux with your data" when, in reality, you cannot trust any OS with your data because there is no such thing as a secure multiuser system?
... my example "privilege escalation Windows 7" could have been "privilege escalation OSX" or "privilege escalation Linux" or even "privilege escalation OpenBSD" and the results would have been analogous?
Enough?
Security quotes of the week Posted Jun 5, 2012 0:18 UTC (Tue) by vonbrand (subscriber, #4458) [Link] >> And the fact that Windows 7 is vulnerable is relevant for Linux/Unix security because... > ... it is/was/can be a POSIX system? Nobody sane uses the POSIX system on Windows. And again, whether the POSIX system of Windows 7 is easy to subvert has next to no bearing on Linux' security > ... it is widely used in desktops and in servers? Again, if Windows 7 is widely used (or not) has no relation whatsoever to Linux' security. > ... in this discussion, people keep bringing "you cannot trust Linux with your data" when, in reality, you cannot trust any OS with your data because there is no such thing as a secure multiuser system? Sure, if we accept that there are no secure multiuser systems then Linux isn't secure. But that begs the question. > ... my example "privilege escalation Windows 7" could have been "privilege escalation OSX" or "privilege escalation Linux" or even "privilege escalation OpenBSD" and the results would have been analogous? Sorry, it isn't enough to ask people to go looking on Google for random problems to prove your point. If you do have a recent example of a way to leverage non-privileged user shell access to root on a reasonably installed (for example, default configuration for a development station on an up to date(ish) mainline distribution, no "disable SELinux" nor "install random junk"), I'd listen. But only given enough details to repeat the feat. And the OpenBSD folks will sure be very interested if you pull it off on their system. Extraordinary claims require extraordinary proof. > Enough? Sorry, not by a long shot.
Security quotes of the week Posted Jun 5, 2012 1:53 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
>Sorry, it isn't enough to ask people to go looking on Google for random problems to prove your point. If you do have a recent example of a way to leverage non-privileged user shell access to root on a reasonably installed (for example, default configuration for a development station on an up to date(ish) mainline distribution, no "disable SELinux" nor "install random junk")
You must be very naive. There is at least one local Linux rootxploit every year, sometimes more often. Right now, no _public_ exploits exist that I'm aware of. But I'm absolutely certain that there are non-public exploits.
Here is the most recent one: http://blog.zx2c4.com/749 (I'd tried it on my box when it came out - it worked).
Security quotes of the week Posted Jun 5, 2012 2:04 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
harping on how insecure linux is implies that if you only avoid using linux, you will be safer.
the reality is that every OS has problems at some point. I don't think that anyone disputes that.
however there are systems that are less secure than others. OpenBSD is one of the better ones (assuming you can actually live with the small feature set supplied)
even in linux distros, there is a wide variety of default security (depending on what is installed), and just about any desktop distro is going to have more vulnerabilities than the server distros. This is in part due to the fact that desktop developers tend to worry less about security, but mostly due to the fact that there is just less stuff installed on the system.
Security quotes of the week Posted Jun 5, 2012 2:16 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
No, harping on how "general shell Linux access equals root" means that if you try to avoid giving malicious code shell access then you'd be safer.
I.e. "sandboxes are vital, not just a good idea".
>however there are systems that are less secure than others.
I'd even argue that Windows with a recent antivirus is more secure than Linux.
>OpenBSD is one of the better ones (assuming you can actually live with the small feature set supplied)
Security quotes of the week Posted Jun 5, 2012 2:27 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
sorry, you can't have it both ways.
you can't both disagree with the statement that some systems are more secure than others, and then say that Windows with current AV is more secure than Linux.
Security quotes of the week Posted Jun 5, 2012 17:18 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, I can.
No widely-used operating system is secure (well, maybe OS on XBox360 is an exception). All of them are guaranteed to have unpatched exploitable holes.
However, if we treat security as a continuum then Windows with an antivirus is more secure simply because more layers of security.
Right now once a program gets root access on Linux - it's game over. It can do whatever it pleases with the kernel and the system. Antivirus programs on Windows at least try to defend system from such attacks and working around them is definitely not trivial or simple.
Security quotes of the week Posted Jun 5, 2012 17:32 UTC (Tue) by dgm (subscriber, #49227) [Link]
> Windows with an antivirus is more secure simply because more layers of security.
Isn't your theory in glaring contradiction with reality?
Security quotes of the week Posted Jun 5, 2012 17:58 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Not really. Linux is simply not targeted yet. And where it's targeted (Android) it behaves like a leaky sieve.
BTW, WinPhone is the only non-jailbroken mobile OS so far.
Security quotes of the week Posted Jun 5, 2012 18:16 UTC (Tue) by hummassa (subscriber, #307) [Link]
> BTW, WinPhone is the only non-jailbroken mobile OS so far.
"Windows Phone 7 unlocker released to side-load applications"
(from Nov 2010)
LOL.
Security quotes of the week Posted Jun 5, 2012 18:23 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
And? Care to actually read your article?
You can sideload apps using an _officially_ _sanctioned_ _mechanism_ ( http://arstechnica.com/information-technology/2011/11/why... ), but you can't get root access using it.
I.e. no jailbreak. Microsoft thinks about security very seriously, unlike certain Linux developers and vendors.
Security quotes of the week Posted Jun 5, 2012 18:32 UTC (Tue) by hummassa (subscriber, #307) [Link]
The default user already has administrative access to the machine! This is the exact definition of jailbreak... If I can read and write any files and I can read and write all registry keys, what else do you want? You have full, root, control of the machine... There is no jail!
> Microsoft thinks about security very seriously, unlike certain Linux developers and vendors.
Now I will have to think you are just trolling me. Are you? Sorry I have fallen for it.
Security quotes of the week Posted Jun 5, 2012 19:00 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
>The default user already has administrative access to the machine!
Not on Windows Phones.
You can access only public API accessible from C#, but nothing more. You can't run arbitrary native code or tinker with raw devices. Oh, and Microsoft can remotely uninstall any of your side-loaded programs.
>Now I will have to think you are just trolling me. Are you? Sorry I have fallen for it.
Linux proponents should look around more often.
Security quotes of the week Posted Jun 5, 2012 19:22 UTC (Tue) by hummassa (subscriber, #307) [Link]
> You can access only public API accessible from C#, but nothing more. You can't run arbitrary native code or tinker with raw devices. Oh, and Microsoft can remotely uninstall any of your side-loaded programs.
If you are not kidding, then you really drank too much kool-aid.
http://www.wp7roottools.com/index.php/guides/native-code
(how to make your app access native-code and bypass policy on mango)
Let me try to explain it to you: what you are proposing (total lockdown) is virtually impossible in an environment so "tinkerable" as the one you'll find in a general purpose computing device.
And a smartphone is a general purpose computing device.
On Windows, every successful malware of the last ten years knew how to disable antivirus protection before trying to infect the machine. And they all do that with administrative privileges on.
There is no 100% locked-down Windows, not even in the Xbox or on Windows Phones. They all have been unlocked, and the time to unlock a new version is still on the league of a couple of months of pouding by a loose team of volunteers (in opposition to, for instance, a nicely-paid and focused team of Uncle Sam's employees)
There is no 100% locked-down OpenBSD.
There is no 100% locked-down Linux.
Does this mean we should give up? No. We should try to plug all the holes. But because (1) the system is not programmed in an overflow-safe language (buffers and integers), (2) the system is not programmed in a security-correctness-proofing way like seL4 [*], and (3) we don't have the manpower or the right tools right now to do (1) and (2), we have to make compromises.
Security quotes of the week Posted Jun 5, 2012 19:49 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Can you actually read what you post?
All unlock methods require developer access, which is granted on per-device basis and is available only on unlocked devices. Basically, on devices where Microsoft allowed it to work.
There's no 'jailbreak' in the sense of iPhone jailbreaks where a bug somewhere in iOS is exploited to gain root access.
>Q: I've a Lumia 800 or 710 can I Interop-Unlock it?
>There is no 100% locked-down Windows, not even in the Xbox or on Windows Phones.
Security quotes of the week Posted Jun 5, 2012 19:53 UTC (Tue) by hummassa (subscriber, #307) [Link]
> XBox 360 is also unhackable. It's unlikely to be hacked before its useful market life ends.
Just told you, it has already been hacked. The thing is there, on top of the table, running sideloaded games AND connected to Microsoft Live or whatever.
Security quotes of the week Posted Jun 5, 2012 20:03 UTC (Tue) by jimparis (subscriber, #38647) [Link]
> XBox 360 is also unhackable. It's unlikely to be hacked before its useful market life ends.
Do you mean "hacked again"? Because it was already hacked once. If you never really change a platform but just keep plugging the security holes as they become publicized, then sure, eventually you'll have plugged most of them.
http://www.securityfocus.com/archive/1/461489
Security quotes of the week Posted Jun 5, 2012 22:22 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
It was hacked only using JTAG (hardware debug interface), not via software hacks.
Ok, I stand corrected - it might be possible to hack XBox with hardware access enabled.
However, recent WP phones are still not hacked. MS's protection seems to be working.
Security quotes of the week Posted Jun 5, 2012 22:47 UTC (Tue) by jimparis (subscriber, #38647) [Link]
> It was hacked only using JTAG (hardware debug interface), not via software hacks.
That's just not true. Please, read the links.
The "King Kong exploit" utilized the ability to read/write arbitrary system memory using shaders on the GPU. This is done by modifying the unsigned shaders on a King Kong game demo. It does require that you modify the firmware on your 360's DVD-drive to be able to run a burned disc, but it's just a SATA drive and modifying firmware involves plugging into a PC and running an updater.
From there, it's purely software to exploit a software hole in the hypervisor's system call interface and gain full access.
Security quotes of the week Posted Jun 5, 2012 18:29 UTC (Tue) by hummassa (subscriber, #307) [Link]
"How to sideload apps onto WindowsPhone/Lumia devices"
https://www.youtube.com/watch?v=1Txv6ldiNqo
"OpenBSD privilege escalation"
And yes, my PS3 has "the best of both worlds" in it, thanks to carefully-planed updates.
And XboXers apparently can sideload apps too...
Oh man.
Security quotes of the week Posted Jun 5, 2012 19:05 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Guys, I've actually taken time to research the facts that I claim.
>"How to sideload apps onto WindowsPhone/Lumia devices"
>"OpenBSD privilege escalation"
>And yes, my PS3 has "the best of both worlds" in it, thanks to carefully-planed updates.
>And XboXers apparently can sideload apps too...
Typical.
Security quotes of the week Posted Jun 5, 2012 19:42 UTC (Tue) by hummassa (subscriber, #307) [Link]
>>And XboXers apparently can sideload apps too...
> Are you simply showing me results of "WP7 jailbreak" from Google search without even bothering to actually read it?
> Typical.
Why would WP7 and Xbox be related?
Anyway, none of your arguments for the safety of one or other held. People sideload their WP7/Mango phones with Native/ARM apps and they unlock and sideload programs on their Xboxes every single day (I just confirmed with an Xboxer coworker, and he explained to me that he has a ton of sideloaded games and his Microsoft Live account -- or whatever it's called these days works perfectly).
I'll try the http://www.wp7roottools.com/ SDK later today in my wife's Lumia, but I have few doubts that it'll just work also.
The only "typical" thing here is that you are putting your hands in your ears and singing "lalala" while people are trying to converse with you. You seem to want to believe so much that rootkits for windows+antivirus or for wp7 or for xbox do not exist that even when I show them to you, you cannot see. You even made the preposterous affirmative that "microsoft cares deeply for security" when the company's record with security issues is the worse possible -- they even make vulnerabilities linger for YEARS until they plug them.
Security quotes of the week Posted Jun 6, 2012 21:38 UTC (Wed) by hummassa (subscriber, #307) [Link]
> I'll try the http://www.wp7roottools.com/ SDK later today in my wife's Lumia, but I have few doubts that it'll just work also.
This surprisingly did not work, but on a Samsung Omnia 7 I did a "full unlock" and ran successfully wp7 root tools, which allowed me to read and write any file or registry key. Apparently, the so called "full unlock" is yet to come to Lumias, but progress has been made.
Security quotes of the week Posted Jun 5, 2012 19:55 UTC (Tue) by vonbrand (subscriber, #4458) [Link] Please explain how "any user can get root by officially sanctioned means" is any different from a security perspective than "a user can get root because of a stupid (or otherwise) programming/default setup/configuration mistake." If any, the former is much, much worse (because it probably won't be fixed, ever) than the later. Considering there is roughly a privilege escalation bug a year for Linux (as you claim), many of which were historically exploitable only when using a non-default setup, some weird hardware, or would have been masked by reasonably run-of-the-mill configuration, bugs that are normally fixed in a matter of days; makes your claims look like trying to start a full-blown hurricane in a teapot.
Security quotes of the week Posted Jun 5, 2012 20:04 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Because you need to get a developer key from Microsoft. And this key is linked to your device - you can't just give it to anybody else.
>Considering there is roughly a privilege escalation bug a year for Linux (as you claim)
>many of which were historically exploitable only when using a non-default setup, some weird hardware, or would have been masked by reasonably run-of-the-mill configuration, bugs that are normally fixed in a matter of days; makes your claims look like trying to start a full-blown hurricane in a teapot.
Security quotes of the week Posted Jun 5, 2012 18:13 UTC (Tue) by hummassa (subscriber, #307) [Link]
> Antivirus programs on Windows at least try to defend system from such attacks and working around them is definitely not trivial or simple.
LOL.
Security quotes of the week Posted Jun 5, 2012 19:05 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Care to expound?
Security quotes of the week Posted Jun 5, 2012 19:25 UTC (Tue) by hummassa (subscriber, #307) [Link]
Repeating the other thing there: every successful exploit on windows disables antivirus first thing after acquiring administrative privileges, right before installing the payload.
Security quotes of the week Posted Jun 5, 2012 19:55 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
"Disable antivirus"? Which one and how?
It's not a simple task. And exploiting the kernel is only the first part of it. Next you need to somehow isolate antivirus-installed hooks without tripping them and leave the system working.
Most malware actually doesn't try to do this. Instead it tries to stay quiet and do not trip any antivirus detection heuristics.
Security quotes of the week Posted Jun 5, 2012 20:30 UTC (Tue) by hummassa (subscriber, #307) [Link]
All of them. How many executable names for antivirus programs do you think there are? Interate ten to twenty of those, kill any running processes with those names, and you have disabled protection in 99% of the cases. At that point in the infection (just exploited root hole, nothing was written to disk yet) it's quite trivial.
Security quotes of the week Posted Jun 5, 2012 22:32 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Try it. Really, go on and try it with Kaspersky antivirus. Nothing will happen - you won't be able to kill antivirus' process. It's protected on the kernel mode level.
It also sets a lot of hooks and tries to monitor self-integrity, so even if you try to kill it by patching kernel process table or in any other obvious way - you'll simply trigger these hooks and either initiate a self-healing attempt or create a BSOD. It's possible to work around them, of course, but decidedly non-trivial. Even Flame malware doesn't try to do it - it simply stays under the radar.
Security quotes of the week Posted Jun 2, 2012 9:18 UTC (Sat) by AndreE (subscriber, #60148) [Link]
Can you explain further please? "Always will" in particular
Security quotes of the week Posted Jun 2, 2012 10:23 UTC (Sat) by hummassa (subscriber, #307) [Link]
As I told in my comment above, I don't have a formal proof of that statement. But things go more or less this way: once you have ANY access to a box, you can trip a vulnerability in the stack involved in the access, and from there you can trip another, and another and another until you have whatever you want from that box.
If you have SHELL access to a box, you already can do
echo BYTESBYTES > a.out; chmod +x a.out; ./a.out
where BYTESBYTES is a program with privilege escalation properties, because it trips some vulnerability on the shell or on libc or whatever.
IMNSHO, this will always (for a latu sensu definition of always) be that way because: (1) our systems programming language of choice today (C) is adversarial to the developer by making non-vulnerability-prone programs difficult to write (come on, before C with Classes I would have written C with Well-Managed Strings and Buffers And Access to The Overflow Flag); (2) programmers will always make mistakes; (3) with some rare, academical exceptions, we do not have a proven-secure programming (as in theorem proof) and those are rare and academical because we do not have a lot of proven-secure-capable developers. <rant>It's still hard to find developers that do not ignore the necessity of maintaining and passing my automated test suites, and those are not rigorous by any standards</rant>.
Security quotes of the week Posted Jun 4, 2012 12:29 UTC (Mon) by nix (subscriber, #2304) [Link]
Even if we had all of those things, it still would not help. All you need for privilege escalation vulnerabilities is a system with sufficiently many interacting parts that you can't hold them all in your head at once, where some of those parts act as switches that ask 'is privilege escalated?' or act to escalate privilege. All OS kernels are far, far into this domain. Even reducing the number of priv-test-and-set points to one each wouldn't help, because those points would be used from many places... the real enemy here, as in so many other places, is complexity -- but this is at least partly *necessary* complexity.
(For extra points, the system must have sufficiently many interacting parts that you can't formally prove that nothing done excepting a few specific intended things can lead to privilege escalation, but since to a first approximation nobody ever formally proves their code correct in this fashion this is overkill).
Security quotes of the week Posted Jun 1, 2012 13:07 UTC (Fri) by nix (subscriber, #2304) [Link]
Uh, part of the kernel.org compromise involved someone riding over OpenSSH from a compromised system. By your definition, the OpenSSH / OpenBSD guys "don't give a fuck about security". But in reality they give a fuck about little else.
Your definition is thus clearly flawed.
Security quotes of the week Posted Jun 1, 2012 13:35 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
> Uh, part of the kernel.org compromise involved someone riding over OpenSSH from a compromised system.
is that established fact? i thought a detailed account of what and how got compromised exactly had not yet been published.
Security quotes of the week Posted Jun 1, 2012 17:48 UTC (Fri) by nix (subscriber, #2304) [Link]
It was what was said here, and in many other places. I can't say if it's 'established fact' because I'm not in a position to know the facts for sure. (I don't think anyone who is has talked.)
Security quotes of the week Posted Jun 1, 2012 14:25 UTC (Fri) by copsewood (subscriber, #199) [Link]
shell == root
That's only really true for shell users who are both knowledgeable and determined to break security. Multiuser security still usefully secures Alice's data against Bob's mistakes if they have the degree of mutual trust needed to share use of a system. Alice and Bob should not maintain data on the same multiuser system otherwise. I thought the other use cases were got rid of some time ago.
Security quotes of the week Posted Jun 1, 2012 17:17 UTC (Fri) by hummassa (subscriber, #307) [Link]
All that goes out the window in the moment Alice or Bob access the WWW.
All it takes, then is ONE malicious webpage that grabs a shell... escale the privileges... and has full control.
Security quotes of the week Posted Jun 2, 2012 9:56 UTC (Sat) by copsewood (subscriber, #199) [Link]
The use case I had in mind was more about sharing use of expensive servers than client/desktops. If malicious code can hijack a web browser and break its sandbox in order to grab a shell on either a single or multiuser system then you've got much bigger concerns than whether more than one mutually trusting parties share machine use. Another security layer is needed if this risk needs mitigation for you or other users, e.g. running different instances of the browser within separate VMs or using suitable MAC policy enforcement tools on the browser software. One extra sandboxing layer instance probably wouldn't be enough, given that CSRF and XSS threats between sites regularly visited are going to be a greater risk in practice than a malicious website code getting shell on the client machine. As a minimum I'd recommend all financial browser use should be in a separate VM per user.
The issue here is far more to do with whether the browser is secure and needs fixing or containerising regardless of whether on a single or multiuser machine, than whether Alice and Bob can trust each other not to use such a browser when they have different accounts on the same shared machine on which typically either Alice or Bob but not both installs this software.
Cost effective risk management != absolute security
Security quotes of the week Posted Jun 2, 2012 10:47 UTC (Sat) by hummassa (subscriber, #307) [Link]
1. practically all browser use is "financial browser use"; we're both subscribers to LWN!
2. Cost effective risk management != absolute security => yes, but depending on your definition of "cost effective" you could as well have written "Santa Claus != Easter Bunny".
Today, when we have expensive and shared server in an enterprise, the sysadmin normally will NOT allow anyone to have a shell account on that server. This way, we take out the "alice logged on the server, used mozilla/chrome and all went to hell" scenario. Good sysadmins will run only the minimum possible set of packages necessary to the day-by-day administration on an expensive and shared server exactly because of that.
In your example: suppose Alice and Bob the DBAs for MassaCorp and they have shell accounts in the database server. Jack is the database server sysadmin and Hugo is the network manager.
One MUST ask:
1. do they NEED to have shell accounts?
2. doesn't the DBMS has some way of they doing their jobs without shell accounts?
3. why would anyone but Jack -- and maybe Hugo, on demand -- have to have a human shell account on the database server?
My point is exactly that you don't need a shell account to install a rootkit, but if you have a shell account, installing a rootkit (not necessarily on purpose -- sometimes all it takes is trying to listen to a music CD, remember?) is trivial. And once you scaled the privilege, all protection went away anyway. That happens in any OS.
Security quotes of the week Posted Jun 2, 2012 11:14 UTC (Sat) by hummassa (subscriber, #307) [Link]
> That's only really true for shell users who are both knowledgeable and determined to break security.
1. For users that are not determined to break security, a simple post-it "please do not access the files under /home/me/pr0n" suffices (this is an exaggeration, if it's not totally clear...).
2. As I mentioned in my other comments below, mistakes made by unknowledgeable shell users can eventually lead to total box compromise.
|
|||||||||||||