LWN.net Weekly Edition for July 6, 2006 [LWN.net]

Interview: Jim Gettys (Part II)

The first part of our interview with Jim Gettys covered many aspects of the "One Laptop Per Child" (OLPC) system. With the second and final installment, we look at a number of other issues, including the software which will run on the system, security issues, and more.

LWN: Time for a few questions about the mix of software you envision running on the OLPC systems. To start with, it appears that the system will be based on a pared-down Fedora-based distribution?

To date, Red Hat are the ones who are putting serious engineering into OLPC and doing most the heavy lifting on the base system, and have assembled a first rate team, including Dave Woodhouse and Marcelo Tosatti.

Red Hat is putting together a pared-down Fedora derivative distribution. The community being what it is, I expect others will put other distributions on the machine as well, given that the OLPC system is an open platform. I'm not sure such duplication is worthwhile, but I'm resigned to it.

I *really* urge everyone to cooperate very strongly at the level of the software for the kids, no matter what the underlying distribution in the long term. This project is fundamentally about kids learning and helping the world; not about free software.

That being said, *free software enables the kids to learn computing in a way that they cannot learn it on closed proprietary platforms*. We are therefore very much part of the free and open source software community.

Chris' team is putting together a python based environment (into which conventional applications can be embedded) aimed at young children, temporarily called "sugar" (more information can be found in postings here, here, here, and here); conventional GUI's are not good for children still learning to read. I have a 8 year old son and an 11 year old daughter, and so have seen over the last few years first hand how unsuitable conventional desktops are for young children.

The Sugar environment, by using the Avahi library (zeroconf/mdns technology), will show the presence of people on the network as a fundamental aid to building collaborative applications. Collaboration is fundamental to learning: most kids learn from their peer group, and teachers serve as the guides.

Will the systems as shipped be 100% free software?

OLPC itself only plans to ship free software at this time.

If not, what other code do you think you might include?

Let me give a concrete example: some countries have coded some educational content in Flash.

We are strongly recommending that future content not be created in closed format like Flash, whose format is closed, lack tools for manipulation, and present major problems for accessibility tools.

But some countries have such content today, and need to use it immediately. And since there is so much flash content on the web, it would not surprise me if countries arrange for Flash to be installed, even if they do not have existing educational content in Flash. We are encouraging everyone to use open standards based formats, and to release useful content under appropriate free creative commons and free software licenses.

Reality being what it is, even if we had veto power over software on the machine (which we certainly don't), we'll see such software included on the machine by the time it in children and teacher's hands; just not distributed from OLPC, but added on afterwords.

Is it true that there will be no package manager on this system?

This is an area where we continue to have discussions. Whether it is like conventional packaging systems or not is unclear right now. Time will tell.

If so, will there be any provision for customizing the system software mix, installing localization data, or updating software?

Of course. There has to be. By middle school, kids are taking different courses and languages. Some kids have special needs, either advanced or the opposite. One of the major advantages that an OLPC has over conventional books, is the possibility to bring much more content appropriate for each child to that child, who live in places which lack libraries we find in U.S. and other developed nation's schools.

A system like this clearly needs a good set of education applications - an area where free software has not traditionally been strong. What sort of applications are you looking at in this area, and might any missing pieces come from?

There is much software sold claiming to be "educational" software, which isn't. The reality is that there aren't all that many good educational applications on *any* platform. The pickings are pretty slim.

We believe all children learn by doing, and should be authoring content, not only passively reading unchangeable engraved in stone content. We are placing some major bets on wiki technology as a base for this. (Not wiki markup though!).

I'd also like to draw your attention to a web site: logowiki.net. Content doesn't have to be static at all, and content can be programs, even programs for young children. The ability to run simulations and manipulate the starting conditions is a major tool to learning.

And one more hardware feature is unique to our machine: you can choose to use the audio input as a direct analog input, allowing direct measurements be made with very cheap sensors (e.g. photodiodes, accelerometers, etc.).

With the likes of Seymour Papert and Alan Kay involved, I think we're in for some fun stuff. For example I saw a demo this week of a wonderful music application called TamTam, that Jean Piche' et al in Canada and Ireland are building using the Csound synthesis software Barry Vercoe originally developed.

Will the systems include a compiler, or, failing that, an interpreter for a language like Python?

Of course.

At a minimum, we expect Logo, javascript and python to be present, and compilers as well when needed by interested kids. Learning programming, though, is best done in interpreted language environment, rather than compiled languages. Certainly C++ should never be a child's first computer language.

In general, is hacking one of the uses to which you think these machines will be put?

Hacking, in the original positive sense of the word (see the Jargon File), we certainly believe should be strongly encouraged in interested children: computing is a fundamental skill in today's society. For others, computers will just be a tool; their pen and paper.

Do you expect that the kids will have root access on their systems?

Yes: we want children to be able to learn computing, if they are interested. For the kid's systems, we want them "easy to fix", rather than "hard to break". For the school's servers, a shared resource, we want them to be "hard to break" *and* "easy to fix", and are exploring technologies like those developed by Planetlab.

Being root on your own personal machine is fundamentally different than having any access to information on the network you should not have. Project Athena, at MIT (where such technologies as Kerberos, X11, the first network IM system, among others), demonstrated this even 20 years ago: on those systems having root access does not get you access to anything but the services you had access to as an individual user. The root password on those systems has been posted for years: it just doesn't matter, if you do your homework properly.

The plan to use LinuxBIOS is interesting. Are there reasons driving that choice (beyond cost)?

Cost isn't a real factor in this decision. The royalty rate of a conventional BIOS is in fact very low.

Capability:

we'd like to be able to boot over the mesh network for (re)install
we may need to follow Mark Foster's fast suspend/resume path, in which case having full source may be essential to its success.
We want interested kids to be able to see how computers really work and learn accordingly.

Some years ago when I was working on Linux on the iPAQ, we had a 12 year old who was hacking on our boot loader, and learning tremendously as a result. Those outstanding kids should also have the opportunity to learn computing deeply.

Is LinuxBIOS ready for this sort of deployment?

We think so. It's already deployed commercially at pretty high scale on a number of products. And the very fast suspend/resume we may need to implement requires complete freedom of action at all levels of the machine.

Millions of identical systems, mostly lacking professional administration, would seem like a magnet for malware authors. What sort of thought is being put into preventing these systems from becoming worm carriers and large-scale zombie networks?

I doubt they will be exactly identical (other than hardware): language is but one of the obvious differences; children take different courses, and study different languages.

And if they need professional administration, we've failed.

Our view is that systems cannot require professional administration at a local level: we could not deploy quickly on this scale and have sufficient expertise if this were required. Part of the IPv6 argument is exactly to allow administration to scale and to simplify administration.

Eugene Kaspersky, who has been predicting Linux doom for years, is now saying that the OLPC will result in a new wave of malware from the developing world. Do you find this outcome plausible? Why or why not?

I don't find Mr. Kaspersky's arguments plausible, for a number of reasons.

We certainly are aware that security is a challenge: young children are not noted for choosing and keeping secure good passwords, and we are looking at other methods as a result.

We expect to deploy SELinux protecting the "standard" network services on our machines to help protect against day-0 attacks, to prevent bad guys from successfully attacking our systems and prevent such people from using our systems as a point of attack.

And keeping our systems up to date automatically is obviously essential.

As far as malware from the developing world: malware for what? Malware is very rare on Linux or Apple's OS/X systems: both systems break out of the starting gate much less insecure than Windows, and writing malware for either is inherently more difficult. And if Mr. Kaspersky's worried about kids in the developing world writing malware on the OLPC systems to attack Windows, how are the kids going to test such Windows malware since our machines are running Linux?

Malware authors working for profit (e.g. stealing passwords and accounts) are certainly going to be older than our kids, and will find a standard Windows system a much more productive development environment, and internet cafe's a much more anonymous place to launch attacks than our school environments.

Lastly, both at the school servers, and the networks supporting them, we have good places to prevent, stop, and track down any such attacks, much better than you'd find in the anonymous world of Internet Cafe's where anyone can pay for anonymous usage.

And high bandwidth back-haul from schools is unlikely to be very common, limiting the problem if it does occur. There are much better targets for zombies: e.g. systems all over the developed world where each machine has a high bandwidth broadband connection, rather than a kid's machine on a large shared mesh network back connected through a similar single connection. Per compromised machine, there may be a difference of a hundred to one of useful bandwidth.

Seems to me that Mr. Kaspersky knows not what he writes of, and is trying to gain eyeballs on his stories by sensationalism.

Given the state of the art, the chances of a security vulnerability turning up in the shipped OLPC systems must be near 100%. What happens then? How will OLPC users obtain and install security fixes?

Our challenge is not just the kid's machines and operating system, but also deployment of server machines in all the schools, to cache distribute software and educational content to all of them.

We expect the kids machines to be updated from school servers, and possibly from other kid's systems.

The closest management tools to what we need appears to be many of the technologies developed by PlanetLab: the commercial distributed content systems are unlikely to work, presuming as they do that systems are in data centers and always/usually available over high speed networks.

At our scale, (and with the highly variable Internet connections we expect), a presumption of constant connectivity seems untenable. We'll know more as we look into this aspect of the project more fully over the next few months.

Some commenters on LWN have expressed concerns that many of these systems may be stolen from the children and used for (or sold to fund) rather less wholesome ends. Is this an issue which the OLPC team has thought about?

Yes, we've thought about it quite a bit.

How could this risk be minimized?

First, we intend that the systems be instantly recognizable as kid's systems, not only so that kids like them and value them more and take care of them carefully, but also so that adults with machines in their possession may be asked questions about whether they should have the machine. And these systems are physically sized for smaller children, our primary "customers"; while adults can use them, it is less desirable than a bigger machine might be.

Second, public education about these distinctive systems is a topic we've discussed with deployment countries as a deterrent.

Third, by saturating each area during deployment, rather than distributing machines piecemeal, we can expect much better mesh networking performance, but also less child from child theft.

Fourth, there will be a commercial version of the machine (that will look quite different) at some point in the project, to reduce the pressure for these unique systems. As I explained before, there are quite a few ways in which these machines are unique, so we'd like there to be fewer reasons for theft, by enabling a commercial version. These commercial machines may also help cross subsidize the children's machine, for as long as the market might bear such a price differential.

Fifth, by its nature, there is a network MAC address in each machine that can aid its tracing, in the case of theft, once a system is recovered. We are, however, very concerned about the child's privacy and safety, and so don't want the systems to go around broadcasting the hardware MAC address in the normal case.

And we're exploring some other possible identity systems as well that may help in this area.

A huge "thank you" is due to Jim, who clearly took a great deal of time to respond to LWN's questions in such detail.

Comments (24 posted)

A software patent attack on Red Hat

Red Hat is long been a likely target of legal attacks; the company has a high profile, customers who can be threatened, and a bank balance which is worth the trouble of coveting. So it is not entirely surprising that a small company called FireStar chose Red Hat as the target for a software patent suit. It is unlikely to be the last.

The patent in question is US patent 6,101,502, which is said to be infringed by the "Hibernate" product acquired with JBoss. This patent, filed in 1998, asserts the following claim:

A method for interfacing an object oriented software application with a relational database, comprising the steps of:

selecting an object model;
generating a map of at least some relationships between schema in the database and the selected object model;
employing the map to create at least one interface object associated with an object corresponding to a class associated with the object oriented software application; and
utilizing a runtime engine which invokes said at least one interface object with the object oriented application to access data from the relational database.

In other words, this is a patent on an object-oriented wrapper for data in a relational database management system. To say that this idea is obvious is to understate the case. The first thing any object-oriented programmer does is to create classes to encapsulate the data to be manipulated; of course such a programmer would create a series of objects to represent relations in an RDBMS. One would expect that it would be possible to examine a large number of object-oriented programs which work with RDBMS systems and not find a single one which lacks this sort of impedance-matching layer. So the world did not need to wait until 1998 for the authors of this patent to come up with this idea.

Thus, if Red Hat puts up a suitable level of resistance, it should be able to get this patent invalidated. But there is little comfort to be found there. There are thousands of these patents in circulation and no shortage of trolls willing to exploit them to line their own pockets. One such case can be beaten down; but there will be more than one. Perhaps many more. Software patents have long been seen as a serious threat to free software; now we are beginning to see this threat come to life.

[As an aside, there have been some allegations that at least one Red Hat employee engaged in pro-patent lobbying in Europe last year, and that, as a result, this suit represents a sort of poetic justice. See this week's Letters Page for a discussion of both sides of this issue. The statement from FFII found there would appear to establish that Red Hat's position on software patents has been clear and consistent.]

Comments (2 posted)

SCO: the end gets closer

Your editor misses the Good Old Days, when outlandish SCO court filings were a daily occurrence, Darl McBride's fulminations were daily press fodder, and the occasional corporate teleconference could be counted upon to keep blood pressures high in the community. One could almost get nostalgic about plowing through yet another blurry PDF file filled with bizarre legalese. The world feels a little lonely now that Chris Sontag no longer shows his face in public.

Actually, the above paragraph is a bunch of hot air; LWN is more fun without the SCO Group on the front page. But a certain morbid interest suggests that the SCO end game should occasionally be chronicled as important milestones unfold. One of those milestones was passed on June 28, when Judge Wells issued an order in SCO v. IBM. For those of us who have been patiently (or, perhaps, not so patiently) waiting for SCO to feel the consequences of its lack of discretion in public and its lack of any actual evidence of wrongdoing, the time has finally come.

The SCO Group, remember, has been under court order for some time to disclose "with specificity" exactly what it thinks IBM did wrong. SCO's final answer took the form of 294 "specifics," described in a sealed filing. IBM responded with a motion saying that most of SCO's claims lacked the required level of specificity and should simply be thrown out, regardless of whether they might have any merit or not. Judge Wells's order was the court's response to this motion.

After reviewing (at length) SCO's history in the case, Judge Wells concluded that SCO's claims were, indeed, not specific enough. Not enough for the court, but also not up to the level that SCO expected from IBM. Thus:

Given SCO's track record in this case, the court is certain that if IBM had simply provided line information without version and file information for "methods," SCO would have filed motions to compel complaining about IBM's lack of specificity. The court cannot find any reason why SCO should not be held to the same level of accountability that SCO held IBM to. Thus, SCO should have supplied not only line but version and file information for whatever claims form the basis of SCO's case against IBM.

Failure to meet the specificity requirement is not enough to throw the claims out, however; a couple of other criteria must be met. One is that the failure was willful - that SCO deliberately failed to disclose that information. According to Judge Wells, that is, indeed, the case:

There is no evidence before the court to indicate that SCO lacked the ability to comply with the court's orders. In fact, given SCO's own public statements outlined in part supra, it would appear that SCO had more than enough evidence to comply with the court's orders....

Based on the foregoing, the court finds that SCO has had ample opportunity to articulate, identify and substantiate its claims against SCO. The court further finds that such failure was intentional and therefore willful based on SCO's disregard of the court's orders and failure to seek clarification. In the view of the court it is almost like SCO sought to hide its case until the ninth inning in hopes of gaining an unfair advantage despite being repeatedly told to put "all evidence . . . on the table."

One might well argue that this is a charitable view of SCO's behavior. But it makes one thing clear: the court has noticed the discrepancy between SCO's public bluster and the evidence it has actually put forward in the trial.

Finally, IBM had to show that it was being hurt by SCO's failure. The court had no trouble buying IBM's argument that it would be hard put to defend a case where it is unaware of what it has done wrong. The troubles go beyond that, though:

Without more specificity than SCO has provided some very important questions that could materially impact this case are nearly impossible to answer. For example, is the code that comprised the method or concept still in use in Linux? If not, then damages may become nominal instead of in the billions. Or, it may be possible that the code comprising a method or concept was already disclosed pursuant to some other license such as the BSD License.... Without the code, however, there is no way to ascertain exactly what the impact is of prior disclosures that may involve the code at issue in the instant case.

The end result is that IBM won big: 182 of SCO's claims have been summarily tossed out - just ten short of what IBM had asked for. On the order of 100 claims remain. This ruling is clearly a major blow to SCO's case, but just how major is hard to say: since SCO's claims remain under seal, we cannot know which ones have survived. But it is clearly a much shorter list, with much of the "methods and concepts" vapor removed. And, just as importantly, the court appears to have concluded that SCO has been given plenty of rope at this point; with luck, this whole episode might just reach a conclusion sometime soon.

Comments (4 posted)

Page editor: Jonathan Corbet

Security

Prelink and address space randomization

July 5, 2006

This article was contributed by John Richard Moser

Prelink (PDF) is a popular tool used to decrease program load time, shortening system boot time and making applications start faster. Developed by Jakob Jelinek at Red Hat, prelink relocates libraries on disk to save dynamic linking time.

When the dynamic linker loads a dynamically linked ELF binary, it has to also load and link all of the libraries before executing the program's entry point, _main(). This process involves relocating libraries—changing all addresses referenced in the library to reflect the actual addresses in memory. Relocating libraries involves iterating through each address in the library and replacing it with the real address as determined by the library's location in the process's virtual address space. Most relocations happen in the symbol table and PLT; but in rare cases there are also .text relocations which require fixed-position executable code to be patched in a slightly slower process.

The relocation process will slow down an application's launch. In order to speed up the process, prelink relocates the libraries ahead of time. This is done by scanning every executable to be prelinked, generating a graph of libraries that will be loaded at the same time as other libraries, and then calculating target addresses for each library at such that it will never be loaded at the same address as other libraries. These offsets are then stored in the shared object files themselves, and the symbol tables and segment addresses are all adjusted to reflect addresses based on the chosen base address.

Once prelink has done its job, the dynamic linker no longer has to concern itself with relocation. Libraries are loaded at the address specified in the library header and the symbol table is already correct. If anything forces the library to be loaded at a different address, then the library is relocated appropriately as usual; otherwise we can say goodbye to the load-time overhead of relocating libraries.

Kernel facilities supplying address space layout randomization for libraries cannot be used in conjunction with prelink; to do so would require relocating the libraries, defeating the purpose of prelinking. Address space randomization is a core feature of secure systems such as OpenBSD, Adamantix, Hardened Gentoo, Fedora Core, and Red Hat Enterprise Linux. It has appeared as part of PaX as well as part of Ingo Molnar's Exec Shield, and has been accepted into the mainline kernel as of 2.6.12 after submission by Arjan van de Ven.

The simple purpose of address space randomization is to make it more difficult to perform certain classes of attacks by changing where in memory important segments for the attack are loaded. If an attacker wants to execute injected shell code or manipulate the program to execute out of order, he obviously has to know where that code is. By shuffling memory segments around, these attacks become quite difficult; the chances of successful attack are mathematically described in the PaX documentation and Wikipedia.

In an attempt to restore some of the benefits of address space randomization, prelink is capable of randomly selecting the addresses used for prelinking. This makes it more difficult to perform certain attacks on a system, because the addresses used are unique to that system. This approach is, however, less effective than per-process randomization because the addresses stay constant until prelink is run again.

There is another implication that has to be examined with prelink. To understand this implication, let us first review a feature of prelink by examining the load address of the C standard library in two processes: a user-owned 'cat' and a root-owned 'bash'. The C standard library is interesting because, in practice, virtually all return-to-libc attacks utilize it exclusively.

 user@icebox:~$ cat /proc/self/maps | grep libc | grep r-xp
 4df2e000-4e053000 r-xp 00000000 08:07 81197      /lib/tls/i686/cmov/libc-2.3.6.so
 user@icebox:~$ sudo -s
 root@icebox:/home/user# cat /proc/$$/maps | grep libc | grep r-xp
 4df2e000-4e053000 r-xp 00000000 08:07 81197      /lib/tls/i686/cmov/libc-2.3.6.so

Closely examining these quickly verifies that the address of glibc's executable code is the same between these two processes; this is consistent with the behavior of prelink. Because the library itself is relocated ahead of time, there is a preference for the dynamic linker to load it at that address. Examination of libc itself yields the below.

 user@icebox:~$ readelf -S /lib/tls/i686/cmov/libc-2.3.6.so | head -n 6
 There are 64 section headers, starting at offset 0x12d114:
 
 Section Headers:
   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
   [ 1] .note.ABI-tag     NOTE            4df2e154 000154 000020 00   A  0   0  4

Computing 4df2e154 - 154, the address and offset taken from any given non-NULL segment, yields 4df2e000, the base address of libc. This makes sense; prelink rewrites the segment and symbol addresses for the library based on a specific load address, and the dynamic linker loads the library at that address to avoid relocating it. Further, any program that links with libc has to be able to read libc, and will thus be able to derive the same information.

All of this means that any program on the system using any prelinked library will be able to leak information about higher privileged tasks using the same library. This allows any attacker able to gain any form of local access—or more directly any ability to read libc—to gain information about the address space layout of higher privileged processes, including the load address of libc. As we know, this information is extremely valuable to an attacker wanting to exploit a privileged process without brute forcing library load addresses.

This vulnerability only applies to attackers with local access; but this is not an unreasonable requirement. Many web hosting companies give local shell access or allow PHP; either of these can be used to remotely fetch a copy of libc. Due to the nature of the dynamic linker and sane security design, the dynamic linker is exactly as privileged as the process it is starting; therefor, even the most stringent mandatory access policies on systems such as SELinux, grsecurity, or AppArmor cannot prevent this attack.

Besides avoiding prelinking, there is one other way to prevent this information leak from being exploited. All processes linked to a prelinked library need access to the library file and load that library at the same address; the point of exposure is the use of the same copy of the library. In order to prevent information leaking, then, you must have separate copy of each library common between any two programs you don't want to leak information about each other. This can be done with Xen, chroot jails, UML, or simply isolated machines, as long as the directory hierarchies are individually prelinked with prelink randomization. Each system will have a different set of addresses from every other system in this scheme. This of course requires more hardware, more disk space, more management, more memory, and more work.

The direct implications of this information leak depend on your exact security concerns. A web hosting company, for example, may not want to run prelink on its servers, given the risk of effectively losing the benefit of address space randomization. A home desktop, on the other hand, may only have to worry about a trojan using the information leak to stage an attack on a system service such as cups or dbus—and should probably worry about /proc/PID/maps first. While these are both essentially the concern of an attacker with local access, the likelihood of attack and the value of potential damages are different.

The prelink tool gives a useful decrease in program load time, and can help users reach their desktop and the programs they need to run more quickly. It does however have some unfortunate repercussions that must be examined, especially in security-sensitive environments relying on address space randomization.

Comments (16 posted)

New vulnerabilities

acroread: unspecified security problems

Package(s):

acroread

CVE #(s):

CVE-2006-3093

Created:

July 4, 2006

Updated:

July 5, 2006

Description:

Various unspecified security problems have been fixed in Acrobat Reader version 7.0.8. Adobe does not provide detailed information about the nature of the security problems. Therefore, it is necessary to assume that remote code execution is possible.

Alerts:

SuSE

SUSE-SA:2006:041

2006-07-04

Comments (1 posted)

kernel: denial of service

Package(s):

kernel

CVE #(s):

CVE-2006-2934

Created:

July 5, 2006

Updated:

July 7, 2006

Description:

The netfilter SCTP connection tracking code can crash when faced with a "packet without chunks." This vulnerability was fixed in the 2.6.17.3 kernel release.

Alerts:

Trustix	TSLSA-2006-0040	2006-07-07
Fedora	FEDORA-2006-772	2006-07-05
Fedora	FEDORA-2006-769	2006-07-05

LWN.net Weekly Edition for July 6, 2006

acroread: unspecified security problems

kernel: denial of service

kiax: arbitrary code execution

openoffice.org: several vulnerabilities

opera: integer overflow and SSL spoof

tikiwiki: multiple vulnerabilities

asterisk: buffer overflow

binutils: buffer overflow

busybox: insecure password generation

bzip2: race condition and infinite loop

ktools: buffer overflow

courier: denial of service

cpio: arbitrary code execution

vixie-cron: privilege escalation

cscope: buffer overflows

Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service

EnergyMech: denial of service

freetype: integer overflows

gdb: multiple vulnerabilities

gdm: improper file permissions

gedit: format string vulnerability

gnupg: remote denial of service

grip: buffer overflow

gzip: arbitrary command execution

Hashcash: possible heap overflow

horde: missing input sanitizing

ImageMagick: heap overflow vulnerability

kdebase: local root vulnerability

kdebase: privilege escalation

kdelibs: kate backup file permission leak

kernel: multiple vulnerabilities

kernel: netfilter memory corruption

kernel: multiple vulnerabilities

kernel: information disclosure

libgadu: memory alignment bug

libgd2: denial of service

libmms: buffer overflows

libpam-ldap: authentication bypass

libpng: heap based buffer overflow

libtiff: buffer overflow

libxml2 - arbitrary code execution

libxml2: multiple buffer overflows

lynx: arbitrary command execution

mozilla products have multiple vulnerabilities

mpg123: buffer overflows

mutt: IMAP namespace buffer overflow

mysql: denial of service

MySQL: logging bypass

nbd: arbitrary code execution

ntp: uses wrong gid

openmotif: buffer overflows

OpenSSH: double shell expansion

shadow: privilege escalation

perl: setuid vulnerabilities

php: multiple vulnerabilities

phpbb2: missing input sanitizing

phpbb2: multiple vulnerabilities

phpMyAdmin: multiple vulnerabilities

pinball: privilege escalation

png: buffer overflow

postgresql: SQL injection

ppp: privilege escalation

Py2Play: remote execution of arbitrary Python code

quagga: multiple vulnerabilities

quake: buffer overflow

scorched3d: multiple vulnerabilities

sendmail: denial of service

shadow-utils: mailbox creation vulnerability

squirrelmail: file inclusion vulnerability

sudo: vulnerability via scripts

texinfo: temporary file vulnerability

tin: buffer overflow

unzip: long file name buffer overflow

w3c-libwww: possible stack overflow

xine-lib: buffer overflow

xine-lib: buffer overflow

xine-ui: format string vulnerabilities

X.Org: buffer overflow

xpdf: buffer overflow