Slashdot Mirror
Portal 2 Incompatible With SELinux
jones_supa writes "Valve has recently released Portal 2 on Steam for Linux and opened a GitHub entry to gather all the bugs from the community. When one of the Valve developers closed a bug related to Portal 2 recommending that the users disable a security feature, the Linux community reacted. A crash is caused by the game's interaction with SELinux, the Linux kernel subsystem that deals with access control security policies. Portal 2 uses the third-party Miles Sound System MP3 decoder which, in turn, uses execheap, a feature that is normally disabled by SELinux. Like its name suggests, execheap allows a program to map a part of the memory so that it is both writable and executable. This could be a problem if someone chose to use that particular memory section for buffer overflow attacks; that would eventually permit the hacker to gain access to the system by running code. In the end, Valve developer David W. took responsibility of the problem: 'I apologize for the mis-communication: Some underlying infrastructure our games rely on is incompatible with SELinux. We are hoping to correct this. Of course closing this bug isn't appropriate and I am re-opening it.' This is more of an upstream problem for Valve. It's not something that they can fix directly, and most likely they will have to talk with the Miles developers and try to repair the problem from that direction."
Why does a decoder need execheap? Is there some sort of optimization that causes the processing and data to be not separated? It sounds like an invitation for all kind of exploits (which is presumably why it is banned by execheap).
Also, is there a reason to use a specific MP3 decoder? Is it because of licensing, or are there technical reasons?
I think that most Windows gamers run anti-virus. Do you also have good advises for them ?
Last time I checked, it's a very bad practice to allow executable code to be writable. Sort of like freely using eval, goto or passing in unvalidated inputs for sql queries.
I think it's a culture clash of developers who've only worked in a Windows environment and consequently are used to turning off operating system security so they can run a program, usually a game, vs. the Linux community who inherited the Unix culture where you can play games on the operating system, but you can't play games with the operating system.
Oh my god!?!? So what about the thousand enterprise software and services (from IBM to Oracle) which specifically say to absolutely disabile SELinux?!?
Let's be honest, SELinux is one of the most useless piece of software ever created by men...
you just need to allow the portal2 binary to use execheap. Now obviously its not good that portal2 uses execheap, but SELinux is fine grained enough to allow for it.
That is what it boils down to. Do i trust a game company on a secured system? No.
---- Booth was a patriot ----
Oh, wow; why on earth is this marked as informative, it's an anti-informative comment.
Any decent anti-virus program is not just going to be checking known signatures, but they will also be checking for malicious activities, execution and memory use patterns that virus makers use that shouldn't be in valid programs.
This is why sometimes you'll get poorly written software that triggers false alarms, they do things they shouldn't and get caught for it.
Additionally statistically very few people will happen across 0-day viruses, it's mostly existing ones that they will come across.
While not false, the cost associated with NOT relying on third party tools also means that smaller studios could not possibly develop anything halfway competitive. Larger studios in turn would have to dedicate far more resources to developing the underlying basic engines rather than content.
Yes, reliance on third party tools, APIs, engines and libraries makes you dependent on them. But it also frees a lot of resources that you can invest in the game rather than developing its foundation.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The same people complaining about Valve instructing people do disable SELinux are the very first people to recommend doing exactly the same thing when someone online asks "How do I do [basic thing] in Linux? It doesn't seem to be working." There isn't a single message board dedicated to Linux that isn't filled with "disable SELinux" posts.
-1 disagree is not a modifier for a reason. -1 troll, flaimbait, redundant, overrated are NOT acceptable substitutes.
They do.
0% detection rate by all major AVs is pretty much a must-have if you want to sell a dropper.
How can it spray itself over the writable area and mark itself executable if it isn't already running?
You would need the existing (trusted) code of the application to spray the malicious code into a writable buffer and mark it executable before this problem could occur.
Wow, really? Sorry random person on the Internet, but you are *completely* wrong. Did you even read the link on return-oriented programming (ROP)?
Here's how ROP works.
First, I (the attacker) get memory corruption on your program. Let's say a big, meaty buffer overflow on stack (yes, I still see these vulns all the time. In 2014. It makes me sad too).
Second, I spray a bunch of fake stack frames, overwriting all the real return addresses and frame pointers. I also dump some shellcode.
Third, the function I'm in returns. Instead of returning to the shellcode directly, though (can't, because it's not executable), it returns to an instruction somewhere that does a tiny piece of work (like loading the address of the page with the shellcode into a register) and then returns. This is called a "gadget".
Fourth, that first gadget "returns" into another gadget, and so on, each one setting up a function call that will convert the page containing shellcode from RW to RX.
Fifth, after the call is set up, the last gadget (second-to-last sprayed stack frame) "returns" to the entry point of the memory protection call (mprotect on Linux, VirtualProtect on Windows).
Sixth, the final sprayed stack frame - the one the mem protection function is using - returns to my newly-executable shellcode. You are pwned.
So yeah, it turns out that bypassing W^X is really not that hard. This is not a new technique, either; it's been around since basically right after DEP (rather, the NX bit that enforces no-execute at the CPU/memory manager level on any modern OS) was invented. There are actual compilers for ROP, where C goes in one end (along with the program you're exploiting) and the ROP chain comes out the other. You don't need very much code to be able to make ROP Turing-complete. This is partially due to the way that x86/x64, with their variable-length instructions, allow mis-aligned operations. You may think there's code in your program that loads the stack pointer into EAX and then immediately RETs, but if you read every single byte of the program (and all its loaded libraries) as a potential instruction start, you will probably find one!
To defeat ROP, you use ASLR (Address Space Layout Randomization), which in theory prevents successful ROP by randomizing the addresses of all the gadgets (specifically, loading all the executable code at addresses which have been XORed with a random mask). In practice, just like the way somebody will do something stupid that throws away the protection of DEP (like execheap does here...), somebody will write code that relies on being loaded at a fixed address, making an ASLR bypass possible. There are other ways too, like combining the overflow bug with an information leakage bug that tells the attacker what the ASLR mask is (i.e. if they can leak the address Y of something that is "supposed to" be at address X, they can get the ASLR mask M = Y^X) and then XOR their ROP addresses before exploitation.
Nonetheless, ROP is harder than just smashing the stack (or heap) data structures and pivoting into your shellcode. Marking some memory as RWX is just asking for trouble, and should never be done.
There's no place I could be, since I've found Serenity...
It's more ready than MS Windows with the stupid popup windows, minimising the game window during play without warning, restarts etc. Let's see some work on that for Win 8.*