Martin Pitt wrote:
Frank Heckenbach [2006-03-02 18:37 +0100]:
not sure, if that's actually a problem resulting in the worst scenario,
It might if someone runs the compiler in a server-like scenario. (I doubt whether anyone does, and if so, there'd be other security questions to consider.) When using the compiler normally, to build and then run a program, it's probably less harmful, since "arbitrary code execution with crafted pascal source files" is really the purpose of a compiler. ;-)
Not really. You do not want to execute arbitrary code by merely *compiling* source code. Think of autobuilders of Linux distributions, etc.
Every nontrivial package contains a makefile or a build script, so it executes arbitrary code anyway. The only semi-realistic threat is when somebody sets a teaching site, where anybody can submit a program for syntax checking.
anyway regeneration with flex-2.5.33 does fix this bug.
- SECURITY UPDATE: Fix arbitrary code execution with crafted pascal source files.
- Rebuild gcc/p/pascal-lex.c with the current flex, which fixes a buffer overflow in generated flex scanners.
- CVE-2006-0459
Do I see this right that the bug is in flex, not in GPC itself?
To be exact, it was in the scanner generated by flex.
(I suppose https://launchpad.net/distros/ubuntu/+source/flex/+bug/30940 but I've always got a 500 on this page so far.)
Right, it was marked as private so far, but now the bug is public.
Is the problem also present in flex-2.5.27?
I didn't check, but it's highly probable.
Looking at the description I see that the problem is due to line:
*YY_G(yy_state_ptr)++ = yy_current_state;
similar line is present in flex scanners generated with older flex versions, but only if the scanner uses reject rules.
AFAICS GPC scanner do not have this problem: `pascal-lex.c' do not contain `yy_state_ptr'.
I've now built and tested GPC with flex-2.5.33 as well. No regressions apart from a few harmless prototype warnings. So I suggest we offically require 2.5.33 from now on.
ATM I see no need.