[sane-devel] possible bin_w_string security issue (not)

Johannes Berg johannes@sipsolutions.net
Fri, 15 Oct 2004 15:47:06 +0200


--=-8KpxnP81NRNqGGtcVgwN
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

I was going to write a mail without the "(not)" but then discovered that
this issue is actually a non-issue, but this is totally non-obvious.

Would you know off-hand why?

bin_w_string contains the following code:

  if (w->direction =3D=3D WIRE_DECODE)
    {
      if (len =3D=3D 0)
        *s =3D 0;
      else if (w->status =3D=3D 0)
        *(*s + len - 1) =3D '\0';
    }

If I interpret the code correctly, this could be used to bring the
server (running the binary protocol) into an invalid state:

1) send any kind of request that requires a string option at the end,
   for example SANE_NET_AUTHORIZE
2) tell the server that the length is 10 or so
3) send 9 bytes and close the connection

The server will react to this in the following way (if I interpret the
code correctly):
* during sanei_w_array it will notice that the status is
   bad and return
* bin_w_string will not(!) zero-terminate the string
   (because it is assuming that *s is not valid, while
   it actually is)
   sanei_w_array doesn't clear the array if anything
   item fails to read.
* now, the server has a password string that is not zero terminated,
   and strcpy()s that string accessing memory beyond the allocated size.


[Actually, I discovered this while I was documenting the wire protocol.
I think it is overly complex and the code badly structured, the wire's
direction thing is really strange!]





Ok, so here's the solution:

The server does
  signal (SIGPIPE, quit);

(which I think is actually another bug, why should sane_close,
sane_exit, sanei_w_exit and lots of other functions be async signal
safe?)

Still, this is that non-obvious that someone writing a server (or
client, which could then be attacked by a malevolent server) with the
sanei library functions could easily oversee this detail, ignore SIGPIPE
or use sockets that don't raise it.

Therefore I'm still sending this mail in hope that someone fixes the
sanei_w_array function to check for status !=3D 0 and clean up after
itself.

johannes

--=-8KpxnP81NRNqGGtcVgwN
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Comment: Johannes Berg (SIP Solutions)

iQIVAwUAQW/U16Vg1VMiehFYAQItGRAApmPf+qNwUfTzFswVVe1K10VSArYVmcOJ
1wN5J3zAhf9oC7gSavY5q2Y5gCZoyCj2+p+iSWf3sjDAV2+RH8WVIS34IItamOC8
zyj9g8/NgHtaF99tTi7/O2j0/3eMvr9t4/dipDZ7l83EI7C0ZYv2CsGX97dmdXf8
HPJo/9Tl4DA+UsBGMngGsj7flVrjf2zThkJzcPqEAgLv8v2Mv4LW5JNtxZIozgGM
LvLdRgYS7SVtt+owY+2bSLdW3V0dYp/QXwqHNXSvZfFHe1FT9AVZBwvF1573J14v
t+T3AwNV/qRxZC4d/0VD6JsPWJA11HFA3agutUK4TN1G10lH+1BkmoM8NXVWWy9p
9jh1G8FsQsPmnV1WGY6jy6JF4rFLARrjfCIefcDKQt5kEC8s9eMiT0+wayvUYZRr
bhO6oOgunMoPpNX3AxyvDhwzZ1uZmoied7QY+C783pY7kIWtZ45mFFCsznnX6FFN
jwhFjubDeyK03SxTzit7KsBy89wTLXqQIaKKR2IqXc9KlXEUp/UGMoEsQSjBBKth
pUSlKymbhp9kSni0DZ8LGX/G9gYhnK0yMxNUYVzBnp8GWuqC/IO/aHX2rR8n0y+W
ztf389uXOpGU7EHKRPW4NfHuzvnW2CZBN9/ReXwkrMPT4K3enB8dAsh3ipj7Ruzh
FaYv+5kkYgU=
=867r
-----END PGP SIGNATURE-----

--=-8KpxnP81NRNqGGtcVgwN--