[Owasp-argentina] Vulnerabilidades de variables manchadas

[Ezequiel Gutesman]

2009/5/12 Andres Riancho <andres.riancho en gmail.com>

> Juanjo,
>
> 2009/5/11 Juanjo Conti <jjconti en gmail.com>:
> > 2009/5/11 Arturo 'Buanzo' Busleiman <buanzo en buanzo.com.ar>
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA512
> >>
> >> Juanjo Conti wrote:
> >> > Les pregunto a Uds que tienen mas experiencia y seguro conocen más
> >> > [...] sin constitue la gran amyoría. Estoy en lo cierto? No lo estoy?
> >>
> >> la gran mayoria, si. O al menos, la mas "noticeable difference" :)
> >
> >
> > Entonces no sería incorrecto que un primer esfuerzo por un analizador de
> > código fuente esté orientado a detectar este tipo de vulnerabilidades.
> > Right?
>
> Si me tengo que jugar, digo que el 90% de las vulnerabilidades se
> pueden detectar de esta manera.
>


Estoy de acuerdo.

Hay muchos proyectos en esa direccion:

Con granularidad per-character, es decir, una marca por cada caracter, que
vive con el mientras exista dentro del interprete, se propaga y se chequea
(hasta ahora) por SQLinjection (si concatenas caracteres con marcas
distintas siguen mezcladas...):

   - grasp.coresecurity.com (en super beta, pero estamos haciendo una
   version para php-5.2.6, el que quiera esta invitado a colaborar)

Con granularidad por variable, mas para una fase de testing (una marca por
variable, si mezclas 2 una "sana" + "insana" = "insana")

   - http://wiki.php.net/rfc/taint (W. Venema)

Hay muchisimos mas proyectos, pero me parece, para lo que estamos hablando,
de los mas representativos de las opciones de granularidad.

El problema que veo yo con el analisis estatico del codigo es que  hagas lo
que hagas seguramente se te escapan o bien execution paths o bien maneras de
bypasear algun escape o algo. En cambio, con el aproach dinamico y en
run-time, podes por ejemplo, saber en el momento preciso antes de ejecutar
una query, exactamente como esta construida, por ejemplo, en grasp:

SELECT * FROM users WHERE name = 'pirulo' or 1=1 --'
..................................xxxxxxxxxxxxxxxxx.

donde . significa "limpio" X "sucio"

En el momento de mandar la query a mysql, se chequean las marcas y esta
query falla, sin importar cuantas veces encodee antes de construirla, porque
las marcas persisten AUNQUE encodees, escapes etc, si esta query llega, es
un ataque.

salu2