Cuberite Forum

Full Version: Evil code
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Today a colleague found the most evil code I've seen so far:
extern "C" const long long main = -4323769003089592391;

This works out-of-the-box on Linux/gcc, in MSVC you need to disable data execution protection by adding these lines:
#pragma comment(linker, "/SECTION:.idata,RWE")
#pragma comment(linker, "/SECTION:.rdata,RWE")

Original source: https://www.reddit.com/r/shittyprogrammi..._c/czszrdf
Tell me, Linux enthisiasts, how does this reflect the "Linux is safer" mantra that I hear oh so often? How could Linux be so safe if the default configuration allows programs to execute data, and thus is very prone to buffer over-/underflow attack vectors?

On Windows, the original code doesn't work simply because the "code" for main is stored within the data segment, which is non-executable by default, thus making it safe. Why doesn't this happen on Linux, too?
Very nice hack!

(02-10-2016, 12:21 AM)xoft Wrote: [ -> ]Tell me, Linux enthisiasts, how does this reflect the "Linux is safer" mantra that I hear oh so often?

In linux, I can easily create an isolated user, with no fancy virtualization needed. That user will not be able to access my personal files, thus isolating the millions of potential Cuberite exploits from my personal dataTongue
=> LINUX is saFEr.

Lesson learned: Don't judge the overall safety of a system based on a single case Wink
Btw, there are many exploits on Windows in order to get root access which won't get fixed because "it's would require too many changes".

Edit: they are called privilege escalation

And with a bit of spearfishing you could easily 1. Grab admin access, 2. Simulate a problem to get the real admin to login there, 3. "pass the hash" to use single sign on to take over the domain admin
Why is an infinite loop so evil?
EDIT: i think i got it, ¿execute any code / root access?
How is it possible that operating systems incite so much emotion. Its not like anybody even knows exactly how safe a piece of software is, and so people just end up asserting unfounded statements.
Any OS system has scope of usage. Such MS Windows - fast install and start project with support and free staff. Unix-like - much more time to setup and less staff to support.
Security paradigm for Windows system is "What is not forbidden - is allowed". It is not good choose for enterprise projects.
Security paradigma of Unix-like is "What is not allowed - is forbidden".
But more and more Linux systems begin to use paradigma of MS.
I'm using MS and Linux OS. When I can use FreeBSD - I'm do it. Whe I can use Linux-like - I'm use Red Hat. In other case - I'm use Windows.
No point in arguing what OS is better. And it's the first sign of not knowing the area of OS applications.
Any OS has exploits and "bugs" it is software created by people.
I'm just wondering why Linux doesn't default to the more secure "don't execute data unless explicitly allowed". This somewhat negates what you've said - Windows doesn't execute data unless explicitly allowed, while Linux is happy to execute data by default. And I hope we can agree that executing data is a bad idea™ most of the time.
There is no real "default" in the Linux world. There are some hardened kernels which wouldn't allow this insecure code such as the grsecurity kernel. With this kernel and without a nicely maintained whitelist you are even unable to start Firefox Smile
I don't think this is about the kernel, it's about the compiler not outputting correct segment flags for the data segment.
Pages: 1 2