[Pkg-scicomp-devel] Bug#441478: [ptb at inv.it.uc3m.es: Bug#441478: libglpk0: security flaw buffer overflow in glplib05.c xvprintf]

[Andrew Makhorin]

>> > Actually, there is a way to circumvent the problem. It is quite ugly
>> > and I am not sure you would like to implement it. Here is it: make
>> > the functions xprintf and xprint1 both static, and move them,
>> > together with xvprintf, into a header file (.h) which will be
>> > included by all other files calling xprintf or xprint1. The only
>> > side effect is that the resulting shared library will increase in
>> > size.
>> 
>> I do not understand the problem. There are many internal glpk routines
>> prefixed by '_glp_', which, in principle, can be called from the user
>> program. However, there is a common convention not to call such routines
>> from outside.

> We are not talking about normal users following the conventions.  We are
> talking about a malicious hacker that could exploit the buffer overflow
> vulnerability currently in GLPK.  I do not know much about such exploits
> (and have no interest in learning them either) but knowing that Debian is
> currently distributing libglpk with such a vulnerability makes me really
> nervous.

I do not think that that could jeopardize the system, only the application.

> I think that I will patch your sources for the Debian package along the
> vsnprintf lines suggested by Peter.  I would encourage you to fix the
> problem in the GLPK source.

Okay. I will make necessary changes to use vsnprintf rather than vsprintf
in the next release.

Best wishes,

Andrew Makhorin