Re: [Fsfe-uk] Windows WMF exploit intentional?

[Chris Croughton]

On Sat, Jan 14, 2006 at 09:42:16PM +0000, Simon Waters wrote:
> Chris Croughton wrote:
> > On Sat, Jan 14, 2006 at 04:09:07PM +0000, Kevin Donnelly wrote:
> >
> > Yes, being open has some advantages, and more people /can/ look at it,
> > but who has the time?  How many Linux users have looked at any of the
> > kernel source code at all, let alone the applications?
> 
> Seriously looked at large chunks of the Linux kernel code? Probably only
> several thousand, or low tens of thousands. It is also extensively
> analysed using static analysis tools.
> 
> The kernel is the wrong example, large well known bits of code like the
> kernel get a relatively solid going over. Indeed people developing
> software tools often look for large, well known code bases like the
> Linux kernel.

Yes, the kernel is the wrong example, it's tightly controlled by a core
group and although anyone can change it they'd need good reasons to do
it (outside the actual kernel development team).  I've only once looked
at one bit which was causing me problems (something to do with
non-support for the VIA chipset as I recall, it was a known problem and
fixed in the next release anyway), and a couple of device drivers.

> The WMF was due to an API design issue, and that kind of error could
> occur readily in free software, especially code that wasn't developed
> under keen open scrutiny, but perhaps became free for other reasons.

Or which was free but no one else was particularly interested in as long
as it worked.  Again, the Linux kernel is probably an exception, most
teams have large parts where only one or a few people do certain bits
and they are just incorporated without much QA or inspection.

> I certainly think that the core components of many successful free
> software projects are often better designed than proprietary
> equivalents, but I think Chris is right that many eyes don't always help
> in these areas, especially on fringe projects, since even spotting an
> issue of this type isn't always sufficient, sometimes these are the most
> difficult to fix. Similarly those looking for bloat in some of the
> desktop projects seem to have no trouble finding stuff that is hideous.

Usually with the bigger teams.  An individual may write hideous code,
but usually individuals don't write much bloat because they can't
handle it, teams tend to write bloat the bigger they get.  Especially
when there is no firm management holding the size down (and even the
Linux kernel has grown enormously in the last few years).

> However I do think that in areas such the static analysis of source
> code, free software projects are already well ahead, and it wouldn't
> take much effort to improve on this situation.

Could be.

> I think the big pluses are in;
> 
>   backward compatibility (we can always recompile and fix old code when
> needed, where as if Word Perfect needs just a minor tweak for Vista,
> someone other than Microsoft will have to do it).

Yes, I have a load of software which is no longer maintained but I can
(and do) just recompile it for changed interfaces (and patch up where
they have changed).  Certainly a big advantage of open over closed
software, I suspect it's the major one most people will notice.

>   distribution where Microsoft and Apple are just getting to the point
> where they can distribute fixes to their own code sensible, the free
> software distros have this pretty much fully automated, from one
> packager to the whole world.

Hmm, not always smoothly, and with many variations (and many people who
still think that their way is "the best way").

> It is also easy to forget what a desparate state the MS Windows desktop
> is in. It is impossible to reasonably secure the common home Microsoft
> desktop without making it unuseable, or at least very unfriendly.
> Updating software, antivirus, and other antimalware tools is an
> unreliable, and painful process.

Yes, and as I mentioned a lot of this is because of the need to run
'legacy' code.  Almost all of the old CP/M-inherited APIs were still
there until the end of the 9x versions, and a number of them are still
preserved in command boxes even in the NT-derived ones (indeed, some had
to be added back in to make the NT API more "home-friendly").

> It is a mistake to think one needs to be perfect to do better in
> security. Absolute security is a myth, just as "bugless" code is a
> utopia that will never be reached.

Indeed.

> Free software should look to exploit its advantages to deploy better
> security. I mean if we enhance say the compiler with a security feature,
> recompiling everything is slow, but not exactly difficult.

Depends whether it is still functional.  If "secure but slow" means
"doesn't actually work" (as in real-time video, for instance) then it
won't be used.

> As to the WMF vulnerability being intentional, I think Mr Gibson gets
> some strange ideas at times. If Microsoft (or a developer there) wanted
> a backdoor in the code (or the NSA wanted one) they could put it in,
> along with the flight simulator game, and other hidden garbage, it isn't
> as if anyone checks their source code terribly closely as far as we can
> tell.

Indeed.  It would be a strange backdoor for the time it was created,
when there was no thought about security anyway (it was known that no
one would trust a MSDOS machine all that much for more than home use and
documents).

> Heck even Linux has implemented some screwy APIs from POSIX and such
> like in the interests of "compatibility", despite Linus usually taking
> the view that such stuff shouldn't go in.

And some old ones have carried over despite being not very secure.
Heck, the whole Standard C API is totally insecure, and you won't change
that without breaking almost everything (the C standards people are
looking at changes to improve things about buffer overruns, but their
'solutions' are highly criticised as being just as vunerable but in
different ways, C is just not designed for security).

Chris C