Cuberite Forum
Evil code - Printable Version

+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Off Topic (https://forum.cuberite.org/forum-9.html)
+--- Forum: Off Topic Discussion (https://forum.cuberite.org/forum-10.html)
+--- Thread: Evil code (/thread-2367.html)

Pages: 1 2


Evil code - xoft - 02-10-2016

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/shittyprogramming/comments/44u8c6/just_figured_out_how_to_make_an_infinite_loop_in_c/czszrdf


RE: Evil code - xoft - 02-10-2016

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?


RE: Evil code - LogicParrot - 02-10-2016

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


RE: Evil code - Schwertspize - 02-10-2016

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


RE: Evil code - tonibm19 - 02-11-2016

Why is an infinite loop so evil?
EDIT: i think i got it, ¿execute any code / root access?


RE: Evil code - tigerw - 02-11-2016

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.


RE: Evil code - DrMasik - 02-11-2016

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.


RE: Evil code - xoft - 02-11-2016

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.


RE: Evil code - sphinxc0re - 02-11-2016

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


RE: Evil code - xoft - 02-11-2016

I don't think this is about the kernel, it's about the compiler not outputting correct segment flags for the data segment.