Bitfrost: the OLPC security model
The One Laptop Per Child platform was always going to present some
interesting security challenges. Millions of identical, network-attached
systems will be deployed into some remote parts of the world, where they
will be managed by people who are not security experts. The systems will
be obvious targets for theft, self-propagating malware, and the creation of
botnets. None of these activities feature highly on the OLPC project's
list of educational objectives, so it stands to reason that some
significant thought needs to go into how to prevent them.
The person charged with the OLPC's security thinking is Ivan Krstić. The
initial results of his work, done with help from Simson Garfinkel, have now
been posted with a request
for comments. Ivan and company have come up with a platform named
"Bitfrost," which, it is hoped, will keep OLPC systems out of trouble and
available for their owners. At this point, there is quite a bit of
information on what Bitfrost will do, but very little on how it will be
implemented.
After an introduction on the shortcomings of the traditional Unix file
permissions model, the Bitfrost specification gets into the overriding
principles and goals. The principles are consistent with the approach the
OLPC project has taken so far: security cannot depend on hardware or
software design secrets, it must be possible for users to gain complete
control over the system, security cannot depend on the user being able to
read, and the security mechanism must be unobtrusive. "Unobtrusive" does
not mean that security won't ever get in the way; instead, it means that
the user will not be pestered by popups with security-related questions.
The associated goals include no user passwords, no unencrypted
authentication, a system which is secure when it is first powered on, a
very limited use of public-key encryption infrastructure, and no permanent
data loss.
The process starts at manufacturing time, when each laptop will be equipped
with unique, randomly-generated serial and UUID numbers. The laptop starts
out in a non-functional, deactivated state; making it work involves the use
of a special activation key generated from the serial number and UUID.
The customer countries will have lists of serial and UUID numbers; from
those it will be able to create the activation keys. The plan is for these
keys to be generated in small batches and shipped, on a USB key, to the
destination schools. Once installed on a server there, the keys can be
used to enable the laptops sent specifically to that school. The purpose
here is to deter thieves who would grab pallets of laptops; without the
activation keys, those laptops would only be useful as spare parts.
There is an interesting step which happens once a laptop is activated and
booted:
On first boot, a program is run that asks the child for their name,
takes their picture, and in the background generates an ECC key
pair. The key pair is initially not protected by a passphrase, and
is then used to sign the child's name and picture. This information
and the signature are the child's 'digital identity'.
The laptop transmits the (SN, UUID, digital identity) tuple to the
activation server. The mapping between a laptop and the user's
identity is maintained by the country or regional authority for
anti-theft purposes, but never reaches OLPC.
The ability to locate the proper owner of an OLPC system has obvious
advantages; it should help to keep each laptop in the proper set of small
hands. On the other hand, the potential for a repressive government to
misuse this data seems real; it would be sad if the OLPC systems could not
be used for truly free communications without fear about who might be
listening.
At the BIOS level, security will be handled as described in this LWN article from last
August. The BIOS will only be rewritable when the new image has been
signed with a special cryptographic key. There will be "developer keys"
available which will enable a laptop's owner to reflash the BIOS, but, in
general, the children will not have that functionality available to them.
At the Linux level, security will be handled through a set of privileges
assigned to each installed program. Privileges look much like Linux
capabilities, but they are not capabilities; they are a new layer of
protections which will be implemented via some other means. Some of the
expected privileges will include:
- P_SF_CORE: the ability to modify the core software on the
system. This privilege is normally off, and cannot be enabled without
a special developer key. There is also P_SF_RUN, which
allows modification of the currently-running system software. This
privilege works by way of a copy-on-write filesystem mechanism;
software changes are saved as copies. This mechanism makes it easy to
revert the system to its initial state should the need arise.
- P_NET: a group of controls on network access. Programs can
be denied access to the net entirely, or they can have any of a wide
range of bandwidth, time-of-day, and destination restrictions applied
to them.
- P_MIC_CAM: programs can be granted (or denied) the ability to
use the camera and the microphone. There will also be LEDs (not
present on the current test systems) which will illuminate whenever
the camera or microphone are in use. So it should be difficult to use
an OLPC system to spy on its owner.
- There is a whole set of quotas designed to prevent a program from
using too much processor time, flash space, etc.
In addition, every program will be run in an isolated mode:
A program on the XO starts in a fortified chroot, akin to a BSD
jail, where its visible filesystem root is only its own constrained
scratch space. It normally has no access to system paths such as
/proc or /sys, cannot see other programs on the system or their
scratch spaces, and only the libraries it needs are mapped into its
scratch space. It cannot access user documents directly, but only
through the file store service, explained in the next section.
Again, details on just how the sandbox will be implemented are scarce for
now - though your editor has heard from Mr. Krstić that it will be
based on Linux-VServer.
The "file store service" is described as a sort of object-oriented
database for documents, "similar in very broad terms to the Microsoft
WinFS design". All access to files from programs goes by way of a
user dialog; there should be no way for a program to modify files outside
of its own scratch area without the user knowing about it.
There is also an optional anti-theft mechanism:
It works by running, as a privileged process that cannot be
disabled or terminated even by the root user, an anti-theft daemon
which detects Internet access, and performs a call-home request --
no more than once a day -- to the country's anti-theft servers. In
so doing, it is able to securely use NTP to set the machine RTC to
the current time, and then obtain a cryptographic lease to keep
running for some amount of time, e.g. 21 days. The lease duration
is controlled by each country.
If a machine has been reported as stolen, the "anti-theft server" will
instruct it to shut down hard and go back into the deactivated state. The
same thing will happen eventually if the stolen system is kept isolated
from the net. This mechanism should help to deter thefts; one can only
hope that it is sufficiently well designed that nobody figures out how to
trigger it as a denial of service attack.
The phone-home feature can be disabled - but only in the presence of
a developer key.
One feature which will not be built into the laptops is filesystem
encryption. The CPU in the OLPC XO laptop is simply too slow to perform
that task without bogging down the system entirely. This issue will be
reconsidered in the future. The OLPC developers have also explicitly
decided to stay out of the content-filtering business.
In summary, the security model developers have this to say:
[W]e believe we've imbued the OLPC security system with cunning and
more magic art than other similar works of craftmanship -- but not
for a second do we believe we've designed something that cannot be
broken when talented, determined and resourceful attackers go forth
harrying. Indeed, this was not the goal. The goal was to
significantly raise the bar from the current, deeply
unsatisfactory, state of desktop security.
If the implementation lives up to the specification, chances are that the
project will have achieved that goal. The OLPC platform is an ambitious
experiment from beginning to end, and its developers have, once again, not
wasted the opportunity to do something interesting with it. If the
security ideas incorporated into the OLPC systems work out as desired, it
would not be surprising to see at least some of them adopted by other
desktop environments. This could be another case where the OLPC project
creates benefits for a large group of people beyond its immediate target.
Comments (61 posted)
Comparing Linux and Minix
Toward the end of
his
linux.conf.au talk, Andrew Tannenbaum put up a few slides on the
runtime cost of the microkernel approach. He had quite a few benchmarks,
but the bottom line was that the microkernel architecture
used in Minix imposed a roughly 5-10% performance penalty, depending on
what one is trying to do. While operating systems hackers would normally
cringe at the prospect of paying a 5% penalty, to many people this could
seem like a good deal: give up 5-10% of a processor which is mostly idle
anyway in exchange for a more reliable system.
In truth, neither the claim of a 5-10% penalty nor that of higher
reliability has been proved in any definitive way. At the conference,
a number of attendees questioned the way in which the benchmarks had been
done, suspecting that Minix had been benchmarked against a monolithic
version of itself. If that is the case, the benchmarks will capture the
context switching costs but will have nothing to say about the costs of the
message-passing architecture. To get a true measure of the penalty of
the microkernel architecture, it was suggested, one should benchmark Minix
against Linux.
As it turns out, the linux.conf.au swag bag contained a CD with Minix 3.1.2a
on it; one might almost think the organizers had this sort of test in mind.
So your editor came home with the intention of installing that version of
Minix and doing a bit of benchmarking. That job has now been done, and we
can talk about how Minix and Linux compare.
Time for a brief digression:
once, some years ago, your editor actually had a spare moment in which to
see how nethack was coming along. One must stay on top of all the
important development projects, after all. The graphics have improved, the
game contained more monsters than ever, etc. But there is an especially
amusing moment when one drops into a level and is informed of a sense of
having entered a more primitive place. The graphics on that level are
straight from
VAX-era rogue, and the whole thing feels rough and, well, primitive.
A similar feeling will come over a Linux user who tries to get things done
on a Minix system. It is a POSIX-like environment, and it has a working version
of the X Window system (but don't go in expecting GNOME or KDE), but that's
as far as it goes. The
shell is painful to use, many commands are
missing, and one runs into obstacles on every path. Since Minix
does not really do paging, memory quickly runs out if too many processes
are run; your editor had not seen the old "not enough core" message in
quite some time. One of the harder things to do on Minix, it turns out, is
to build any sort of non-trivial software package - even after figuring out
that the default C compiler is crippled but gcc can be found under
/usr/gnu. As a result, your editor had to give up on most of his
attempts to build current benchmarks; they just would not compile on Minix.
In the end, your editor succeeded in building and running two benchmark
programs: IOtest and UnixBench. Neither seems to be recent enough to have
a currently-maintained web page. IOtest is a disk exerciser, evidently
intended originally as a tool for driver developers. It's
useful for exercising drives in a serious way;
it also produces performance numbers on the side. UnixBench was developed
by Byte in the 1990's, and hasn't seen a whole lot of work since. It
remains, however, a useful way to get a snapshot of the relative speeds of
many operating system functions.
The benchmarks were run on an AMD Athlon 1700 system using an unremarkable
ATA disk. There are three partitions on the disk: one for the operating
system, one for swap (Linux only, since Minix does not support it), and one
for destructive disk tests. The partitioning was not changed between the
installations. Minix does not support partitions larger than 4GB (who
could ever need more than that?) so the disk tests were restricted to 4GB
on both systems. The Minix tests were done on a full installation of Minix
3.1.2a; the Linux side was represented by a late-September
Debian Etch snapshot running a 2.6.17 kernel.
The IOtest read test simply performs random reads of varying sizes,
starting with one process and going up from there. IOtest can run a large
number of competing processes, but your editor limited it to four so as to
avoid running into Minix's memory limitations. For the curious, the full Minix results and Linux results are available. The bottom line
is that the results are nearly comparable: for all practical purposes, the
two systems performed about the same. Similar things can be said about the
results (Minix, Linux) of the read/write test, which are
summarized in the plot to the right (the dashed line represents Minix).
Comparable results would be expected with a benchmark like this, since it
will be dominated by the drive's seek performance. The portion of the disk
being exercised (only 4GB, remember) was not enough to demonstrate a
difference in I/O scheduler implementations. The disk never comes near its
peak I/O rate. So the main conclusion to draw from these results is that
Minix does not get terribly in the way.
The UnixBench results (raw results: Minix, Linux) paint a rather different
picture. These results are summarized in the plot to the left; the upper
bar for each test represents Linux.
The measured system call overhead for Minix is a full ten times
higher than the value for Linux. The file copy tests ran between two and
ten times faster on Linux. Pipe throughput differed by a factor of seven;
Minix was 140 times slower at process creation. The difference in shell
script execution performance, however, was 1.4 - in Minix's favor. One
assumes that the rather simple shell provided by Minix is, at least, faster
than bash.
One can argue that Minix is a new and unfinished system which has not, yet,
had the benefit of a great deal of performance tuning. There is doubtless
some merit to that claim; the Minix folks will probably find a number of
ways to make things faster. On the other hand, it would not be
unreasonable to argue that Linux, by supporting much greater functionality
on a far wider range of hardware, has every right to be slower - but it's
not. Linux is quite a bit faster; the Minix folks certainly ran benchmarks
which showed a 5-10% difference, but they were not benchmarking against
Linux.
Dr. Tanenbaum made the claim that only a computer geek would accept better
performance if that trade brought with it lower reliability. By that
reasoning, it doesn't matter that Minix is much slower than Linux on the
same hardware; Minix is aiming for a different goal. But people do care
about performance; the fact that Dr. Tanenbaum felt the need to put up
benchmark results suggests that he cares too. Trading some performance for
reliability could well be a good deal. When one compares Minix (in its
current state) to Linux, however, the performance difference is large, and
the increased reliability is unproven.
Comments (85 posted)
Reader survey followup
Last week's reader survey drew just about 1000
responses -
approximately 25% of our entire subscriber base. We appreciate the time
you all took to tell us what you think about LWN. Fully digesting the
responses will take some time, but there are a few things which jump out
quickly.
About 90% of those who responded were individual subscribers. As it
happens, almost 25% of LWN subscribers get their access through group
subscriptions, but fewer of them took the time to respond. Perhaps people
on group subscriptions tend to be more busy, or perhaps fewer of them
follow LWN every week. In any case, the opinions of group subscribers
were somewhat underrepresented.
A full 50% of the responses came from Europe, compared to 39% from North
America and 5% from Australia and New Zealand. It has been a while since
we had accurate statistics of where our readers are coming from - the
current LWN server isn't up to the task of recording all that information.
Once upon a time, North Americans and Europeans made up approximately equal
parts of our reader base. It would be interesting if the Europeans have
now pulled ahead.
There were few surprises in the responses on which parts of LWN readers
enjoy the most. It seems maybe we'll have to keep the Kernel Page after
all. Seriously, though, the most interesting result may have been the
relatively low scores given to the weekly Announcements Page. One of the
things we have noticed over the years is that a surprising number of items
from that page end up being mentioned in the annual LWN timeline feature.
Important stuff goes on that page, but it is currently set up as a sort of dumping
ground at the very end of the Weekly Edition. Some changes may be called
for there.
Quite a few readers were surprised to discover the index of kernel articles. The
index was prominently announced on the Kernel Page when it was created, and
it's linked at the top of the kernel
subsection page. But, clearly, it is not easy enough for people to
find.
More generally,
a number of respondents suggested that the time has come for a site
redesign. Trust us, we know that. The current design is mostly unchanged
since its unveiling in June, 2002, but it really dates back to January,
1998, when LWN first hit the net. Our purpose was to create a clean,
easy-to-read, text-oriented site, and the result has served us well for
some time. But it is definitely time to rethink things. That will be a
slow process, however.
Complaining about comment quality has been a popular activity in recent
times, but there was not a great deal of interest in either of the proposed
comment filtering mechanisms. A few readers really do want a blacklisting
capability, though. Instead, there were a number of requests for a
feature which would highlight comments posted to an article since the last
time one looked. Both blacklisting and highlighting (and many other
potential features) run into one practical problem: the single
1300 MHz Duron processor which runs the entire LWN site is already feeling
a little stressed. The more complicated content - weekly edition pages,
long comment trees, etc. - is aggressively pregenerated and cached; adding
per-user rendering would defeat that caching and force those pages to be
rendered on the fly. For various reasons,
upgrading the server involves far more expense than just buying a new box.
The day when we have to make that leap is coming, though.
There was a suggestion that the entire LWN archive be closed to
non-subscribers. That is not a step we expect to take. Closing the
archive would make LWN disappear from the net for all practical purposes,
with little in the way of expected benefit. It is also very much our goal
to increase the amount of useful information available to the community as
a whole, and that runs counter to the idea of a closed archive.
For those who called for more Grumpy Editor articles:
you have been heard. Those articles are a lot of work, and times have been
busy, which is why they have been relatively scarce recently. There
are a couple of topics queued up, however, so expect the Grumpy Editor to
make another appearance here before too long.
In summary: the information you have provided is useful - we are most
grateful. We will be looking at it closely as we ponder changes to LWN to
help make it more successful in the future. What will not change, however,
is our commitment to high-quality writing and high-quality coverage of the
Linux and free software community from within.
Comments (42 posted)
Page editor: Jonathan Corbet
Security
SLIDE into SELinux policy development
February 7, 2007
This article was contributed by Jake Edge.
Complaints about SELinux often center
around its overall complexity and the difficulty in developing policies
for applications that run on the system. The
SELinux Policy IDE
(SLIDE) is an Eclipse plug-in that provides a framework for developing and
testing policies that should help reduce some of these problems.
SELinux is a security framework
that uses the Linux Security Module (LSM) kernel interface to implement
mandatory access control (MAC) mechanism. MAC controls the capabilities that a
particular process can have based on the policies installed by the
administrator. Those policies govern much more than traditional
UNIX-style permissions and for that reason can be difficult to
generate and especially to test. Readers of this page will remember an
overview that covers
a bit more detail about SELinux internals.
SLIDE is an effort to ease the process of developing policies with an
eye towards applications and daemons that have policy support.
To do that, it uses the popular Eclipse integrated development
environment (IDE) as a way to organize and control policy development.
It provides all of the expected capabilities within Eclipse: syntax
highlighting, auto-completion, integrated searching, etc. One of the
biggest hurdles that developers face is keeping track of the various
interfaces, types, roles, and modules and how they interact; SLIDE
organizes and indexes them, along with their comments, and makes that
available in a nice GUI.
The testing features are particularly useful; one can set up a remote
machine (or local virtual machine) that can accept policy updates from
SLIDE. Once the updates have been accepted, various tests can be kicked
off on the remote machine and the audit log can be monitored to determine
whether the policies covered all of the required resources. If not, the
policy can be modified in SLIDE, pushed out to the remote machine and tested
again.
SLIDE is a project of Tresys Technology,
which has released it under the GPL. It does not appear to have attracted
much of a development community, at least yet and the SourceForge project
page has not
been updated in quite some time. The
documentation
and trac site provided by Tresys are excellent. Perhaps the SourceForge
project was an attempt to enlist community aid which did not attract the
level of interest that they might have hoped for. It is a fairly esoteric
subject that does not cause too many open source developers to itch. Many
of those developers, perhaps, simply turn SELinux off.
As with most complex tools, SLIDE will not be terribly helpful to those who
know little about SELinux policies. It has a steep learning curve even if
you have a bit of that background, but for experts it is probably quite
intuitive. For those reasons, it probably will not help other projects
to generate policies for their software. In order to foster more
applications with SELinux policies, it is likely that experts in policy
development will have to join forces with these other projects to produce
and maintain the policies. Using SLIDE will likely speed up that process and
it is a welcome addition to a fairly sparse toolkit.
Comments (4 posted)
New vulnerabilities
bcfg2: local password disclosure
| Package(s): | bcfg2 |
CVE #(s): | |
| Created: | February 1, 2007 |
Updated: | February 7, 2007 |
| Description: |
The bcfg2 configuration file has incorrect permissions, this can
be used for a local password disclosure to unprivileged users. |
| Alerts: |
|
Comments (none posted)
gd: buffer overflow
| Package(s): | gd |
CVE #(s): | CVE-2007-0455
|
| Created: | February 7, 2007 |
Updated: | February 28, 2008 |
| Description: |
The gd graphics library contains a buffer overflow which could enable a remote attacker to execute arbitrary code. Note that various other packages include code from gd and could also be vulnerable. |
| Alerts: |
|
Comments (2 posted)
kdelibs: cross-site scripting
| Package(s): | kdelibs konqeror |
CVE #(s): | CVE-2007-0537
|
| Created: | February 5, 2007 |
Updated: | August 13, 2007 |
| Description: |
Konqueror 3.5.5 does not properly parse HTML comments, which allows remote
attackers to conduct cross-site scripting (XSS) attacks and bypass some XSS
protection schemes by embedding certain HTML tags within a comment, a
related issue to CVE-2007-0478. |
| Alerts: |
|
Comments (none posted)
mpg123: denial of service
| Package(s): | mpg123 |
CVE #(s): | CVE-2007-0578
|
| Created: | February 5, 2007 |
Updated: | February 7, 2007 |
| Description: |
The http_open function in httpget.c in mpg123 before 0.64 allows remote
attackers to cause a denial of service (infinite loop) by closing the HTTP
connection early. |
| Alerts: |
|
Comments (none posted)
postgresql: insufficient verification
| Package(s): | postgresql |
CVE #(s): | CVE-2007-0555
CVE-2007-0556
|
| Created: | February 5, 2007 |
Updated: | March 19, 2007 |
| Description: |
PostgreSQL has two vulnerabilities that allow an authenticated attacker
with the permissions to run arbitrary SQL to launch a denial-of-service
attack or possibly read out random chunks of memory. Since attacks to
require authenticated access, the security hole is only considered medium
risk. See announcement for additional
information. |
| Alerts: |
|
Comments (none posted)
samba: several vulnerabilities
Comments (none posted)
thttpd: remote file access
| Package(s): | thttpd |
CVE #(s): | |
| Created: | February 1, 2007 |
Updated: | February 7, 2007 |
| Description: |
The start-stop-daemon command from thttpd performs a chdir / command,
this allows all files that are readable by the thttpd
process to be remotely accessed by unauthenticated users. |
| Alerts: |
|
Comments (none posted)
wireshark: multiple vulnerabilities
Comments (6 posted)
Updated vulnerabilities
apache: cross-site scripting
| Package(s): | apache |
CVE #(s): | CVE-2006-3918
|
| Created: | August 9, 2006 |
Updated: | April 4, 2008 |
| Description: |
From the Red Hat advisory: "A bug was found in Apache where an invalid Expect header sent to the server
was returned to the user in an unescaped error message. This could
allow an attacker to perform a cross-site scripting attack if a victim was
tricked into connecting to a site and sending a carefully crafted Expect
header." |
| Alerts: |
|
Comments (none posted)
bind: denial of service
| Package(s): | bind |
CVE #(s): | CVE-2006-4095
CVE-2006-4096
|
| Created: | September 7, 2006 |
Updated: | February 1, 2007 |
| Description: |
Bind has two denial of service vulnerabilities.
Recursive servers queries for SIG records will trigger an assertion
failure if more than one RR set is returned.
An INSIST failure can be triggered by sending a large number of
recursive queries. |
| Alerts: |
|
Comments (none posted)
bind: denial of service
| Package(s): | bind |
CVE #(s): | CVE-2007-0493
CVE-2007-0494
|
| Created: | January 26, 2007 |
Updated: | March 14, 2007 |
| Description: |
The bind package is vulnerable to two remote denial of service attacks in
which attackers can cause the bind daemon to to crash or exit unexpectedly
by providing malformed data to the daemon in a DNS request. |
| Alerts: |
|
Comments (none posted)
bluez-utils: hidd vulnerability
| Package(s): | bluez-utils |
CVE #(s): | CVE-2006-6899
|
| Created: | January 16, 2007 |
Updated: | May 14, 2007 |
| Description: |
hidd in BlueZ (bluez-utils) before 2.25 allows remote attackers to obtain
control of the Mouse and Keyboard Human Interface Device (HID) via a
certain configuration of two HID (PSM) endpoints, operating as a server,
aka HidAttack. |
| Alerts: |
|
Comments (none posted)
bugzilla: multiple vulnerabilities
| Package(s): | bugzilla |
CVE #(s): | CVE-2006-5453
CVE-2006-5454
CVE-2006-5455
|
| Created: | November 10, 2006 |
Updated: | August 28, 2007 |
| Description: |
Bugzilla has the following vulnerabilities:
Input data passed to various fields is not properly sanitized before
being passed back to users.
Users can gain unauthorized access to read attachment
descriptions while using diff mode.
HTTP GET and HTTP POST requests can be used to perform unauthorized
actions due to improper verification.
Input that is passed to showdependencygraph.cgi is not properly
sanitized before being returned to users. |
| 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)
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)
cvstrac: denial of service
| Package(s): | cvstrac |
CVE #(s): | CVE-2007-0347
|
| Created: | January 29, 2007 |
Updated: | January 31, 2007 |
| Description: |
Ralf S. Engelschall from OpenPKG GmbH discovered a denial of service (DoS)
vulnerability in the CVS/Subversion/Git Version Control System (VCS)
frontend CVSTrac, version 2.0.0. |
| Alerts: |
|
Comments (none 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)
dbus: denial of service
| Package(s): | dbus |
CVE #(s): | CVE-2006-6107
|
| Created: | December 15, 2006 |
Updated: | February 12, 2007 |
| Description: |
Unspecified vulnerability in the match_rule_equal function in bus/signals.c
in D-Bus before 1.0.2 allows local applications to remove match rules for
other applications and cause a denial of service (lost process messages). |
| Alerts: |
|
Comments (none posted)
dovecot: index cache file handling error
| Package(s): | dovecot |
CVE #(s): | CVE-2006-5973
|
| Created: | November 29, 2006 |
Updated: | May 8, 2007 |
| Description: |
The dovecot IMAP server has an error in its index cache file handling code which could be exploited by an authenticated user to execute arbitrary code. Only servers with the (non-default) mmap_disable=yes option setting are vulnerable. |
| Alerts: |
|
Comments (none posted)
elinks: arbitrary file access
| Package(s): | elinks |
CVE #(s): | CVE-2006-5925
|
| Created: | November 16, 2006 |
Updated: | February 1, 2007 |
| Description: |
The elinks text-mode browser has an arbitrary file access vulnerability
in the Elinks SMB protocol handler. If a user can be tricked into
visiting a specially crafted web page, arbitrary files may be read or
written with the user's permissions. |
| Alerts: |
|
Comments (none posted)
fetchmail: password disclosure and DOS
| Package(s): | fetchmail |
CVE #(s): | CVE-2006-5867
CVE-2006-5974
|
| Created: | January 9, 2007 |
Updated: | March 16, 2007 |
| Description: |
Fetchmail suffers from a password disclosure vulnerability due to a failure to use secure protocols (advisory) and a denial of service vulnerability (advisory). |
| Alerts: |
|
Comments (none posted)
ffmpeg: buffer overflows
| Package(s): | ffmpeg |
CVE #(s): | CVE-2006-4799
CVE-2006-4800
|
| Created: | September 14, 2006 |
Updated: | May 28, 2007 |
| Description: |
the AVI processing code in FFmpeg has a number of buffer overflow
vulnerabilities.
If an attacker can trick a user into loading a specially crafted
crafted AVI, arbitrary code can be executed with the user's privileges. |
| Alerts: |
|
Comments (2 posted)
Mozilla stuff: multiple vulnerabilities
Comments (none posted)
freeradius: several vulnerabilities
| Package(s): | freeradius |
CVE #(s): | CVE-2005-4745
CVE-2005-4746
|
| Created: | August 8, 2006 |
Updated: | April 24, 2007 |
| Description: |
Several remote vulnerabilities have been discovered in freeradius, a
high-performance RADIUS server, which may lead to SQL injection or 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)
ftpd: privilege escalation
| Package(s): | ftpd |
CVE #(s): | CVE-2006-5778
|
| Created: | November 10, 2006 |
Updated: | February 14, 2007 |
| Description: |
Ftpd is vulnerable to a privilege escalation attack,
an incorrect seteuid() call can be used by an FTP user to gain
unauthorized access to files or directories. |
| Alerts: |
|
Comments (none posted)
gcc: file overwrite vulnerability
| Package(s): | gcc |
CVE #(s): | CVE-2006-3619
|
| Created: | September 6, 2006 |
Updated: | March 14, 2008 |
| Description: |
The fastjar utility found in the GNU compiler collection does not perform adequate file path checking, allowing the creation or overwriting of files outside of the current directory tree. |
| Alerts: |
|
Comments (none posted)
gdb: buffer overflow
| Package(s): | gdb |
CVE #(s): | CVE-2006-4146
|
| Created: | September 15, 2006 |
Updated: | June 12, 2007 |
| Description: |
A buffer overflow in dwarfread.c and dwarf2read.c debugging code in GNU
Debugger (GDB) 6.5 allows user-assisted attackers, or restricted users, to
execute arbitrary code via a crafted file with a location block
(DW_FORM_block) that contains a large number of operations. |
| Alerts: |
|
Comments (none 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: stack overwrite
| Package(s): | gnupg |
CVE #(s): | CVE-2006-6235
|
| Created: | December 12, 2006 |
Updated: | March 13, 2007 |
| Description: |
A "stack overwrite" vulnerability in GnuPG (gpg) allows attackers to
execute arbitrary code via crafted OpenPGP packets that cause GnuPG to
dereference a function pointer from deallocated stack memory. |
| Alerts: |
|
Comments (3 posted)
gtk2: denial of service
| Package(s): | gtk2 |
CVE #(s): | CVE-2007-0010
|
| Created: | January 24, 2007 |
Updated: | February 8, 2007 |
| Description: |
From the Red Hat advisory: A bug was found in the way the gtk2 GdkPixbufLoader() function processed
invalid input. Applications linked against gtk2 could crash if they
loaded a malformed image file. |
| Alerts: |
|
Comments (1 posted)
gv: stack-based buffer overflow
| Package(s): | gv |
CVE #(s): | CVE-2006-5864
|
| Created: | November 20, 2006 |
Updated: | April 9, 2007 |
| Description: |
Stack-based buffer overflow in the ps_gettext function in ps.c for GNU gv
3.6.2, and possibly earlier versions, allows user-assisted attackers to
execute arbitrary code via a PostScript (PS) file with certain headers that
contain long comments, as demonstrated using the DocumentMedia header. |
| Alerts: |
|
Comments (none posted)
gzip: multiple vulnerabilities
| Package(s): | gzip |
CVE #(s): | CVE-2006-4334
CVE-2006-4335
CVE-2006-4336
CVE-2006-4337
CVE-2006-4338
|
| Created: | September 19, 2006 |
Updated: | June 1, 2007 |
| Description: |
Tavis Ormandy of the Google Security Team discovered two denial of service
flaws in the way gzip expanded archive files. If a victim expanded a
specially crafted archive, it could cause the gzip executable to hang or
crash.
Tavis Ormandy of the Google Security Team discovered several code execution
flaws in the way gzip expanded archive files. If a victim expanded a
specially crafted archive, it could cause the gzip executable to crash or
execute arbitrary code. |
| Alerts: |
|
Comments (1 posted)
horde-kronolith: local file inclusion
| Package(s): | horde-kronolith |
CVE #(s): | CVE-2006-6175
|
| Created: | January 17, 2007 |
Updated: | March 7, 2008 |
| Description: |
Kronolith contains a mistake in lib/FBView.php where a raw, unfiltered
string is used instead of a sanitized string to view local files. An
authenticated attacker could craft an HTTP GET request that uses directory
traversal techniques to execute any file on the web server as PHP code,
which could allow information disclosure or arbitrary code execution with
the rights of the user running the PHP application (usually the webserver
user). |
| Alerts: |
|
Comments (none posted)
imagemagick: buffer overflows
| Package(s): | imagemagick |
CVE #(s): | CVE-2006-5868
|
| Created: | November 28, 2006 |
Updated: | February 16, 2007 |
| Description: |
Daniel Kobras discovered multiple buffer overflows in ImageMagick's SGI
file format decoder. By tricking a user or an automated system into
processing a specially crafted SGI image, this could be exploited to
execute arbitrary code with the user's privileges. |
| Alerts: |
|
Comments (1 posted)
ImageMagick: buffer overflows
| Package(s): | ImageMagick |
CVE #(s): | CVE-2006-5456
|
| Created: | October 31, 2006 |
Updated: | March 8, 2007 |
| Description: |
Multiple buffer overflows in GraphicsMagick before 1.1.7 and ImageMagick
6.0.7 allow user-assisted attackers to cause a denial of service and
possibly execute execute arbitrary code via (1) a DCM image that is not
properly handled by the ReadDCMImage function in coders/dcm.c, or (2) a
PALM image that is not properly handled by the ReadPALMImage function in
coders/palm.c. |
| Alerts: |
|
Comments (2 posted)
imlib2: arbitrary code execution
| Package(s): | imlib2 |
CVE #(s): | CVE-2006-4806
CVE-2006-4807
CVE-2006-4808
CVE-2006-4809
|
| Created: | November 6, 2006 |
Updated: | August 13, 2007 |
| Description: |
M. Joonas Pihlaja discovered that imlib2 did not sufficiently verify the
validity of ARGB, JPG, LBM, PNG, PNM, TGA, and TIFF images. If a user
were tricked into viewing or processing a specially crafted image with
an application that uses imlib2, the flaws could be exploited to execute
arbitrary code with the user's privileges. |
| Alerts: |
|
Comments (none posted)
java: multiple vulnerabilities
| Package(s): | java |
CVE #(s): | CVE-2006-4339
CVE-2006-4790
CVE-2006-6731
CVE-2006-6736
CVE-2006-6737
CVE-2006-6745
|
| Created: | January 18, 2007 |
Updated: | June 8, 2007 |
| Description: |
java has multiple vulnerabilities, these include:
an RSA exponent padding attack vulnerability, two vulnerabilities
which allow untrusted applets to access data in other applets,
vulnerabilities that involve applets gaining privileges due to
serialization bugs in the JRE and buffer overflows in the java image
handling routines that can give attackers read/write/execute capabilities
for local files. |
| Alerts: |
|
Comments (1 posted)
kdelibs: integer overflow
| Package(s): | kdelibs |
CVE #(s): | CVE-2006-4811
|
| Created: | October 18, 2006 |
Updated: | March 5, 2007 |
| Description: |
The KDE khtml library can pass untrusted parameters into Qt, allowing a hostile user to trigger an integer overflow there and execute arbitrary code. |
| Alerts: |
|
Comments (none posted)
kdenetwork: denial of service
| Package(s): | kdenetwork |
CVE #(s): | CVE-2006-6811
|
| Created: | January 11, 2007 |
Updated: | February 1, 2007 |
| Description: |
The KsIRC 1.3.12 utility in kdenetwork is vulnerable to a remote
denial of service attack that can be caused by a malicious IRC server
sending a long PRIVMSG string. This causes an assertion failure and
an associated NULL pointer dereference. |
| Alerts: |
|
Comments (none posted)
kernel: multiple vulnerabilities
| Package(s): | kernel |
CVE #(s): | CVE-2006-5749
CVE-2006-4814
CVE-2006-6106
|
| Created: | January 5, 2007 |
Updated: | May 7, 2008 |
| Description: |
A security issue has been reported in Linux kernel due to an error in
drivers/isdn/i4l/isdn_ppp.c as the "isdn_ppp_ccp_reset_alloc_state()"
function never initializes an event timer before scheduling it with the
"add_timer()" function.
The mincore function in the kernel does not properly lock access to user
space, which has unspecified impact and attack vectors, possibly related to
a deadlock.
Another vulnerability has been reported in Linux kernel caused by a
boundary error within the handling of incoming CAPI messages in
net/bluetooth/cmtp/capi.c. This can be exploited to overwrite certain
Kernel data structures. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-4623
|
| Created: | October 18, 2006 |
Updated: | November 14, 2007 |
| Description: |
The kernel DVB la |