Dear list,
I have been given two example programs that I have been requested to
provide exploits for.
I would kindly ask you to suggest me the simplest way to cause as much
cpu-hogging in the first one, and zombification in the second, as
possible.
For causing this, you may use
* As server for it to connect to, any simple unix tool or C script of
your choice, and
* You may alter any Linux kernel settings you want, to alterate the
fwrite() and fread() behavior that OpenSSL gets.
My suggestions for how exploit below, but without exploit scripts.
Also, if you think these are *not explotaible*, please tell!!
Also just for reference, how badly broken do you consider programs that
do select() in the wrong direction like this to be - do you consider
them disqualified from any production use?
Thanks!!
(1)
The first program invokes SSL_write only. Its error is that it responds
to SSL_ERROR_READ by making a select() for writability, which is of
course basically always there, meaning that when that is the case it
will.
How would you cause this program to hog as much CPU as possible?
void make_me_hog_cpu_main() {
[Connects to an SSL server of your choice, sets the SSL in
nonblocking mode, and does all way up to SSL_connect.]
char buf[1];
// Needed?: SSL_write(ssl,buf,1);
do {
int r = SSL_write(ssl,buf,0);
int e = SSL_get_error(ssl,r);
if ((e == SSL_ERROR_WANT_READ) || (e == SSL_ERROR_WANT_WRITE)) {
select( with the SSL socket in writefds );
}
} while (not EOF yet);
}
I think the way I would do it, would be to make it connect to a dummy
TCP server that reads all data and throws it away, but never responds
with any data.
(2)
The second program invokes SSL_read only. Its error is that it responds
to SSL_ERROR_WRITE by making a select() for readability.
It should be easy to make the select() call never return.
How would you cause this program to zombify?
void make_me_zombify_main() {
[Connects to an SSL server of your choice, sets the SSL in
nonblocking mode, and does all way up to SSL_connect.]
do {
int r = SSL_read(ssl,buf,1);
int e = SSL_get_error(ssl,r);
if ((e == SSL_ERROR_WANT_READ) || (e == SSL_ERROR_WANT_WRITE)) {
select( with the SSL socket in readfds );
}
} while (not EOF yet);
}
I see this one as a bit trickier - what I see is that OpenSSL starts
with writing 320 bytes on the socket (see strace output below), when
starting negotiation.
If I somehow would decrease Linux' NIC's MTU, decrease OS write buffers,
and similar things, to less than 320 bytes so say to 1 byte, then the
SSL_read SSL negotiation's first fwrite() would not write all 320 bytes
and thus it would return SSL_ERROR_WRITE and the server would never
answer anything, at least not before disconnecting, so the select()
would cause the connection to zombify until it closes.
Thanks!
strace openssl s_connect -host wikipedia.org -port 443 shows:
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [0], 4) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("208.80.154.224")}, 16) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f9c3e8be000
write(1, "CONNECTED(00000003)\n", 20CONNECTED(00000003)
) = 20
select(4, [3], [3], NULL, NULL) = 1 (out [3])
time(NULL) = 1424859317
time(NULL) = 1424859317
write(3,
"\26\3\1\1;\1\0\0017\3\3T\355\240\265\341\232v\352N\6\357Q\1\0}\2248\362\332\240\201"...,
320) = 320
read(3, "\26\3\3\0B\2\0", 7) = 7
time(NULL) = 1424859317
time(NULL) = 1424859317
read(3,
"\0>\3\3T\355\240\265+\246\24\\(\337\214\336\241\356)\33\357\342\217\253\254X\257\267\335\35\233\36"...,
64) = 64
read(3, "\26\3\3\fT", 5) = 5
read(3,
"\v\0\fP\0\fM\0\7\3320\202\7\3260\202\6\276\240\3\2\1\2\2\22\21!\227.2\245\345"...,
3156) = 1384
read(3, "g\202\rwikipedia.org0\t\6\3U\35\23\4\0020\0000\35\6\3U"...,
1772) = 1772
