full-disclosure - gated 3.6 ripquery, was Re: we should block: hushmail.com, hush.com

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] [thread-next>] [day] [month] [year] [list]

From: silvio at big.net.au (silvio@....net.au)
Subject: gated 3.6 ripquery, was Re: we should block: hushmail.com, hush.com

i've not actually verified any of this, so comments are welcome i guess.

looking at gated 3.6 ripquery we see this code -->

static void
ripq_trace (const char * dir, struct sockaddr_in * who, void_t cp, register int size)
{
    register struct rip *rpmsg = (struct rip *) cp;
    register struct rip_netinfo *n;
    register const char *cmd = "Invalid";

    /* XXX - V2 extensions */

    if (rpmsg->rip_cmd && rpmsg->rip_cmd < RIPCMD_MAX) {
        cmd = trace_state(rip_cmd_bits, rpmsg->rip_cmd);
    }

now.. this is ok, if it is indeed true that the the rip msg is infact
of the correct minimum size so we dont do conceptual out of bounds
reads (ignoring the fact that the cp buffer comes from the bss).

looking at where this is called from .. -->

/*
 * Handle an incoming routing packet.
 */
static void
ripq_input (struct sockaddr_in * from, struct in_addr * to, int size)
{
    register struct rip *msg = (struct rip *) ((void_t) packet);
    struct rip_netinfo *n;
    struct hostent *hp;

    if (dflag) {
        ripq_trace("RECV", from, (void_t) msg, size);
    }
    if (msg->rip_cmd != RIPCMD_RESPONSE)
        return;

this also has a similar view that the size can at least accomodate
the rip header etc..

the layer above this does stuff like size = recvfrom()

well.. thats bad i spose, but the data is already zero initialized since
its on the bss at this point, so its not going to cause major
problems.. some logs and some conceptual "out of bounds" reads, but not
segfault or otherwise crash.

lets look at some other code

    switch (rpmsg->rip_cmd) {
#ifdef  RIPCMD_POLL
        case RIPCMD_POLL:
#endif  /* RIPCMD_POLL */
        case RIPCMD_REQUEST:
        case RIPCMD_RESPONSE:
            (void) fprintf(stderr, "\n");
            size -= 4 * sizeof(char);

ok.. the reason for the 4*sizeof(char), is that the header is 4 bytes
here (remember this for 2 seconds).

back to ripq_input..

 printf(" version %u:\n",
           msg->rip_vers);
    size -= sizeof(int);
    n = (struct rip_netinfo *) ((void_t) (msg + 1));

now we do size -= sizeof(int) which for something like x86 is going
to be 4 as above.. on a 64 bit architecture, this is mostly likely going
to be 8 bytes.

i wonder if anyone reported weird bugs against ripquery on 64 bit
architectures?

--
Silvio

On Fri, Sep 20, 2002 at 04:22:40AM -0400, Matthew McGehrin wrote:
> I think the list should just block hushmail.com and hush.com, as in the few days it has been proven that these folks are using anonymity to hide behind dozens of stupid posts.
> 
> I vote to block hushmail.com
> 
> -- Matthew

i say we cut of china from google.  i heard they have automated porn
havesting bots that rely on it.

--
Silvio