it has recently come to my attention (through the
Debian security advisory) that flex 2.5.31 was
vulnerable to a buffer overflow that allowed remote
code injection (apparently CVE-2006-0459).
As I am the co-maintainer for the bogofilter project
and maintainer for the fetchmail project that use flex,
and we'd experimented with flex 2.5.31, I interested
myself in the problem, downloaded flex 2.5.33 and all I
find is this utterly inadequate and, to put it as plain
text, barefaced notice in "NEWS":
"** numerous bug and security fixes"
1. No documentation in the ChangeLog, 2. none on the
web site, 3. no details about the security fixes, which
bugs there were, 4. how they could be triggered, 5.
when they were introduced (earliest vulnerable
version), 6. when and 7. how it was fixed, 8. no
reference to CVE-2006-0459, no note on the web site or
in the project news, 9. no note if the latest stable
release, 2.5.4a, was vulnerable. 10. No note next to
the 2.5.31 download on the flex.sf.net website. 11. No
info about the release/support/suitability for
production of 2.5.31/2.5.33 on the web site.
This handling of security issues is utterly
inacceptable even for a spare-time project and has
SEVERELY damaged my trust into flex. I am therefore
considering switching all my projects away from flex
and use different scanners. There have been five weeks
since the new release to document these vulnerabilities
before I'm writing this bug report.
I acknowledge that flex-2.5.3X are dubbed "development"
on Freshmeat; unfortunately, the CVS browser on
SourceForge yields "Internal Server Error".
Proper security handling would:
A. send an official announcement to the announcement
list that marked 2.5.31 vulnerable and either pointed
to Ubuntu's patch at
B. mark 2.5.31 vulnerable on the web site and remove
the download (the file will still be available through
prdownloads.sourceforge.net, so no harm done here)
C. mention in detail the missing information bits I
D. clearly mark experimental/alpha/development versions
not meant for production as such.
As many projects inherit flex's vulnerabilities and in
most of them, rebuilding the scanner and issuing new
tarballs is required, it is of paramount importance
that word is spread to all developers of projects using
Please rethink your handling of security
vulnerabilities. Playing hide and seek can only lose
trust and importance.