Hi Elias,
yes, it is good point.
even if 1.0.0 is an old version (the actual stable one is 1.1.0) we will
try to fix it as I guess there are people still using it.
indeed, there are a lot f places (as Ron showed) where function without
size limit are used, but in some case, by doing there is no way of a
overflow (Ex: if I print an integer is a buffer of 12 chars, for sure it
will not overflow).
But we should double check all of them to be sure.
I will appreciate if you can upload this on the tracker to have it in sight.
Thanks and regards,
Bogdan
Elias Baixas wrote:
Hi all, I just found a bug in version 1.0.1 of OpenSER, in the
postgres module. I know that version is outdated, but it has some
security implications, so it maybe important to have it located and
fix it in branch 1.0.X.
The function str2valp() uses a char buffer[256] to store a message
that will later be printed to logs, this message is printed using
sprintf, so if the value returned from the database is bigger than
those 256 bytes, that drives to a stack overflow vulnerability with
its security implications (DoS easily, and maybe arbitrary code
execution in more unlikely situations).
Version 1.1.0 is not flawed by this bug, so I imagine someone must
already be aware of this.
The default configuration of the postgres db used in OpenSER limits
most of the fields to 128 or 255 characters (when created with
scripts/postgresqldb.sh) so the vulnerability is not a concern if db's
have been created this way.
In general, the common advice is not to use neither sprintf nor strcpy
to avoid this kinds of dangerous bugs, and substitute them for
snprintf and strncpy (which is almost always the case in openser
code), as well as %s by %.*s
I hope it helps !
Elias Baixas
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
