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: |
|
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: |
|
Comments (none posted)
kiax: arbitrary code execution
| Package(s): | kiax |
CVE #(s): | CVE-2006-2923
|
| Created: | June 30, 2006 |
Updated: | July 5, 2006 |
| Description: |
The iax_net_read function in the iaxclient library fails to properly
handle IAX2 packets with truncated full frames or mini-frames. These
frames are detected in a length check but processed anyway, leading to
buffer overflows. |
| Alerts: |
|
Comments (none posted)
openoffice.org: several vulnerabilities
| Package(s): | openoffice.org |
CVE #(s): | CVE-2006-2198
CVE-2006-2199
CVE-2006-3117
|
| Created: | June 30, 2006 |
Updated: | January 4, 2007 |
| Description: |
Several vulnerabilities have been discovered in OpenOffice.org, a free
office suite.
- It turned out to be possible to embed arbitrary BASIC macros in
documents in a way that OpenOffice.org does not see them but executes them
anyway without any user interaction. (CVE-2006-2198)
- It is possible to evade the Java sandbox with specially crafted Java
applets. (CVE-2006-2199)
- Loading malformed XML documents can cause buffer overflows and cause a
denial of service or execute arbitrary code. (CVE-2006-3117)
|
| Alerts: |
|
Comments (none posted)
opera: integer overflow and SSL spoof
| Package(s): | opera |
CVE #(s): | CVE-2006-3198
CVE-2006-3331
|
| Created: | July 3, 2006 |
Updated: | July 5, 2006 |
| Description: |
Opera before version 9.0 has an integer overflow vulnerability due to the
improper handling of JPEG files. Also Opera did not reset the SSL security
bar after displaying a download dialog from an SSL-enabled website, which
could allow remote attackers to spoof a trusted SSL certificate from an
untrusted website and facilitate phishing attacks. |
| Alerts: |
|
Comments (none posted)
tikiwiki: multiple vulnerabilities
| Package(s): | tikiwiki |
CVE #(s): | CVE-2006-3048
CVE-2006-3047
|
| Created: | June 29, 2006 |
Updated: | July 5, 2006 |
| Description: |
The Tikiwiki content management system has an SQL injection
vulnerability due to insufficient input sanitization.
An attacker may be able to execute arbitrary SQL statements
or inject arbitrary scripts into the user's browser.
|
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
asterisk: buffer overflow
| Package(s): | asterisk |
CVE #(s): | CVE-2006-2898
|
| Created: | June 15, 2006 |
Updated: | July 27, 2006 |
| Description: |
The Asterisk PBX application has a buffer overflow vulnerability in the
IAX2 channel driver that can be used for the remote execution of
arbitrary code.
|
| Alerts: |
|
Comments (none posted)
binutils: buffer overflow
| Package(s): | binutils |
CVE #(s): | CVE-2006-2362
|
| Created: | May 27, 2006 |
Updated: | August 29, 2006 |
| Description: |
The GNU Binutils has a buffer overflow vulnerability in libbfd.
Maliciously crafted Tektronix Hex Format files with improper length
characters can cause a crash and possibly lead to the execution of
arbitrary code. |
| Alerts: |
|
Comments (none posted)
busybox: insecure password generation
| Package(s): | busybox |
CVE #(s): | CVE-2006-1058
|
| Created: | May 5, 2006 |
Updated: | May 2, 2007 |
| Description: |
The BusyBox 1.1.1 passwd command does not use a proper salt when generating
passwords. This would create an instance where a brute force attack could
take very little time. |
| Alerts: |
|
Comments (2 posted)
bzip2: race condition and infinite loop
| Package(s): | bzip2 |
CVE #(s): | CAN-2005-0953
CAN-2005-1260
|
| Created: | May 17, 2005 |
Updated: | January 10, 2007 |
| Description: |
A race condition in bzip2 1.0.2 and earlier allows local users to modify
permissions of arbitrary files via a hard link attack on a file while it is
being decompressed, whose permissions are changed by bzip2 after the
decompression is complete. Also specially crafted bzip2 archives may cause
an infinite loop in the decompressor. |
| Alerts: |
|
Comments (2 posted)
ktools: buffer overflow
| Package(s): | centericq |
CVE #(s): | CVE-2005-3863
|
| Created: | December 7, 2005 |
Updated: | August 29, 2006 |
| Description: |
From the Debian-Testing alert: Mehdi Oudad "deepfear" and Kevin Fernandez "Siegfried" from the Zone-H
Research Team discovered a buffer overflow in kkstrtext.h of the ktools
library, which is included in (at least) centericq and motor. |
| Alerts: |
|
Comments (none posted)
courier: denial of service
| Package(s): | courier |
CVE #(s): | CVE-2006-2659
|
| Created: | June 9, 2006 |
Updated: | August 4, 2006 |
| Description: |
A denial of service vulnerability has been found in the function for
encoding email addresses. Addresses containing a '=' before the '@'
character caused the Courier to hang in an endless loop, rendering the
service unusable. |
| Alerts: |
|
Comments (none posted)
cpio: arbitrary code execution
| Package(s): | cpio |
CVE #(s): | CVE-2005-4268
|
| Created: | January 2, 2006 |
Updated: | May 8, 2007 |
| Description: |
Richard Harms discovered that cpio did not sufficiently validate file
properties when creating archives. Files with e. g. a very large size
caused a buffer overflow. By tricking a user or an automatic backup
system into putting a specially crafted file into a cpio archive, a
local attacker could probably exploit this to execute arbitrary code
with the privileges of the target user (which is likely root in an
automatic backup system). |
| Alerts: |
|
Comments (none posted)
vixie-cron: privilege escalation
| Package(s): | cron |
CVE #(s): | CVE-2006-2607
|
| Created: | May 31, 2006 |
Updated: | July 13, 2006 |
| Description: |
The Vixie cron daemon does not check the return code from setuid(); if that call can be made to fail, a local attacker may be able to execute commands as root. |
| Alerts: |
|
Comments (1 posted)
Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service
| Package(s): | cyrus-sasl |
CVE #(s): | CVE-2006-1721
|
| Created: | April 21, 2006 |
Updated: | September 4, 2007 |
| Description: |
Cyrus-SASL contains an unspecified vulnerability in the DIGEST-MD5
process that could lead to a Denial of Service. An attacker could possibly
exploit this vulnerability by sending specially crafted data stream to the
Cyrus-SASL server, resulting in a Denial of Service even if the attacker is
not able to authenticate. |
| Alerts: |
|
Comments (none posted)
EnergyMech: denial of service
| Package(s): | emech |
CVE #(s): | |
| Created: | June 27, 2006 |
Updated: | June 28, 2006 |
| Description: |
A bug in EnergyMech fails to handle empty CTCP NOTICEs correctly, and
will cause a crash from a segmentation fault. By sending an empty CTCP
NOTICE, a remote attacker could exploit this vulnerability to cause a
denial of service. |
| Alerts: |
|
Comments (none posted)
freetype: integer overflows
| Package(s): | freetype |
CVE #(s): | CVE-2006-0747
CVE-2006-1861
CVE-2006-2493
CVE-2006-2661
CVE-2006-3467
|
| Created: | June 8, 2006 |
Updated: | October 10, 2007 |
| Description: |
The FreeType library has several integer overflow vulnerabilities.
If a user can be tricked into installing a specially
crafted font file, arbitrary code can be executed with the privilege
of the user. |
| Alerts: |
|
Comments (none posted)
gdb: multiple vulnerabilities
| Package(s): | gdb |
CVE #(s): | CAN-2005-1704
CAN-2005-1705
|
| Created: | May 20, 2005 |
Updated: | August 11, 2006 |
| Description: |
Tavis Ormandy of the Gentoo Linux Security Audit Team discovered an integer
overflow in the BFD library, resulting in a heap overflow. A review also
showed that by default, gdb insecurely sources initialization files from
the working directory. Successful exploitation would result in the
execution of arbitrary code on loading a specially crafted object file or
the execution of arbitrary commands. |
| Alerts: |
|
Comments (5 posted)
gdm: improper file permissions
| Package(s): | gdm |
CVE #(s): | CVE-2006-1057
|
| Created: | April 19, 2006 |
Updated: | May 2, 2007 |
| Description: |
The .ICEauthority file may be created with the wrong ownership and permissions; gdm 2.14.2 fixes the problem. |
| Alerts: |
|
Comments (none posted)
gnupg: remote denial of service
| Package(s): | gnupg |
CVE #(s): | CVE-2006-3082
|
| Created: | June 21, 2006 |
Updated: | July 28, 2006 |
| Description: |
A vulnerability was discovered in GnuPG 1.4.3 and 1.9.20 (and earlier) that
could allow a remote attacker to cause gpg to crash and possibly overwrite
memory via a message packet with a large length. |
| Alerts: |
|
Comments (1 posted)
gzip: arbitrary command execution
| Package(s): | gzip |
CVE #(s): | CAN-2005-0758
|
| Created: | August 1, 2005 |
Updated: | January 9, 2007 |
| Description: |
zgrep in gzip before 1.3.5 does not handle shell metacharacters like '|'
and '&' properly when they occurred in input file names. This could be
exploited to execute arbitrary commands with user privileges if zgrep is
run in an untrusted directory with specially crafted file names. |
| Alerts: |
|
Comments (2 posted)
Hashcash: possible heap overflow
| Package(s): | hashcash |
CVE #(s): | CVE-2006-3251
|
| Created: | June 27, 2006 |
Updated: | July 21, 2006 |
| Description: |
Andreas Seltenreich has reported a possible heap overflow in the
array_push() function in hashcash.c, as a result of an incorrect amount
of allocated memory for the "ARRAY" structure. |
| Alerts: |
|
Comments (none posted)
horde: missing input sanitizing
| Package(s): | horde |
CVE #(s): | CVE-2006-2195
|
| Created: | June 15, 2006 |
Updated: | June 29, 2006 |
| Description: |
The Horde3 web application framework does not perform sufficient
input sanitizing, allowing the possible injection of web
script code through a cross-site scripting attack. |
| Alerts: |
|
Comments (none posted)
ImageMagick: heap overflow vulnerability
| Package(s): | ImageMagick |
CVE #(s): | CVE-2006-2440
|
| Created: | May 25, 2006 |
Updated: | September 5, 2006 |
| Description: |
The ImageMagick DisplayImageCommand has a heap overflow vulnerability.
If an maliciously created unexpanded glob is passed to ImageMagick,
a heap overflow can result. |
| Alerts: |
|
Comments (none posted)
kdebase: local root vulnerability
| Package(s): | kdebase |
CVE #(s): | CAN-2005-2494
|
| Created: | September 7, 2005 |
Updated: | August 11, 2006 |
| Description: |
The kdebase package (and kcheckpass in particular) found in KDE versions 3.2.0 through 3.4.2 suffers from a lock file handling error which can enable a local attacker to obtain root access. See this advisory for details. |
| Alerts: |
|
Comments (none posted)
kdebase: privilege escalation
| Package(s): | kdebase |
CVE #(s): | CVE-2006-2449
|
| Created: | June 15, 2006 |
Updated: | August 28, 2006 |
| Description: |
The KDE Display Manager(KDM) is vulnerable to a local symlink attack.
A local user can use this to read arbitrary files that they do not
have permission to access. See this KDE
advisory for more information. |
| Alerts: |
|
Comments (none posted)
kdelibs: kate backup file permission leak
| Package(s): | kdelibs kate kwrite |
CVE #(s): | CAN-2005-1920
|
| Created: | July 19, 2005 |
Updated: | November 27, 2006 |
| Description: |
Kate / Kwrite, as shipped with KDE 3.2.x up to including 3.4.0, creates a file backup before saving a modified file. These backup files are created with default permissions, even if the original file had more strict permissions set. See this advisory for more information. |
| Alerts: |
|
Comments (none posted)
kernel: multiple vulnerabilities
| Package(s): | kernel |
CVE #(s): | CVE-2006-2271
CVE-2006-2272
CVE-2006-2274
CVE-2006-2275
CVE-2006-1864
|
| Created: | May 12, 2006 |
Updated: | July 13, 2006 |
| Description: |
Multiple vulnerabilities in the Linux have been found.
- An error in the Stream Control Transmission Protocol (SCTP) code that
uses incorrect state table entries when certain ECNE chunks are received in
CLOSED state, could be exploited by attackers to cause a kernel panic via a
specially crafted packet.
- An error exist when handling incoming IP-fragmented SCTP control
chunks, which could be exploited by attackers to cause a kernel panic via a
specially crafted packet.
- Linux SCTP (lksctp) allows remote attackers to cause a denial of
service (infinite recursion and crash) via a packet that contains two or
more DATA fragments, which causes an skb pointer to refer back to itself
when the full message is reassembled, leading to infinite recursion in the
sctp_skb_pull function
- Linux SCTP (lksctp) allows remote attackers to cause a denial of
service (deadlock) via a large number of small messages to a receiver
application that cannot process the messages quickly enough, which leads to
"spillover of the receive buffer."
- A vulnerability has been identified due to an input validation error
when processing arguments containing backslash ("\\") characters passed to
certain commands (e.g. "cd"), which could be exploited by authenticated
attackers to escape chroot restrictions for a CIFS or SMBFS mounted
filesystem.
|
| Alerts: |
|
Comments (none posted)
kernel: netfilter memory corruption
| Package(s): | kernel |
CVE #(s): | CVE-2006-2444
|
| Created: | May 25, 2006 |
Updated: | July 5, 2006 |
| Description: |
The 2.6.12 kernel has a remote memory corruption vulnerability
that can be remotely triggered by loading the ip_nat_snmp_basic
module and traffic is network-translated on port 161 or 162. |
| Alerts: |
|
Comments (none posted)
kernel: multiple vulnerabilities
| Package(s): | kernel |
CVE #(s): | CVE-2006-2445
CVE-2006-2448
CVE-2006-3085
|
| Created: | June 23, 2006 |
Updated: | August 11, 2006 |
| Description: |
There is a race condition error in the "posix-cpu-timers.c" script that
does not prevent another CPU from attaching the timer to an exiting
process. This could be exploited by attackers to cause a denial of
service.
A flaw due to errors in "powerpc/kernel/signal_32.c" and
"powerpc/kernel/signal_32.c" could allow userspace to provoke a machine
check on 32-bit kernels.
An infinite loop in "netfilter/xt_sctp.c" could be exploited by attackers
to exhaust all available memory resources, creating a denial of service
condition. |
| Alerts: |
|
Comments (none posted)
kernel: information disclosure
| Package(s): | kernel |
CVE #(s): | CVE-2006-1343
|
| Created: | May 31, 2006 |
Updated: | July 20, 2006 |
| Description: |
The 2.6 kernel netfilter code contains an information leak; this vulnerability has been fixed in the 2.6.16.19 release. |
| Alerts: |
|
Comments (none posted)
libgadu: memory alignment bug
| Package(s): | libgadu |
CVE #(s): | CAN-2005-2370
|
| Created: | July 29, 2005 |
Updated: | June 25, 2007 |
| Description: |
Szymon Zygmunt and Michal Bartoszkiewicz discovered a memory alignment
error in libgadu (from ekg, console Gadu Gadu client, an instant
messaging program) which is included in gaim, a multi-protocol instant
messaging client, as well. This can not be exploited on the x86
architecture but on others, e.g. on Sparc and lead to a bus error,
in other words a denial of service.
|
| Alerts: |
|
Comments (none posted)
libgd2: denial of service
| Package(s): | libgd2 |
CVE #(s): | CVE-2006-2906
|
| Created: | June 14, 2006 |
Updated: | January 16, 2007 |
| Description: |
Certain GIF images can cause libgd2 to go into an infinite loop, adversely affecting the performance of image processing applications. |
| Alerts: |
|
Comments (none posted)
libmms: buffer overflows
| Package(s): | libmms |
CVE #(s): | CVE-2006-2200
|
| Created: | July 6, 2006 |
Updated: | December 25, 2006 |
| Description: |
Several buffer overflows were found in libmms. By tricking a user into
opening a specially crafted remote multimedia stream with an application
using libmms, a remote attacker could overwrite an arbitrary memory portion
with zeros, thereby crashing the program. |
| Alerts: |
|
Comments (none posted)
libpam-ldap: authentication bypass
| Package(s): | libpam-ldap |
CVE #(s): | CAN-2005-2641
|
| Created: | August 25, 2005 |
Updated: | October 6, 2006 |
| Description: |
libpam-ldap, the PAM LDAP interface, has a vulnerability in which
it fails to authenticate with an LDAP server which is not configured
properly, allowing an authentication bypass. |
| Alerts: |
|
Comments (none posted)
libtiff: buffer overflow
| Package(s): | libtiff |
CVE #(s): | CVE-2006-2193
|
| Created: | June 15, 2006 |
Updated: | September 1, 2008 |
| Description: |
The t2p_write_pdf_string function in libtiff 3.8.2 and earlier is vulnerable
to a buffer overflow. Attackers can use a TIFF file with UTF-8 characters
in the DocumentName tag to overflow a buffer, causing a denial of service,
and possibly the execution of arbitrary code. |
| Alerts: |
|
Comments (none posted)
mozilla products have multiple vulnerabilities
Comments (none posted)
mpg123: buffer overflows
| Package(s): | mpg123 |
CVE #(s): | CVE-2006-1655
|
| Created: | May 24, 2006 |
Updated: | July 3, 2006 |
| Description: |
mpg123 does not properly validate MPEG 2.0 layer 3 files, leading to a number of buffer overflow vulnerabilities. |
| Alerts: |
|
Comments (none posted)
mutt: IMAP namespace buffer overflow
| Package(s): | mutt |
CVE #(s): | CVE-2006-3242
|
| Created: | June 28, 2006 |
Updated: | October 24, 2006 |
| Description: |
TAKAHASHI Tamotsu discovered that mutt's IMAP backend did not sufficiently
check the validity of namespace strings. If an user connects to a malicious
IMAP server, that server could exploit this to crash mutt or even execute
arbitrary code with the privileges of the mutt user. See this Secunia advisory for more
information. |
| Alerts: |
|
Comments (none posted)
mysql: denial of service
| Package(s): | mysql |
CVE #(s): | CVE-2006-3081
|
| Created: | June 23, 2006 |
Updated: | July 18, 2006 |
| Description: |
Mysqld in MySQL 4.1.x before 4.1.18, 5.0.x before 5.0.19, and 5.1.x before
5.1.6 allows remote authorized users to cause a denial of service (crash)
via a NULL second argument to the str_to_date function. |
| Alerts: |
|
Comments (none posted)
MySQL: logging bypass
| Package(s): | mysql |
CVE #(s): | CVE-2006-0903
|
| Created: | April 4, 2006 |
Updated: | May 21, 2008 |
| Description: |
MySQL 5.0.18 and earlier allows local users to bypass logging mechanisms
via SQL queries that contain the NULL character, which are not properly
handled by the mysql_real_query function. NOTE: this issue was originally
reported for the mysql_query function, but the vendor states that since
mysql_query expects a null character, this is not an issue for mysql_query. |
| Alerts: |
|
Comments (2 posted)
ntp: uses wrong gid
| Package(s): | ntp |
CVE #(s): | CAN-2005-2496
|
| Created: | August 26, 2005 |
Updated: | August 11, 2006 |
| Description: |
When starting xntpd with the -u option and specifying the
group by using a string not a numeric gid the daemon uses
the gid of the user not the group. This problem is now fixed
by this update. |
| Alerts: |