Hacker News Reader

Comment by tptacek | Hacker News Reader

The C code in the "framework" this thing uses is pretty scary; grep for MAX_BUFFER_SIZE, malloc, strcpy, &c. The header parsing in particular.

View on HN

Agreed.

    q3k@nihilism ~/Projects/longs $ python2 -c "print 'GET / HTTP/1.1.\r\n' + 'a'*2000 + '\r\n\r\n'" | nc 127.0.0.1 1337

    q3k@nihilism ~/Projects/longs $ PORT=1337 ./longs
    *** Error in `./longs': free(): invalid next size (normal): 0x000000000155a5f0 ***
    ...

Sounds like a fun heap exploitation challenge. Almost CTF-like.

EDIT: It also throws a whole bunch of warning when compiling. [moved this here from the first line after child post mention]

Thank you for raising this issue. We're currently working on fixing this. Here's the issue on the [tracker](https://github.com/riolet/longs/issues/6).

That's not a warning. That's a runtime error.

I know, this is some internal glibc allocation code failing because that request overflowed a buffer on the heap. The bug is, as tptacek mentioned, in the header receiving function [1].

The compilation warnings was an additional remark, I should've phrased that post better.

[1] - https://github.com/riolet/longs/blob/master/wafer.c#L334-337

Not the only case of this, either.

cool, a capture the aws instance contest! (/s)

May I ask what's wrong with malloc?

I don't have much experience with C outside of embedded systems, so my security practices in C are probably less than ideal for PC/server based code.

Nothing is wrong with malloc per se, but the way it's used here is extraordinarily unsafe (they're allocating fixed-sized buffers for variable-length fields). Even if they'd attempted to allocate variable-length buffers, they'd still need to handle integers safely, and this code doesn't.

Reply on news.ycombinator.com