zerothehero

- friends
56 link karma
1,495 comment karma
send messageredditor for
what's this?

TROPHY CASE


  • Three-Year Club

r17 now open source by matthewnoursein programming

[–]zerothehero 0 points1 point ago

Thanks for doing this.

Am I missing something or is the entire source in headers files? https://github.com/matthewnourse/r17/tree/master/nplus1/include/np1

I don't see a "src" dir.

Does this actually make it faster? Maybe you could do like "sqlite" does and release an "amalgamation" as a single C++ file. I think this would accomplish the same thing. Although I guess this is a command line tool and not a library.

Hadoop on 5 machines vs r17 on 1 machine by matthewnoursein programming

[–]zerothehero 3 points4 points ago

This project is really cool! Hadn't heard of r17. Surprised at the negative reactions here.

Hadoop is a huge headache and you can get a lot done with 1 machine these days. 16, 32, and 100 core machines are inevitable in a very short time frame.

EDIT: Oh, not open source. What are your plans for r17? If it were open source I'd contribute.

Also: does it make use of multiple cores?

Hiring - they are doing it right. by Zephironin programming

[–]zerothehero -1 points0 points ago

RIPOFF of Google job ad 8 years ago!

http://haacked.com/archive/2004/07/12/google-mysterious-billboard.aspx

I solved this 8 fucking years ago

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 0 points1 point ago

Wow very cool! Cool solution to level 6. Who'd have known that using redirection to a file and rlimit works together...

Using a hint from this thread (or maybe the other reddit one), I wrote a parent process which kept the write end of a stderr pipe open. Then it would fill the pipe up with pipesize=65536 - N bytes, where N is the number of characters to check. Then it would start the child. The fprintf(stderr, ".") would then be blocked and not print "Haha" if the first N chars are correct.

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 0 points1 point ago

GOT IT!

level06@ctf6:/tmp/tmp.0KPZsmsYXn$ /levels/level06 /home/the-flag/.password the*********
Welcome to the password checker!
........................
Wait, how did you know that the password was the************?

The password begins with "the", but that won't help you any... if anyone wants hints feel free to ask.

For the last 3, I took LONG blind alleys with lots of brute force. Then after understanding the problem better, I found a shorter and elegant solution. I think you have to go through the dumb way to come up with the good way.

Stripe CTF by sanitybitin netsec

[–]zerothehero 0 points1 point ago

OK I copied it from you and ran it. :) So the trick is...

  1. you know you control buf and can put shell code there.
  2. You know you can overwrite the return address of the function that contains buf (fun)
  3. In fun you found that there is a register with the address of buf.
  4. Now you search the whole program for "call" on that register? Why is that even there? What is __do_global_ctors?
  5. You cause the program to jump to that instruction while the register contains the address of buf.

Is that right? I'd be interested in learning how people get here. It makes sense though because you are effectively working around the randomization.

FWIW I made my exploit REALLY repeatable and really automated. Still no luck on the remote machine. Pretty positive I'm not making any dumb mistakes in repeating it, as everything is automated with shell scripts. I'm going to e-mail them about the possible reasons.

One reason I mentioned was 32-bit native vs 32 bit executable on a 64-bit machine. I found another 64-bit machine to run on to test this -- however it seems to do MUCH more stack randomization than 8MB. Odd... maybe a special kernel patch? It's a dreamhost server.

Wasn't able to get it on that machine either...

Although it seems like other people brute forced the randomization successfully using very similar techniques.

Stripe CTF by sanitybitin netsec

[–]zerothehero 0 points1 point ago

Oh interesting. I think you and I might have been bumping up against the same thing. What kind of payload did you make?

Yeah I feel like there is something similar to the executable stack protection that is just at runtime on their kernel.

It is weird to me that the exact same binary with the exact same inputs exploits on my machine but not theirs. I guess the big difference is that theirs is a 64-bit machine in 32 bit mode. Mine is a 32 bit machine.

I feel like I could just try a different technique like injecting environment variables and it will probably work... but I won't know why this one doesn't work...

Stripe CTF by sanitybitin netsec

[–]zerothehero 0 points1 point ago

Hey, I ALMOST got it. See my posts here:

http://www.reddit.com/r/programming/comments/q1qii/want_to_try_your_hand_at_writing_exploits_try/

I got it working on my local machine every time by turning off stack randomization.

Then I turn on stack randomization and got it working 2-3 times out of 84 tries.

The reason is that the stack randomization spreads it over 8MB. One trick I used is to make a NOP slide that is the maximum length of an argument (131071 bytes) rather than ~1000 bytes. So then it's 100 times easier to hit. Buffer looks like:

1036 bytes + 4 byte address + ~129,000 NOPs and then the shell code.

So this works on my machine very reliably. I copied their binary onto my machine and it works too.

But when I execute it on THEIR machine, I only get seg faults. Tearing my hair out a bit.

There are other approaches suggested in the thread... namely that you can also inject data into the process through environment variables and try to find those. I might try that but haven't yet.

I think breaking it down into steps is important. For me anyway, it was important to get it hitting EVERY time on the local machine with stack randomization off. I also tested my shell code on their machine outside of their binary by compiling a small C program.

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 0 points1 point ago

Hm, maybe I will try that... I am not good with gdb yet. All I know how to do is set a breakpoint at an address and print a register... which is what I used to find the range of randomization.

Status:

On their machine I am able to do:

level04@ctf5:/tmp/tmp.mlu4ppyKrt$ gcc -Wl,-zexecstack -m32 -fno-stack-protector -o shellex_c  shellex_c.c && ./shellex_c
$ 

My shell code works on their machine. I figured out how to make an executable stack without the "execstack" binary -- through ld options.

My randomization works with their binary on my machine.

It still doesn't work with their binary on their machine. ARGH.

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 1 point2 points ago

Oops, good idea. (I did base64 but I didn't know how to copy more than one screenful with tmux; however a plain terminal works fine).

Damnit, I can exploit their binary on my machine! I have 84 iterations and its hits every single time, 2 or 3 times.

Running the exact same thing on their machine still isn't working!! I must be making some stupid mistake somewhere but I double checked everything...

I md5sum'd my shell code.

I run gdb to get the range of $esp addresses -- 8 MB. Then I do search in 100kb increments over that range. Changing the jump address.

AHHH....

The only niggle is that I was testing my shell code with a small C program that just copies it directly and runs it on the stack. On my machine, I still have to run "execstack -s" to get this to run and not segfault. On their machine I can't do this same test of the shell code because there's no "execstack".

I guess the issue is that there are many possible reasons for the "Segmentation fault" error and I can't really distinguish them... I don't know if I'm not hitting the right addresses or if my shell code is somehow broken on their machine. But I can't distinguish the cases.

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 0 points1 point ago*

Ah the 64-bit machine would explain the different addresses... I was using gdb to account for the difference and using roughly the right addresses on the local and remote machine though...

I think putting a lot of shell codes is just similar to my huge 130k NOP area with a shell code at the end?

I think I may try your environment variable solution... but I currently don't know how to find them. EDIT: I see that the max env variable size is also 130k, but you can put more of them there. Nice technique.

One issue is that I am running "execstack -s" to allow an executable stack on my local machine. If I don't do that, my exploit segfaults instead of getting the shell.

However on the hacker news thread someone said that the stack WAS executable. If not, that would be an obvious problem, and it would be consistent with all the segfaults I'm seeing on the remote machine.

Anyone know how to check if a binary on their machine has an executable stack?

Probably need to sleep on it again... that always works.

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 0 points1 point ago*

Hmmm... I could use some help too. I got it working on my local machine, compiling what is basically an identical level04 binary.

The maximum argument size is 131071. So to brute force the randomization better, I figured I can use more than 129,000 NOPs after the frame pointer, rather than 1,000 or so before the frame pointer.

So I do 1036 bytes of NOPs, then 4 bytes for the pointer, and then 129,000 NOPs, then shell code. I am hazy about this part but I just put a breakpoint in "fun" using gdb, and print out "$esp". The stack pointer.

And then I just search in 10kb(?) steps from that $esp value. On my local machine it reliably hits maybe 1 out of 50 times. I have shell exploit.

On the remote machine I can't get it to hit at all... maybe I just need to try the same address a lot instead of moving it around? Argh.

Maybe my 1036 value is wrong on the remote machine? I got that by a little trial an error, not really stepping through it with gdb. I'm not good with x86 assembly.

I wish I could copy the remote binary and compare with my compiled binary. They seem to have neutered scp though ("STDIN is not a terminal). Anyone get the level04 binary off the machine? Or is anyone able to get files easily to the remote machine?

EDIT: Question: why do the stack addresses begin with 0xffff on the remote machine, but 0xbfff on my machine?

EDIT: On my own machine, I can turn address randomization off, and hit the exploit every time, so I think my arithmetic is at least right. I can vary the jump address from 4 to 120,000+, and the exploit still hits, so the NOP slide is working... that's a big target to hit.

From my experiments, relocation seems to move the stack within a range of 8MB or so. That is 80 100kb windows....

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 4 points5 points ago

Woohooo! Got it!!! Thanks for the tips.

For others: Do it on your local machine... it's way easier because the server is slow. When you get to the server, "nm" is helpful.

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 6 points7 points ago

I went to bed, and of course thought of the solution within 5 minutes and got up to check it and type this. :) &fns-argv[2] is apparently not constant due to randomization, but &fns-&buf is! (obviously, now) I will do all the fiddly stuff tomorrow.

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 1 point2 points ago*

Yes, I realized my mistake now. I need to create a negative index that jumps to a pointer to a function.

But now I think I am running into stack randomization issues, as my printf calculations of addresses are changing on every run. Maybe this is only on my machine, haven't tried it on their machine...

EDIT: Hm I compiled on their machine, calculating (void *)&fns - (void *)argv[2] and it is different on every run.... sleeping on it will probably help.

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 1 point2 points ago

Hm, not quite... see below. I am trying the negative indexes. Brute forced it without luck, then calculated what I think it should be... which doesn't fit in a 32-bit integer. The address space is 32 bits and I believe the code and the stack are on totally opposite sides, nearly 232 away from each other. But the most negative offset representable is -231.

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 1 point2 points ago*

I believe this is the answer. I compiled a pretty much identical copy on my local machine (32 bit, unstripped, etc.), and then used "nm" on it to see where "run" is. And then I used "pmap" to look at where the stack (fns) is relative to the executable code.

The niggle I am running into is that the offset I believe you need to pass to get from the stack to the code is more than -maxint -- it's a 32 bit executable and you have "int index" which is at most -2**31. So I can try calling arbitrary pieces of memory but I can't get THAT far. Hmmmm...

EDIT: You don't really need to use "nm" and "pmap" if you copy it to your local machine. You can just use printf("%p %p", run, fns) and recompile.

Stripe CTF by sanitybitin netsec

[–]zerothehero 0 points1 point ago*

EDIT: figured it out, I was barking up the wrong tree.

Yeah it looks like you are supposed cause a buffer overflow to overwrite the argument to the run() function so that you can cat the password in the system() call.

But I don't see how you can overwrite anything... the strncpy() call looks fine to me... NUL-terminated and so forth. my C is rusty though.

BTW "nm /levels/level03" might help?

Want to try your hand at writing exploits? Try Stripe's "Capture the Flag" challenge: ssh into their server as user level01, and your first challenge is to read level02's password. by obvioustrollin programming

[–]zerothehero 6 points7 points ago

Hm, could use a hint on level 3. Is the vulnerability around the strncpy() function? It seems like the answer would be a buffer overflow. But it looks like it is called correctly and the buffer is NUL-terminated correctly.

Inventing on Principle - Bret Victor shows what programming tools could be like and talks about living for a cause by gapopin programming

[–]zerothehero 4 points5 points ago

Geez, this guy is unequivocally a genius.

He deserves a MacArthur award (something Richard Stallman also won).

Anyone know a nominator?

http://www.macfound.org/site/c.lkLXJ8MQKrH/b.959481/k.2EF5/Fellows_FAQ.htm#The_Nomination_Process

RANT: Where do I get a small home server to run Linux these days? by zerotheheroin hardware

[–]zerothehero[S] 0 points1 point ago

OK thanks. That one looks decent if a little obscure.

RANT: Where do I get a small home server to run Linux these days? by zerotheheroin hardware

[–]zerothehero[S] -2 points-1 points ago*

You didn't actually read anything I wrote. If there are so many, then point to some I can buy right now. Go ahead, do it. Shouldn't be more than a Google search away, right?

There are 2 in this thread -- the ASRock that I pointed to, and the Giada. Neither have any reviews on Amazon, but I happen to know the ASRock is probably good so I bought it.

Two PCs, from a couple of tiny manufacturers, out of an entire market of PCs is plenty? Requirements are roughly "core i3-ish, $600-ish, small and quiet, boots Linux out of the box, can buy it online easily." i.e. Mac-Mini like, but runs Linux.

I like all the downvotes without any argument -- you guys know I'm right. PCs suck now.

RANT: Where do I get a small home server to run Linux these days? by zerotheheroin hardware

[–]zerothehero[S] -4 points-3 points ago

It's actually harder than it sounds. The main reason is that there are a lot of notebook components that may or may not be available for off-the-shelf builders. And it will cost a LOT more than $600 that way, especially if I have to pay for someone's time too.

view more: next