Security quotes of the week
Posted Jun 1, 2012 7:57 UTC (Fri)
by malor (guest, #2973)
[Link] (47 responses)
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.
Posted Jun 1, 2012 12:25 UTC (Fri)
by hummassa (subscriber, #307)
[Link] (43 responses)
Posted Jun 1, 2012 13:54 UTC (Fri)
by malor (guest, #2973)
[Link] (5 responses)
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.
Posted Jun 1, 2012 15:24 UTC (Fri)
by etienne (guest, #25256)
[Link]
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;
Posted Jun 1, 2012 16:50 UTC (Fri)
by AndreE (guest, #60148)
[Link]
Posted Jun 1, 2012 17:15 UTC (Fri)
by hummassa (subscriber, #307)
[Link]
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).
Posted Jun 1, 2012 21:10 UTC (Fri)
by dgm (subscriber, #49227)
[Link]
Posted Jun 4, 2012 10:59 UTC (Mon)
by jschrod (subscriber, #1646)
[Link]
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.
Posted Jun 2, 2012 2:05 UTC (Sat)
by vonbrand (subscriber, #4458)
[Link] (33 responses)
I'd like some kind of proof for this "fact"...
Posted Jun 2, 2012 10:08 UTC (Sat)
by hummassa (subscriber, #307)
[Link] (32 responses)
Posted Jun 4, 2012 2:24 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (31 responses)
And the fact that Windows 7 is vulnerable is relevant for Linux/Unix security because...
Posted Jun 4, 2012 14:46 UTC (Mon)
by hummassa (subscriber, #307)
[Link] (30 responses)
... 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?
Posted Jun 5, 2012 0:18 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (29 responses)
>> 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?
Posted Jun 5, 2012 1:53 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (28 responses)
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).
Posted Jun 5, 2012 2:04 UTC (Tue)
by dlang (guest, #313)
[Link] (27 responses)
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.
Posted Jun 5, 2012 2:16 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (26 responses)
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)
Posted Jun 5, 2012 2:27 UTC (Tue)
by dlang (guest, #313)
[Link] (25 responses)
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.
Posted Jun 5, 2012 17:18 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (24 responses)
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.
Posted Jun 5, 2012 17:32 UTC (Tue)
by dgm (subscriber, #49227)
[Link] (17 responses)
Isn't your theory in glaring contradiction with reality?
Posted Jun 5, 2012 17:58 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (16 responses)
BTW, WinPhone is the only non-jailbroken mobile OS so far.
Posted Jun 5, 2012 18:16 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (9 responses)
"Windows Phone 7 unlocker released to side-load applications"
(from Nov 2010)
LOL.
Posted Jun 5, 2012 18:23 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
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.
Posted Jun 5, 2012 18:32 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (7 responses)
> 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.
Posted Jun 5, 2012 19:00 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
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.
Posted Jun 5, 2012 19:22 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (5 responses)
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.
Posted Jun 5, 2012 19:49 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
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.
Posted Jun 5, 2012 19:53 UTC (Tue)
by hummassa (subscriber, #307)
[Link]
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.
Posted Jun 5, 2012 20:03 UTC (Tue)
by jimparis (guest, #38647)
[Link] (2 responses)
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
Posted Jun 5, 2012 22:22 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
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.
Posted Jun 5, 2012 22:47 UTC (Tue)
by jimparis (guest, #38647)
[Link]
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.
Posted Jun 5, 2012 18:29 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (5 responses)
"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.
Posted Jun 5, 2012 19:05 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
>"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.
Posted Jun 5, 2012 19:42 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (1 responses)
> 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.
Posted Jun 6, 2012 21:38 UTC (Wed)
by hummassa (subscriber, #307)
[Link]
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.
Posted Jun 5, 2012 19:55 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
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.
Posted Jun 5, 2012 20:04 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
>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.
Posted Jun 5, 2012 18:13 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (5 responses)
LOL.
Posted Jun 5, 2012 19:05 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Jun 5, 2012 19:25 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (3 responses)
Posted Jun 5, 2012 19:55 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
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.
Posted Jun 5, 2012 20:30 UTC (Tue)
by hummassa (subscriber, #307)
[Link] (1 responses)
Posted Jun 5, 2012 22:32 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Posted Jun 2, 2012 9:18 UTC (Sat)
by AndreE (guest, #60148)
[Link] (2 responses)
Posted Jun 2, 2012 10:23 UTC (Sat)
by hummassa (subscriber, #307)
[Link] (1 responses)
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>.
Posted Jun 4, 2012 12:29 UTC (Mon)
by nix (subscriber, #2304)
[Link]
(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).
Posted Jun 1, 2012 13:07 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
Your definition is thus clearly flawed.
Posted Jun 1, 2012 13:35 UTC (Fri)
by PaXTeam (guest, #24616)
[Link] (1 responses)
is that established fact? i thought a detailed account of what and how got compromised exactly had not yet been published.
Posted Jun 1, 2012 17:48 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Jun 1, 2012 14:25 UTC (Fri)
by copsewood (subscriber, #199)
[Link] (4 responses)
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.
Posted Jun 1, 2012 17:17 UTC (Fri)
by hummassa (subscriber, #307)
[Link] (2 responses)
All it takes, then is ONE malicious webpage that grabs a shell... escale the privileges... and has full control.
Posted Jun 2, 2012 9:56 UTC (Sat)
by copsewood (subscriber, #199)
[Link] (1 responses)
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
Posted Jun 2, 2012 10:47 UTC (Sat)
by hummassa (subscriber, #307)
[Link]
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.
Posted Jun 2, 2012 11:14 UTC (Sat)
by hummassa (subscriber, #307)
[Link]
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.
(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.) Security quotes of the week
Security quotes of the week
Only on Linux, and it is utter, absolute bullshit that it always needs to be that way.Security quotes of the week
Security quotes of the week
and when the attacker is paid $250K a shot ( http://www.schneier.com/blog/archives/2012/06/the_vulnera... )
I am not sure it can "absolutely be done" (not that Windows, Mac,... are so more protected).
I am waiting the day $250K is injected every few days into securing Linux, obviously Git comments will not be of real importance then.
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
> population. And if they trust Linux with their data, they may end up dead.
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Not really. There are systems that are targeted differently.
OpenBSD is mostly guarded by the Elusive Joe effect ("Why is he so elusive, does he ride fast or is he a sharpshooter? Nah, nobody cares about him").
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
http://www.winrumors.com/windows-phone-7-unlocker-release...
Security quotes of the week
Security quotes of the week
Security quotes of the week
Not on Windows Phones.
Security quotes of the week
Security quotes of the week
>A: The short answer is yes if you have a Lumia 710 - you must firstly downgrade your bootloader - and "maybe" for the Lumia 800, because only some of them can be Interop-Unlocked at the moment.
I know because I actually have an 'unlucky' Lumia 800 which can't be unlocked.
XBox 360 is also unhackable. It's unlikely to be hacked before its useful market life ends.
Security quotes of the week
Security quotes of the week
http://free60.org/King_Kong_Hack
Security quotes of the week
Security quotes of the week
Security quotes of the week
https://www.youtube.com/watch?v=1Txv6ldiNqo
http://sirad.pd.infn.it/people/lucas/OBSDdocs/Kris_Vangen...
http://www.tomsguide.com/us/Linux-PS3-playstation-OtherOS...
http://forum.xda-developers.com/showthread.php?t=985500
Security quotes of the week
Requires special officially sanctioned developer access. Duh.
I've specifically said that OpenBSD is as insecure as Linux and other OSes.
Hypervisor in PS3 was broken only because of el-stupido developers who misused the signing keys.
Are you simply showing me results of "WP7 jailbreak" from Google search without even bothering to actually read it?
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Easily checked by searching CVEs.
I'm talking about bugs in default/core configuration.
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week
Security quotes of the week