#13 SECURITY: vulnerability docs inadequate

Will Estes
Matthias Andree

Dear developers,

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
or equivalent

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
criticized above.

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.


  • John43

    Logged In: YES

    I hereby nominate you to handle items A through D above, and
    deal with all the red tape and security policies imposed by
    the various Linux distros. Welcome aboard!

  • Logged In: YES

    Thanks for the offer, but no, I refuse that honor.

    Seriously, there is zero need to invoke foreign
    distributions, from Debian's security advisory and Ubuntu's
    patch and flex-2.5.33's NEWS file, it looks pretty much like
    a genuine flex-2.5.31 scanner skeleton bug.

    Only that there's still no hint 2.5.31 might not be
    production ready or alpha or beta or something like that
    either (this would excuse sloppy documentation to a major
    extent). Distributors aren't writing http://flex.sf.net/ for
    you either, are they?

    And it's flex.sourceforge.net that offers the code injection
    vulnerable 2.5.31 without the slightest note of danger.
    Still. And that's plain irresponsible. (Or where is the hint
    "don't use 2.5.31" that I missed?)

    I'd be happy to elide 2.5.31 from your front page, only the
    effort of doing that (i. e. clicking until the fingers bleed
    just to add me to the project) would outweigh the effort to
    just do that yourself I'm afraid.

    I know very well that release and security handling are
    tedious efforts, but why not ditch 2.5.31 and write a note
    "don't use 2.5.31, security bugs lurking" when adding 2.5.33
    to the front page? Excuse my not understanding that.

    Should I assume that your security handling isn't going to
    change for the nonce?

  • John43

    Logged In: YES

    Ok, I'll make a note about the security thing. It's actually
    really minor, though. Only sloppily written scanners are
    susceptible, and even then only if they require backing up
    states and match over 4096 bytes in a single token. I
    haven't seen a scanner like that in practice. All the major
    distros stuck with version 2.5.4a, which means most projects
    never even saw 2.5.31.

  • Logged In: YES

    Well, this clarification from your latest comment is what I
    would have appreciated to see in the NEWS file of 2.5.33's,
    in a security announcement (or boths) - because that makes
    estimating the actual risk possible.

    Bogofilter for instance deals with untrusted input, and
    nobody guarantees that a) spammers and scammers are sending
    tokens shorter than 4096 bytes (we've seen such in the wild,
    in long comments; we're not sure what software such exploits
    were targeted at), b) the rest of the MTA setup actually
    breaks them down to 1000 bytes per line, and bogofilter also
    uses a trailing context rule.

    And I know David has been experimenting with flex 2.5.31 to
    find out about our lexer's portability. That's reason enough
    for me to be honestly concerned.

  • Will Estes
    Will Estes

    • assigned_to: nobody --> wlestes
  • Will Estes
    Will Estes

    Logged In: YES

    As john43 noted in earlier comments, much of the vuln-
    reporting red tape is outside the control of the flex
    maintainers. Much of the information you requested was not
    publicly disclosable at the time of the release in
    question. The flex releases are marked clearly as beta code
    and the only "official" release is 2.5.4a.

    Also, as john43 noted earlier, the vulnerability arises
    from poorly written scanners.

    Thanks for your report.


  • Will Estes
    Will Estes

    • status: open --> closed