Security
Brief items
Multics security, thirty years later
Worth a read: Paul Karger and Roger Schell have released a new paper (available in PDF format) entitled "Thirty Years Later: Lessons from the Multics Security Evaluation." It includes an analysis of the security of the Multics operating system, written by the same two authors and published in 1974, along with a new forward describing how things have changed in the mean time. Their assessment of the current state of computer security is harsh:
The unpleasant conclusion is that although few, if any,
fundamentally new vulnerabilities are evident today, today's
products generally do not even include many of the Multics security
techniques, let alone the enhancement identified as essential.
That essential enhancement is the creation of verifiable "security kernel" around which the rest of the system could be built. In 2002, very few systems built around such kernels exist, and the authors are not very enthusiastic about those which do exist:
...the ring 0 supervisor of Multics of 1973 occupied about 628K
bytes of executable code and read-only data. This was considered
to be a very large system. By comparison, the size of the SELinux
module with the example policy code and read-only data has been
estimated to be 1767K bytes. This means that just the example
security policy of SELinux is more than 2.5 times bigger than the
entire 1973 Multics kernel and that doesn't count the size of the
Linux kernel itself. Given that complexity is the biggest single
enemy of security, this suggests that the complexity of SELinux
needs to be seriously examined.
Or, to put things in more general terms:
Given the understanding of system vulnerabilities that existed nearly
thirty years ago, today's "security enhanced" or "trusted" systems would
not be considered suitable for processing even in the benign closed
environment.
So how do we make things better? The paper does not provide a whole lot of new suggestions. The authors talk some about the tools that are used; for example, Multics was mostly free of buffer overflow vulnerabilities, thanks to the use of PL/I as the implementation language. PL/I required an explicit declaration of the length of all strings.
The net result is that a PL/I programmer would have to work very
hard to program a buffer overflow error, while a C programmer has
to work very hard to avoid programming a buffer overflow error.
Beyond that, one gets the sense that the authors feel they said what needed to be said thirty years ago, and they are still waiting for the message to get across. Their prediction:
It is unthinkable that another thirty years will go by without one
of two occurrences: either there will be horrific cyber disasters
that will deprive society of much of the value computers can
provide, or the available technology will be delivered, and
hopefully enhanced, in products that provide effective security.
The authors hope for the latter scenario; so do we.
Security reports
AFD 1.2.14 multiple local root compromises
AFD ("automatic file distributor") suffers from buffer overflow vulnerabilities which can lead to a local root compromise. Version 1.2.15 of AFD contains fixes for the problems.A couple of KDE security advisories
The KDE project has issued a couple of security advisories:- This one describes a cross-site
scripting vulnerability in Konqueror (and any other application which
uses the KHTML renderer). Javascript code running in one frame can
access other frames which should be inaccessible. This problem is
fixed in kdelibs 3.0.3a.
- The second is for a secure cookie problem in Konqueror. The "secure" flag in cookies is not recognized, with the result that "secure" cookes can be transmitted over unencrypted connections. KDE 3.0.3 fixes the problem.
We will, of course, pass on distributor updates as we receive them.
A security update to XFree86
The XFree86 project has released XFree86 4.2.1, which fixes a few security problems. The most urgent problem is a vulnerability in the internationalization code which can allow an attacker to cause a privileged X client to load and execute arbitrary code. This vulnerability only exists in XFree86 4.2.0; earlier releases are not vulnerable.No distributor updates have been received as of this writing, though Slackware has updated its XFree86 packages.
New vulnerabilities
Denial of service vulnerability in amavis
| Package(s): | amavis | CVE #(s): | |||||
| Created: | September 11, 2002 | Updated: | September 11, 2002 | ||||
| Description: | AMaViS is vulnerable to a denial of service attack via maliciously crafted input. Patches exist for AMaViS, but the recommended solution is to upgrade to the (actively developed) amavis-perl tool. See this advisory for details. | ||||||
| Alerts: |
| ||||||
Input validation vulnerability in cacti
| Package(s): | cacti | CVE #(s): | |||||
| Created: | September 11, 2002 | Updated: | September 11, 2002 | ||||
| Description: | Cacti is a PHP front end to rrdtool; it assists in the creation of plots from a MySQL database. This tool does not properly validate all input, leading to a remote code execution vulnerability in certain, limited conditions. See this Bugtraq posting for details. | ||||||
| Alerts: |
| ||||||
Cross-site scripting vulnerability in mhonarc
| Package(s): | mhonarc | CVE #(s): | CAN-2002-0738 CAN-2002-1307 CAN-2002-1388 | ||||||||||||
| Created: | September 11, 2002 | Updated: | January 3, 2003 | ||||||||||||
| Description: | Mhonarc is an HTML formatter for electronic mail; it can be vulnerable to cross-site scripting problems when presented with maliciously crafted messages. This problem is fixed in mhonarc version 2.5.3, but it is not clear that all possible vulnerabilities have been fixed. See the Debian advisory below for information on how to disable text/html attachment support in mhonarc, which may be a more secure solution. | ||||||||||||||
| Alerts: |
| ||||||||||||||
Multiple vulnerabilities in wordtrans
| Package(s): | wordtrans | CVE #(s): | CAN-2002-0837 | ||||
| Created: | September 11, 2002 | Updated: | February 4, 2003 | ||||
| Description: | The "wordtrans" interface to multilingual dictionaries suffers from input validation and cross-site scripting vulnerabilities; versions through 1.1pre8 are vulnerable. See this Guardent advisory for details. | ||||||
| Alerts: |
| ||||||
Resources
The IP Security Protocol (Linux Journal)
This Linux Journal article explains IPSec, different levels of security and how to be safe sending and receiving packets over the network. "Several different solutions exist that allow us to cope with this problem, each operating at a different level of abstraction. In this article, we will discuss the differences between and purposes of application-level security, socket-level security and network-level security."
This article continues with part 2 which moves on to encapsulating security payloads and key exchange mechanisms.
This week's Linux Advisory Watch and Security Week
The Linux Advisory Watch and Linux Security Week newsletters from LinuxSecurity.com are available."Know Your Enemy: Honeynets" paper updated
The Honeynet Project has announced an update to its "Know Your Enemy: Honeynets" paper. "This update includes far greater detail in explaining how to deploy 1st and 2nd generation Honeynets. Even more exciting, we have released a significant amount of new code, especially for GenII (2nd generation) Honeynets! This should make deploying these technologies much easier, with different options and different operating systems."
Events
Security events calendar
| September 19 - 20, 2002 | SEcurity of Communications on the Internet 2002(SECI'02) | Tunis, Tunisia |
| September 23 - 26, 2002 | New Security Paradigms Workshop 2002 | (The Chamberlain Hotel)Hampton, Virginia, USA |
| September 23 - 25, 2002 | University of Idaho Workshop on Computer Forensics | (University of Idaho)Moscow, Idaho, USA |
| September 26 - 27, 2002 | HiverCon 2002 | (Hilton Hotel)Dublin, Ireland |
| September 27 - 29, 2002 | ToorCon 2002 | (San Diego Concourse)San Diego, CA, USA |
| October 16 - 18, 2002 | Recent Advances in Intrusion Detection 2002(RAID 2002) | Zurich, Switzerland |
Page editor: Jonathan Corbet
Next page:
Kernel development>>