Michal Zalewski recently decided to look for exploitable vulnerabilities in
web browsers. So he write a little CGI script which generates random HTML
and feeds it to the browser; a refresh tag is used so that the browser will
repeatedly request new pages - until things come to a crashing halt.
Mr. Zalewski
reported his results on
Bugtraq as "a mini-farce." It seems that most of the browsers he tested
fared rather poorly.
The key word here is "most." One browser was able to absorb noisy input
indefinitely without crashing; that browser was Internet Explorer.
There has been quite a bit of talk recently about Internet Explorer's
security problems, and how the alternatives - both free and proprietary -
are more secure. So this kind of result is somewhat embarrassing. As
Mr. Zalewski put it:
It appears that the overall quality of code, and more importantly,
the amount of QA, on various browsers touted as "secure", is not up
to par with MSIE; the type of a test I performed requires no human
interaction and involves nearly no effort. Only MSIE appears to be
able to consistently handle malformed input well, suggesting
this is the only program that underwent rudimentary security QA
testing with a similar fuzz utility.
So what sort of HTML turned out to be problematic? A few examples have
been posted - but all you smug, free-software-using folks might want to
think twice before clicking on them. Use of a tool like wget is
probably more appropriate. One of the examples, which, as your smug,
free-software-using editor can attest, kills Firefox is, in its entirety:
<HTML><INPUT
The post notes that this bug is probably exploitable, and that many others
certainly exist. The tester also does nothing involving either cascading
style sheets or JavaScript - one suspect that those areas might, just
maybe, be the source of a bug or two themselves.
The Mozilla project has been quick to capitalize on the recent bout of
Internet Explorer security problems. This incident demonstrates, however,
that the free software community can, at times, be a little too quick to
claim better security. Testing against malformed input has been a standard
quality assurance technique for decades; the fact that Mozilla, seemingly,
has not done this testing is a little discouraging. Security can be a
winning point for free software, but it doesn't happen automatically. If
we're going to claim to have a more secure product, we should be sure we've
done the homework first. Meanwhile, expect a new set of Mozilla patches
sometime soon.
Comments (37 posted)
Alan Cox has sent out an announcement regarding a couple of tty-related
security fixes which were included in the 2.6.9 kernel release. One of
them is, conceivably, remotely exploitable, though it appears to be
impossible to exploit in most cases. 2.4 and 2.2 kernels are also
vulnerable; expect distributor updates shortly. Click below for the details.
Full Story (comments: none)
Bruce Schneier's CRYPTO-GRAM newsletter for October is out, with articles
on disclosing network outage information, license plate scanners, academic
freedom, and RFID passports. "
Normally I am very careful before I ascribe such sinister motives to a
government agency. Incompetence is the norm, and malevolence is much
rarer. But this seems like a clear case of the government putting its
own interests above the security and privacy of its citizens, and then
lying about it.
"
Full Story (comments: 19)
