It's called Shellcode. These kids these days with their exclusive Ruby on Rails knowledge. "Shell what? Oh you mean that new band that you probably never heard of?"
I don't see ruby mentioned anywhere and the article mentions shellcode. I thought it was informative and interesting and I am well aware of shellcode. Your comment is unnecessarily condescending and may discourage posts like this.
That may be goldenkey's goal, and shouldn't be discouraged either. Someone's opinion that something is awful and doesn't belong here is just as legitimate as your opinion that something is informative and interesting.
Your comment is unnecessarily condescending and may discourage comments like this.
I disagree. Most opinions that state "I already knew this, and you should too" are banal and do not lead to interesting discussion. And the moderation system of this site is set up to promote interesting discussion.
True but my comment was more directed at the disenfranchising nature of 'using printf.' Printf has nothing to do with shellcode, and is just a silent mockdrop of BS to entice those who would probably click onto the next article of a real explanation of shellcode were had. I prefer frankness to BS even if the frank explanation intimidates most.
The Buffer Overflow #1 and #2 projects might also be worth checking out. You can download the project description, starter code, and VM image, and see if you can write code to get the root shell.
if you're going to insert a shell code into printf, then well... you can implement anything in printf... or in memcpy.. or in strcat.. or whatever really.
Heck, why not just title it "a web server with no library function calls" and call an array of bytes as a function? Then everybody would be able to see what it really is, which is an unremarkable shellcode embedded directly in a C program. I feel like the "printf" was only included so that people would have something to recognize in the title.
By that logic you could just execve httpd with shellcode. Or ruby. Or a ruby program that generates a perl script that compiles a Prolog program to shellcode that looks like it prints hello world, but actually does execve httpd.
I got segmentation fault trying out his hello world example (after changing VMA address). Then again, isn't that the supposed behavior? Not every memory page can be written to, if I remember correctly.
Yes, segfault for me too after i changed ADDR preprocessor directive to the VMA address from objdump, as the instruction says. I'm on Ubuntu Linux 13.10 x64.
Ubuntu adds a security feature that provides a read-only relocation table area in the final ELF. To be able to run the examples in ubuntu, add this in the command line when compiling
ok, now it compiles, thanks for that. However, I'm getting an incomplete response "<h1>hello world</h1" without the trailing closing angled bracket. And when I try to run final.c after setting the FUNCTION_ADDR and ADDR as per your tutorial, I get some stray HTTP/1.0 200 and Content-type text/html being displayed on stdout as I start the program final.c (compiled to a.out by default)
Ah, you have found a bug in my code (I made an error in computing the string length, and didn't notice it because it displayed fine on Chrome). I have fixed my code in git and the blog post.
As for the stray output displayed on the stdout: it is to be expected. The %n format outputs the numbers of character that is written by printf, so it must have written something to the stdout.
Ah! that explains so much (and also why i've wasted a whole hour figuring out why what I observed was happening) I'm a CLI curl guy, rather than relying on these browsers which randomly would add a 0x0d 0x0a to my form submissions, for example. I also noticed that compiling (assembling-linking) the .S to execute it would not print anything (just hang there like a normal webserver), but I was getting stuff written to stdout with the final.c/webserver.c version using its shellcode.
Really nice, it's so weird that format strings support %n, it's such a massive security vulnerability that I don't really know what was going on in the mind of the guy that decided to implement this.
It's only a vulnerability if the user can control the format string. Otherwise it's a useful way of getting the lengths of things; but ironically it's not paying attention to lengths that also causes buffer overflow vulnerabilities...
C was designed way before security was a concern. If somebody exploited your program, you could just slap them because they'd be sitting at a terminal in the same room with you - no need for fancy ASLR or controlling how many characters you write to a buffer when physical violence was a viable option :)
This isn't even remotely true. Computer security was a concern and an area of study long before C/Unix showed up. Unix (and by extension C) descended directly from the Multics project, which from its start in 1964 made security a central priority. Kernighan and Ritche were important members of the Multics project. Further, the idea that everyone who used the computers of that era were "in the same room" is also patently absurd.
I like my fantasy about how things were back then better, thankyouverymuch. At least this way I can believe they didn't unleash the flood of pwnage on the world while knowing better.
