full-disclosure - Silent Fixes (was GAYER THAN AIDS ADVISORY #01: IE 5 remote code execution)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20040218224355.H86964@dekadens.coredump.cx>
From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: Silent Fixes (was GAYER THAN AIDS ADVISORY
 #01: IE 5 remote code execution)

On Wed, 18 Feb 2004, Leif Sawyer wrote:

> Uh.  Methinks you don't read the linux kernel mailing list, do you? Yes,
> every freaking buffer overflow they fix is discussed. In fact, nearly
> every change made to the kernel is discussed at some point.

Err, slow down...

There is a great deal of open source software problems that get patched
silently when the author found out about them before the general public -
and this applies to Linux components, too.

Not all authors do that, but some do. Of course the information is usually
not kept entirely secret: you can find out about it studying changelogs,
following development mailing lists for every major component of the
system, or by reviewing diffs. But that is not the point. These channels
are never going to reach the general audience. There is no official
bulletin, no BUGTRAQ post, no CERT notice. Perhaps there is a "changed int
to unsigned int to fix some bugs" entry in ChangeLogs, but so what?

I would prefer to refrain from calling names, mostly because you can't
always tell cases when a bug is fixed accidentally, and when the act of
patching is just covered up - but boy, does it happen. I can give authors
the benefit of doubt, but sometimes, it's just too much to ask. In some
"general cases", I would be willing to believe some changes made to 2.4
kernels were implemented because the developers knew something is very
wrong with the old code, and yet just kludged it in their branch, and
never told 2.2 maintainers, vendors, or the general public it might be a
good idea to do something... when approached about these problems, they
would say "oh yeah, we knew it's broken so we fixed it there". Same goes
for many other pieces of software, including popular network daemons.

Authors have very little short-term incentive to make themselves look bad
and to tell others about flaws in their software. Some naively hope that
by keeping it low profile, and only discussing it with other developers,
they are preventing the vulnerability from being exploited in the wild.
Of course, by doing so, they do hint some audiences - most often,
blackhats - and the effect is not always what they hoped for. As a result,
it's not quite a good idea to run software that is several versions older
than the most current snapshot just because there were no publicly
announced vulnerabilities in them.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2004-02-18 22:43 --
   http://lcamtuf.coredump.cx/photo/current/