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
* Andrew Makhorin [EMAIL PROTECTED] [2007-09-15 14:38]:
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
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
* Andrew Makhorin [EMAIL PROTECTED] [2007-09-15 15:59]:
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
* Andrew Makhorin [EMAIL PROTECTED] [2007-09-11 10:32]:
static void
xvprintf (const char *fmt, va_list arg)
{
charbuf[4000 + 1];
vsprintf (buf, fmt, arg);
xassert (strlen (buf) sizeof (buf)); /* here! */
xputs (buf);
return;
}
Friday, September 14, 2007, 12:21:09 PM, you wrote:
* Andrew Makhorin [EMAIL PROTECTED] [2007-09-11 10:32]:
static void
xvprintf (const char *fmt, va_list arg)
{
charbuf[4000 + 1];
vsprintf (buf, fmt, arg);
xassert (strlen (buf) sizeof (buf));
* Andrew Makhorin [EMAIL PROTECTED] [2007-09-14 13:13]:
Friday, September 14, 2007, 12:21:09 PM, you wrote:
I am a bit confused here: xvprintf is called by xprintf in
src/glplib05.c. The xprintf function is actually available in the
public API through _glp_lib_xprintf. It would then be
_glp_lib_xprintf is *not* api routine and formally being not declared
in glpk.h it is not available to the user.
Unfortunately, this is not the case. The following works here with GLPK
4.21:
$ cat test.c
main () { _glp_lib_xprintf (Ouch!\n); }
$ gcc test.c -o test -lglpk
* Andrew Makhorin [EMAIL PROTECTED] [2007-09-14 15:04]:
Even though _glp_lib_xprintf is not declared in glpk.h, it is available in
libglpk.so and malicious programs *_can_* be written that could exploit the
vulnerability.
I see no way how to hide such internal routines from the
* Rafael Laboissiere [EMAIL PROTECTED] [2007-09-14 20:50]:
* Andrew Makhorin [EMAIL PROTECTED] [2007-09-14 15:04]:
Even though _glp_lib_xprintf is not declared in glpk.h, it is available in
libglpk.so and malicious programs *_can_* be written that could exploit
the
vulnerability.
As I remember the previous bug report concerned one informational
message (from glp_simplex) not masked by msg_lev = GLP_MSG_OFF, and
that bug was fixed in 4.21.
Hi, yes, indeed, and thank you.
Well, speaking tangentially I'm not sure I'd call it fixed to be
absolutely precise, rather
Hi Rafael,
The bug report below was filed against the GLPK package in Debian.
Although the reported version is 4.20, the problem would also exist
in 4.21. Could you please check this?
As I remember the previous bug report concerned one informational
message (from glp_simplex) not masked by
Also sprach Andrew Makhorin:
As I remember the previous bug report concerned one informational
message (from glp_simplex) not masked by msg_lev = GLP_MSG_OFF, and
that bug was fixed in 4.21.
Hi, yes, indeed, and thank you.
Well, speaking tangentially I'm not sure I'd call it fixed to be
13 matches
Mail list logo
