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.
Waldek Hebisch wrote:
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.
Of course, strictly speaking, Martin is right, but for practical purposes I agree with Waldek.
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'.
Yes, I avoided REJECT because of the performance penalty. So if that's all that's affected (I still get a 500 on the above page, and I haven't searched again now), then we have no problem anyway.
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.
Still it might be useful to install 2.5.33 on one's system if one also builds other packages which might use flex and perhaps contain REJECT. Anyway, I'll test with 2.5.33 now, and you can test with another version, if you prefer.
Frank
-
Frank Heckenbach -
Waldek Hebisch