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