Thomas –
This week, advisories were released for bugzilla, ethereal, tcptraceroute, Netscape,
ypserv, XFree86, xpdf, orville-write, eldav, xbl, webfs, osh, and foomatic.
The distributors include Conectiva, Debian, Mandrake, RedHat, TurboLinux, and
YellowDog. Like most weeks, the more proactive vendors released several
new advisories and others submitted advisories for older issues. Overall,
this week has not been very active.
I wanted to take a moment to thank the readers for the wonderful feedback that
we received. If you missed last
week’s Advisory Watch, I discussed Gartner’s latest report that suggests
IDS technology will be obsolete by 2005. Although I find this report very
interesting, I did not expect the amount of feedback that I received.
Most people agreed with my conclusion that a majority of all system vulnerabilities
could be alleviated if administrators would simply patch his/her system quickly.
An insightful reader by the name of Jeremy quickly wrote, “Hear hear!
But you can’t really blame the sysadmins.” He continued to discuss
how the inability to maintain systems is not the fault of the administrator.
He pointed out that the burden ultimately falls on upper management.
System administrators only do what they are told to do. Adequate
funding and support is necessary to maintain a secure and stable system.
Jeff Cours, wrote the following:
I think the fundamental problem is that software engineering
is still a very young field of engineering. I run a Linux box at home.
Because I’m not a full time administrator and don’t have time to keep track
of vulnerabilities as they come up, I use Red Hat Network. Even then, I
am constantly surprised at the number and frequency of updates that come
down the pipe. The fact that my system needs so much maintenance is, I
think, a sign that we don’t yet know how to engineer software with the
same level of reliability that we can engineer, say, a bridge.Here, as I see them, are some of the open issues in software engineering:
1. Gotos, Pointers and Threads
Gotos, pointers, and threads are all paradigms that have the same underlying
problem of unpredictability. Gotos can transfer control to a huge range
of places within the program. Pointers allow data access to a huge range
of places. And threads allow an enormous number of possible orders of execution.
(Exceptions and interrupts are similar to threads in this respect, but
they’re a little less extreme.) All three paradigms tremendously increase
the number of cases the engineer has to analyze to make sure the code properly
handles them. Structured programming sharply reduced the number of gotos,
but pointers and threads are still in widespread use. I think we’ll either
need new paradigms that are as useful as threads and pointers but don’t
introduce as many cases to analyze, like structured programming did for
gotos, or we’ll need more powerful analysis techniques.2. Fault Propagation
The cables that hold up the Golden Gate Bridge are made of multiple
strands of wire. One reason for that design choice is that, if a single
strand breaks, the break is not likely to affect neighboring strands.Unfortunately, we don’t yet know how to do that same thing with software.
A bug in one part of the code might stay local (say, just affecting the
output of a print statement) or its effects might propagate and cause the
whole application, or in some cases the whole operating system, to crash.
As far as I know, fault propagation in software is still an area of active
research.3. Predictability
When civil engineers build a bridge, they have a good idea before they
build it how much wind or how strong an earthquake it can withstand, how
much load it will bear, and how much traffic can go across it. Software
engineering hasn’t yet reached that point. We’ve made a great start: quality
assurance techniques can say roughly how many bugs remain in a given release,
and complexity analysis helps us choose one algorithm over another, but
we don’t yet have analysis tools that will let us accurately predict how
reliable a program will be, how fast it will run, how well it will handle
unusual inputs, or how long it will take to write it.I don’t mean to say that software engineers are slacking. On the contrary,
we’ve made tremendous progress, but we’ve had only 50 or 60 years to work
on the problem. It would be interesting to survey the more mature fields
of engineering and see how long it took them to get to that state. I wouldn’t
be surprised if it takes 100-150 years and a few bridge collapses (or equivalent)
for a field of engineering to mature, which would mean we should see the
number of security patches start to drop off somewhere in the second half
of this century.In the meantime, you’re right, we can expect to have to patch our systems
regularly. Here, I think systems like Red Hat Network and Debian’s package
management have a lot to offer: they recognize that human nature is much
harder to change than technology, so they make it as easy as possible to
find out that an update needs to happen and to apply it. Yes, exhorting
sysadmins to patch their systems is also important, but it seems to me
that it’s only one small piece of a much larger issue.
Jeff made several very good points. I particularly like his analogy comparing
software engineering to conventional engineering projects. Also this week,
I spoke with a security consultant from one of the Big 5 Accounting firms.
I asked him what his opinion was on the Gartner report. He replied by stating
that he did not believe IDS would be dead by 2005, but only IDS as we know it
today. He pointed out that IDS technology will get more sophisticated, but
there will still be a need for it. He had a hard time agreeing that they
will be obsolete. What do you think? I tend to agree. I see
the technology getting better, but I don’t see it going away. Perhaps the
real issue here is that people are now beginning to realize that an IDS is not
an all-in-one solution. It is merely a single tool in an entire tool chest.
Remember Ye Olde Security Wisdom, “Security Is Not a Product; It’s a
Process” (Schneier,
Crypto-Gram: December 15 1999)
Everyone wish me luck; I’m getting married this Saturday!
Take care,
Benjamin D. Thomas
LinuxSecurity Feature Extras:
Real-Time
Alerting with Snort – Real-time alerting is a feature of an IDS
or any other monitoring application that notifies a person of an event
in an acceptably short amount of time. The amount of time that is acceptable
is different for every person.Intrusion
Detection Systems: An Introduction
Intrusion Detection is the process and methodology of inspecting data
for malicious, inaccurate or anomalous activity. At the most basic levels
there are two forms of Intrusion Detection Systems that you will encounter:
Host and Network based.[ Linux
Advisory Watch ] – [ Linux
Security Week ] – [ PacketStorm
Archive ] – [ Linux Security
Documentation ]
Linux Advisory Watch is a comprehensive newsletter that outlines
the security vulnerabilities that have been announced throughout the week.
It includes pointers to updated packages and descriptions of each vulnerability.
[ Subscribe
]
Distribution: | Conectiva | |||
6/20/2003 | bugzilla | |||
vulnerabilities
This update fixes several problems with the bugzilla package shipped |
||||
6/20/2003 | ‘BitchX’ remote vulnerabilities | |||
vulnerabilities
This update fixes two remote vulnerabilities in Bitchx |
||||
6/20/2003 | ‘netpbm’ math overflow vulnerabilities | |||
vulnerabilities
Alan Cox and Al Viro discovered[1] several “math overflow” vulnerabilities |
||||
6/20/2003 | ‘apache 2’ vulnerabiltiies | |||
vulnerabilities
This update addresses two security vulnerabilities which have been fixed |
||||
6/25/2003 | ethereal | |||
multiple vulnerabilities
This update announcement addresses several vulnerabilities in ethereal |
||||
Distribution: | Debian | |||
6/20/2003 | ‘orville-write’ buffer overflows | |||
multiple vulnerabilities
Orville Write, a replacement for the standard write(1) command, contains |
||||
6/20/2003 | ‘eldav’ temp file vulnerabilities | |||
multiple vulnerabilities
eldav, a WebDAV client for Emacs, creates temporary files without taking |
||||
6/20/2003 | ‘xbl’ buffer overflow | |||
multiple vulnerabilities
Steve Kemp discovered several buffer overflows in xbl, a game, which |
||||
6/20/2003 | ‘webfs’ buffer overflow | |||
multiple vulnerabilities
webfs, a lightweight HTTP server for static content, contains a buffer |
||||
6/20/2003 | ‘osh’ buffer overflows | |||
multiple vulnerabilities
Steve Kemp discovered that osh, a shell intended to restrict the actions |
||||
6/23/2003 | tcptraceroute | |||
root privilege vulnerability
tcptraceroute is a setuid-root program which drops root privileges after |
||||
Distribution: | Mandrake | |||
6/25/2003 | ethereal | |||
arbitrary code execution vulnerability
A number of string handling bugs were found in the packet dissectors |
||||
Distribution: | RedHat | |||
6/20/2003 | Netscape | |||
Multiple vulnerabilities
A number of string handling bugs were found in the packet dissectors |
||||
6/25/2003 | ypserv | |||
denial of service vulnerability
A vulnerability has been discovered in the ypserv NIS server prior to |
||||
6/25/2003 | XFree86 | |||
multiple vulnerabilities
There are multiple vulnerabilities in XFree86. |
||||
Distribution: | TurboLinux | |||
6/24/2003 | xpdf | |||
arbitrary command execution vulnerability
If a victim clicks on a hyperlink contained within a malicious PDF file, |
||||
Distribution: | YellowDog | |||
6/25/2003 | foomatic | |||
multiple vulnerabilities
There are multiple vulnerabilities in the foomatic package. |
||||
6/25/2003 | xpdf | |||
arbitrary command execution vulnerability
Martyn Gilmore discovered a flaw in various PDF viewers and readers. |
||||
6/25/2003 | hanterm-xf arbitrary command execution vulnerability |
|||
arbitrary command execution vulnerability
An attacker can craft an escape sequence that sets the window title |
||||
Category:
- Security