Dear Dave Ahmad,

Nearly same bugs exist in reference socks5 implementation by NEC. There
are few different overflows, all look not exploitable in socks5v1.0r11,
at least on majority of platforms due to specific data layout, but may
be exploitable in earlier versions or in derived software. Examples:

1. in SOCKS5 User-Name parsing:

proxy.c:

static int GetString(S5IOHandle fd, char *buf, double *timerm) {
    u_char len;

    buf[0] = '\0';
    if (S5IORecv(fd, NULL, (char *)&len, 1, 0, UPWD_IOFLAGS, timerm) != 1) return -1;
    if (len == 0) return 0;

    if (S5IORecv(fd, NULL, buf, len, 0, UPWD_IOFLAGS, timerm) != len) return -1;
    buf[len] = '\0';
    return len;
}

problem is that target username buffer is 128 bytes.

2. In SOCKS4 username parsing:

proxy.c:

static int HandleS4Connection(S5LinkInfo *pri, S5IOInfo *iio, list *auths, double *timerm) {
...
   char buf[256+256+8],
...

    for (tmp = buf, *tmp = '\0'; tmp < buf+sizeof(buf)-1; *++tmp = '\0') {
        if (S5IORecv(iio->fd, iio, tmp, 1, 0, PROXY_IOFLAGS, timerm) != 1) {
            S5LogUpdate(S5LogDefaultHandle, S5_LOG_DEBUG(0), 0, "Socks4: Read failed: %m");
            return EXIT_ERR;
        }

        if (*tmp == '\0') break;
    }

    S5LogUpdate(S5LogDefaultHandle, S5_LOG_DEBUG(10), 0, "Socks4: Read user: %s", buf);

    strcpy(pri->srcUser, buf);

pri->srcUser is 128 bytes...

3. in reading hostname

struct sockaddr_name {
    unsigned short sn_family;
    unsigned short sn_port;
    char sn_name[255];
};

protocol.c:
            memcpy(result->sn.sn_name, buf+RP_HOSTOFF+1, (u_char)buf[RP_HOSTOFF]);
            memcpy(&result->sn.sn_port, buf+RP_HOSTOFF+1+buf[RP_HOSTOFF], sizeof(u_short));
            result->sn.sn_name[(int)(u_char)buf[RP_HOSTOFF]] = '\0';

(off-by-one vuln).

I've got no response from authors.

-- 
~/ZARAZA
Îñîáóþ ïðîáëåìó ñîñòàâëÿåò àëêîãîëèçì.  (Ëåì)

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]