On DTrace envy
By Jonathan Corbet
August 7, 2007
When Sun looks to highlight the strongest features of the Solaris operating
system, DTrace always appears near the top of the list. Your editor
recently had a conversation with an employee of a prominent analyst firm
who was interested, above all else, in when Linux would have some sort of
answer to DTrace. There is a common notion out there that tracing tools is
one place where Linux is significantly behind the state of the art. So
your editor decided to take a closer look.
The Linux tool which is most similar to DTrace is SystemTap. This development is
supported by a number of high-profile companies, including Red Hat, Intel,
IBM, and Hitachi. Most distributions have SystemTap packages somewhere in
their systems of repositories, making it readily available to Linux users.
DTrace supporters have been known to say that SystemTap is merely a knock-off of
DTrace, and a badly-done one at that. SystemTap proponents will
counter that it is an independent development which can hold its own.
Both tools are based on the insertion of probe points in the system
kernel. Whenever a thread of execution hits one of those probe points,
some sort of action - as described in the tool's C-like language - is run.
That action can be as simple as printing a message, or it can be
significantly more complicated than that.
DTrace comes with a large set of pre-defined probe points wired into the
Solaris kernel - seemingly tens of thousands of them. These points are well documented and
cover most of the kernel. Some simple wildcarding is implemented for the
selection of multiple probe points. It is claimed that the run-time
overhead of unused probe points is negligible. [Update: see the
comments for some useful clarification on the use of dynamic probe points
in DTrace.]
SystemTap, instead, does not depend on static probe points within the
kernel; that capability exists, but nobody has much interest in maintaining
all of those points. Instead, SystemTap uses dynamic probes (implemented
with kprobes) which
are inserted into the kernel at run time. A flexible language can enable
probes to be easily inserted anywhere in the kernel, with fairly complete
wildcard support which allows, for example, all functions within a source
file or subsystem to be instrumented with a single statement. Unused probe
points do not exist at all, and so cannot affect system performance.
There are a couple of advantages to the DTrace approach. The probe points
exist and can be easily found in the manuals; a SystemTap user, instead, is
required to have a certain amount of familiarity with the kernel source
code. DTrace probe points are fixed at locations where it is known to be
safe to interrupt the execution of the kernel. The SystemTap
documentation, instead, comes with warnings that placing probes in the
wrong places can cause system crashes and mutterings about the possibility of
implementing blacklists in the future. The number of "wrong places"
appears to be quite small, but that is of limited comfort for an
administrator trying to observe the operation of a production system -
something which is supposed to be possible with either system. There is a
set of predefined points provided in the "tapsets" packaged with SystemTap,
but it is small.
The "D" language provided with DTrace is more restricted than the SystemTap
language, though it does have a few features - like the ability to print
stack traces - which appear to be missing in SystemTap. The D language has
no flow control or looping constructs. Instead, the code associated with a
probe has a predicate expression determining whether that code is executed
when the probe is hit. Thus each selected probe point can be thought of
as having a single, controlling "if" statement around it, with no
further flow control possible afterward.
SystemTap's language, instead, has conditionals, loops, and the ability to
define functions. It also has, for those who like to live dangerously, the
ability to embed C code. There are clear advantages to a more powerful
scripting language, but hazards as well: SystemTap must, for example, carry
extra code to keep infinite loops in scripts from bringing down the system.
D is, like Java, compiled to a special virtual machine and interpreted at
run time. SystemTap, instead, compiles directly to C. So SystemTap code
may execute more quickly, but D may benefit from the additional safety
checks which a virtual machine allows.
DTrace has the ability to work with user-space probes. As with the kernel,
developers are required to insert the probe points before DTrace can use
them; it is not clear that large amounts of user-space code have been so
instrumented. There is clear elegance to the idea, though, and this
capability may prove genuinely useful in the future as more applications
are equipped with probe points. SystemTap does not currently have this
capability.
In practice, simply getting SystemTap to work can be a challenge - even
when a distributor-supported package is available. SystemTap is clearly
its own development which must be (somewhat painfully) integrated with a
specific kernel. DTrace can be expected to simply work out of the box.
And that is perhaps the biggest difference between the two tracing
systems. SystemTap would appear to have all of the capabilities it really
needs to be a powerful system tracing tool - at least on the kernel side.
DTrace features which are missing - speculative
tracing, for example - could certainly be added if there were demand
for it. Evidently user-space tracing is in the works.
But what SystemTap really needs is more basic than that. What's missing is
the degree of maturity exhibited by DTrace.
SystemTap needs to simply work on most systems - and be usable by the
system administrators. To a great extent, the "simply work" part is
something that the distributors must address. Current SystemTap packages
as tested by your editor have the look of an edge-of-the-repository
afterthought. They do not have the dependencies to bring in the needed
kernel information, requiring a fair amount of manual "what does it need
now?" administrative work.
Even then, performance is spotty at best; the SystemTap utilities just do
not have access to the sort of information (uncompressed kernel images, for
example) that they need to operate correctly. Until an administrator can
simply tell the package management system to install SystemTap and expect
to have it work thereafter, it will be hard to convince anybody that we
have a mature tracing tool.
On the development side, there should be an extensive set of
well-documented trace points which can be used without having to go into
the kernel source. Digging deeply into the system in a flexible way is
always going to require a certain amount of skill, but SystemTap all but
requires its users to be kernel hackers. The hard work of making a tool
which can match - and, in places, exceed - DTrace has been done. What
remains is a large (but relatively straightforward) job: making this tool
usable by a much wider set of system administrators. Until that is done,
DTrace envy will remain with us.
Comments (54 posted)
Red Hat High teaches free software
By Jake Edge
August 7, 2007
"Get 'em while they're young" should be the motto of Red Hat High (RHH), a summer
camp program, funded by Red Hat, to introduce junior high school students
to free software tools. Now in its second year, RHH has a curriculum
designed to get students using creative tools to produce tangible works
during the week-long camp. In addition to teaching 50 eighth and ninth
grade students about free software, the project seeks to expand its reach,
not by increasing its enrollment, but by exporting the concept to other
venues.
The students all came from schools in the area around Red Hat's North Carolina
headquarters, and each had to be nominated by one of their teachers. RHH was
looking for participants "that show great creative potential and an
interest in technology, but perhaps lack the resources to pursue it outside
of school." In addition to the technology focus, the camp also provided
other social events in the evenings, all free of charge to the
campers. The camp was held at North Carolina State University, allowing
the students to experience dormitory life a few years early.
The students could choose amongst five different tracks, each focused on a
particular tool:
The curriculum for each track had a specific goal, "create a Google Gadget"
or "create ten seconds of animation" for example. During the program,
the students would learn the tool from scratch, then, singly or
collaboratively, use it to create something.
Two student projects are highlighted in a Red Hat Magazine article
about RHH 2007. One is three minute audio clip, the other a fifteen
second animation - both are quite impressive for 8th and 9th grade
students. The organizers failed to get permission from all of the students
to share their work, so these are the only examples available - something
they hope to fix for next year's camp. By all
accounts, RHH was a success, with the students and their parents as well
as the organizers. But, just as important, the course content for each of the
tracks will be made available to other
projects with similar goals.
Camp field trips included the Red Hat campus to "experience life in a
technology company" as well as a visit to a college level 3D animation
class, where the "free beer" part of free software really hit home.
Project coordinator Greg DeKoenigsberg
describes the scene:
When the kids reached the 3D Animation classroom, they were very impressed
by Maya — until one of them asked for a free copy. 'A full license
of Maya costs $7000,' the instructor said, which elicited an outraged
reaction from the kids. 'But Blender is free!' they cried in unison.
Then the teacher started to show them some of the things Maya could do, and
he was clearly surprised at the kids' clueful responses. 'These are
vertices,' he'd say, and then they'd say 'yeah, we've done that.' 'Okay,
this is texturing.' 'Yeah, we've done that too.'
In many ways, RHH is a testbed for free software outreach to young people.
In the two years of the program, the organizers have learned what works,
now they are ready to export that knowledge to others. The first step is
to focus on tutorials for the various tools, by creating new versions
specifically packaged into curricula that teachers can immediately use.
DeKoenigsberg, puts it this way:
A strong community of teachers and free software enthusiasts should be able
to develop, validate, and license simple lesson plans, with the explicit
goal of teaching kids to do stuff that is both cool and immediately
useful. It's my hope that Red Hat High can serve as a model for that
development.
Once the curricula exist, training teachers to use it in their classrooms
is the next step. The main barrier is teachers' time, but the way around that is
through the professional development programs that many school districts
have. Because professional development courses are often tied to their
earnings, formal training sessions that fulfill those requirements, will be
quite attractive to teachers that have an interest in free software, but
lack the time. In many districts, funding is available for
these kinds of training programs as well.
The project is a worthy one, even if it never escapes beyond the
Raleigh-Durham area. Even 50 students at a time, getting the word out
about free software is a good thing. If the project's larger goals can be
realized – spreading this knowledge far and wide – it can make
a huge difference.
Getting young folks hooked on expensive proprietary
software may be good for the bottom line at Adobe or Microsoft, but it is
not so good for the wallets of schools and parents. Free software is able
to replace an awful lot of proprietary packages, with no licensing hassles,
so that students can run it anywhere they can find an open computer. That
message has not, yet, been widely heard, but RHH hopes to change that.
Comments (2 posted)
A report from OSCON 2007
August 2, 2007
This article was contributed by Donnie Berkholz
O'Reilly's annual OSCON in Portland, Ore., is perhaps the only major
conference in North America that spans the entire spectrum of open-source
communities. This makes it a great opportunity to learn from people who may
be encountering the same sorts of problems in a vastly different
environment. Other events such as FOSDEM or LCA already provide this kind
of environment, but
for those of us who are US-based, it's helpful to have one with a lower
travel budget. I highly recommend giving a talk if you're going so you get
in free, though, since registration costs hover around US$1000 and up. It's
clearly not a nonprofit conference.
Numerous groups met preceding the main part of the conference, one of them a
group of people involved with running a variety of free/open-source
projects. At the foundations
summit, most of the discussion centered around dealing with the issues
facing nonprofits, such as trademarks, fundraising and bookkeeping. But in
the same way as a full conference, the "hallway track" here was the most
useful. As the number of people grows, the discussion gets slower and
slower, but meeting the people involved with other foundations is
invaluable. The summit ended Tuesday, and next day, the exhibit hall and
regular sessions began.
In his session, Arjan van de Ven talked about efforts to reduce power use,
focusing on a few main problems to avoid in your code. The first, not
surprisingly, was polling. There is no excuse for polling, with the advent
of things like inotify. He said, "Frequent polling causes spattergroit."
His second enemy was timers. It costs power to keep moving your CPU in and
out of idle states, so you want to group timer events together rather than
having them randomly spread throughout time by a number of programs. On the
kernel side, you can use round_jiffies() or
round_jiffies_relative(), and in
userland, you can use glib's g_timeout_add_seconds() —
not g_timeout_add(). Some work is underway to add this
functionality to glibc as well. You don't want the entire Internet doing
this at the same time, however, so each computer must group its events at a
slightly different time.
Arjan's final enemy was disk I/O. Since disks have moving parts, they consume
a lot of power (at least until solid-state disks grow more
common). High-speed links such as SATA and SCSI also eat power when not in
power-saving mode. Gotchas here include opening files, even when in cache,
because of the access time update (use the O_NOATIME flag to open() when
possible), and looking for files or directories that don't exist (even when
using inotify, this always goes to disk).
A special case of this is media playback. The key is avoiding constant
spinups of DVDs as well as hard drives by using large buffers — Arjan
suggested 20 minutes of video or a minute of audio. Also, decode in large
batches so you can be idle longer.
Tools such as powertop and strace are key in tracking down the
culprits. Powertop can tell you where to look, and strace can tell you more
about what any programs are doing. Near the end, Arjan showed a graph of how
tuning and recent fixes dropped a Fedora 7 default installation from a
power consumption of 21W down to about 15.5W. That just a few fixes dropped
it by so much shows how broken things were, but we're now on the right
track. A good goal is to aim for 50 or less wakeups a second, because
getting below that level generally doesn't gain you much more.
A man with the job title "Disruptive Innovator" gave a talk with about 550
slides in 45 minutes. Rolf Skyberg of Ebay applied Maslow's hierarchy of
needs to technology to try to explain how users behave. The first level is
survival, the second is security, and the third is belonging. Computer
programs apparently haven't managed to get any higher up on the scale
yet. In terms of programs, survival means the program runs without
segfaults; security means the program is useful; and belonging means the
program is pretty. The more energy users spend finding the basics (help,
logging in, etc.), the less they have to spend doing something useful. But
one thing worth remembering is that people using a program may have higher needs
than you expected. For example, the iPod isn't just useful, it's pretty. And
people really care about that prettiness despite the lack of features like
an FM transmitter, a recorder, etc. that many other, less popular MP3
players have.
Luke Kanies talked about Puppet, a server automation tool he wrote in
Ruby. It's a replacement for earlier popular tools such as cfengine. He
really promoted the architecture, because any component in the entire system
can be replaced and reused separately. Puppet's made of three main layers:
server, networking and client. The server layer contains a compiler, a
file server, a certificate authority and a report handler. The networking is
XMLRPC over HTTPS. The client layer includes a resource abstraction layer,
transactions and a resource server. Each of these individual components can
be ripped out and replaced if you don't like it. You could change the
configuration language, use a different method of communication, or whatever
else your heart desires.
The resource abstraction layer contrasts the most with other tools such as
cfengine. It abstracts all the concepts like "install a package," "add a
user," "add a group" and so forth so you can run Puppet on any Linux or
other Unix-like OS and retain a simple configuration file without
OS-specific details. The layer supports about 10 different distributions and
other operating systems, and it's not difficult to add more.
Work is underway to create a library of Puppet config files (or recipes) to
reduce all the duplication, and that should greatly ease adoption of
Puppet. Puppet seems like a well-thought-out and extensible tool, so it will
be interesting to watch where it goes.
Clinton Nixon talked about dealing with legacy PHP code, but many of the
points are generally applicable to refactoring any code. His three primary
suggestions were to separate the controller and the view, even if you don't
have a solid MVC architecture; to call methods instead of including code
that runs from the include file; and to get rid of global variables.
His rules for view code were that control structures, printing, and
display-specific, unnested functions were allowed, but assignment and other
function calls were prohibited. He suggested beginning by drawing a line at
the top of the code and adding a comment that says "view code below here,"
then gradually migrating controller code above the line until you can move
it to a separate file. For loops, encapsulate the variables in an
object. Once you've gotten to this point, you may find duplicated views that
you can factor out.
Untangling a web of included files is a process of figuring out the inputs
and outputs, wrapping the entire file in a method, then refactoring. The
nice part about this style of refactoring is that the code always
works. There's never a point where you check in the code and it's broken.
Finally, he recommended two books: Working effectively with legacy code, by
Michael Feathers, and Refactoring by Martin Fowler. Although the Fowler
book is a classic, he recommended the newer book by Feathers because it's
more approachable.
At the close of the sessions Thursday, Dave Jones gave his now-infamous
"User Space Sucks" talk. Since most people have gotten the basic idea of
this talk, I'm only going to mention the new information. Dave re-ran his
tests a week ago on Fedora 7 to look at disk I/O during the
bootstrap process, and he
found that it had actually gotten even worse since FC6. Counts of stat(),
open() and exec() calls had either increased or stayed the same. But the
problem has grown harder, because the offenders no longer stand out in the
same way as the originals.
OSCON always provides some entertaining and educational talks, provided
you've got a way to get into them. But its free content isn't too shabby
either. The exhibit hall, all of the BOFs and parties (of which there are
many), and the accompanying OSCAMP (like FooCamp, BarCamp, etc.) and FOSCON
(mostly about Ruby) are all gratis. It stands nearly alone in the U.S. as a
conference that spans across all of the open-source world, although a niche
certainly exists for a lower-margin meeting like FOSDEM or LCA on this side
of the ocean.
Comments (35 posted)
Page editor: Jonathan Corbet
Security
Securing our votes
By Jake Edge
August 8, 2007
This has been a bad few weeks to be a voting machine vendor. Three
separate governments, California, Florida and the UK looked at the devices
and have come to remarkably similar conclusions. The machines they looked
at are poorly designed, poorly implemented and subject to a wide variety of
security threats. None of the studies mentioned it, but it is likely that
the machines looked great.
The most comprehensive study was done
by California Secretary of State Debra Bowen's office. That study looked
at three electronic voting systems, each from a different manufacturer.
Each system had three separate teams investigating, one looking at the source
code, a "red team" that had physical access to the device and an
accessibility team. Their conclusions were not surprising to anyone who has
paid attention to this issue over the years.
All three of the voting machine systems were found to be sorely deficient
by all three teams. Even accessibility, which is one of the major benefits
touted by electronic voting advocates, was found lacking:
Although each of the tested voting systems included some accessibility
accommodations, none met the accessibility requirements of current law and
none performed satisfactorily in test voting by persons with a range of
disabilities and alternate language needs.
Though it is certainly terrible not to meet the needs of some individual
voters,
safeguarding the election process and accurately reporting the vote totals
need to be
higher priorities. Since they obviously had not successfully completed the
accessibility task, one would hope they were able to secure the
voting process. Unfortunately, they could not get the primary job done
right either.
The red team reports were released first and the conclusions were
devastating:
The red teams demonstrated that the security mechanisms provided for
all systems analyzed were inadequate to ensure accuracy and integrity
of the election results and of the systems that provide those results.
The teams were able to defeat the physical security of the voting machines,
modify or overwrite the software in the machines as well as subvert the
tabulation machines in order to provide incorrect vote counts. All of this
just by having access to the machines themselves; the same access that
election officials, poll workers and, to a lesser extent, voters, have.
Several days later, the source code teams' reports were released and, at
that point, were almost anti-climactic. Unsurprisingly, they found
numerous, hideous source code flaws in all three systems. Buffer
overflows, hard coded passwords ('diebold' being a particularly difficult
one to guess), misuse of encryption, integer overflows (wrapping
vote counts to negative or zero perhaps); the list goes on an on. It is as
if the voting machine vendors are completely unaware of the last
twenty (or thirty or forty) years of software security flaws.
In reality, they are most likely not unaware, they are just arrogant.
Diebold, Hart and Sequoia (the companies whose machines were studied) do
not depend solely on their technical "prowess" to win bids for providing
voting machines, politics plays a huge role. These are well connected
companies. It also helps that they are all uniformly bad, there are
literally no secure choices for a government agency to make.
Florida's study only covered
Diebold equipment, but it echoed the findings in the California study. Avi
Rubin of Johns Hopkins University, who participated in a 2003 study of
Diebold's voting machine, notes:
So, Diebold is doing some things better than they
did before when they had absolutely no security, but they have yet to do
them right. Anyone taking any of our cryptography classes at Johns Hopkins,
for example, would do a better job applying cryptography.
One of the bigger problems found was that Diebold assigned cryptographic
keys to each voting machine that is derived from an MD5 hash
of the machine's serial number. Rubin again:
This is arguably worse than having a fixed static key in all of the
machines. Because with knowledge of the machine's serial number, anyone can
calculate all of the secret keys. Whereas before, someone would have needed
access to the source code or the binary in the machine.
The UK also released reports
on the outcome of electronic voting trials held in May. The overall
summary of the trial, was, once again, not very favorable:
The
level of implementation and
security risk involved was
significant and unacceptable.
There remain issues with the
security and transparency of the
solutions and the capacity of the
local authorities to maintain
control over the elections.
This was not the result of security professionals analyzing the systems for
flaws, but was instead noted in actual trials of the equipment in an election.
The California study was quite well done and well thought out, except for
one thing: it was done long after the equipment was bought and used in
elections. This is the kind of study that needs to be done before
buying the equipment. Due to the conclusions of the study, Bowen
revoked the certification of the equipment from all three vendors, but immediately had to
conditionally re-certify them as a practical matter. Even with a six month
lead time, replacement systems (either electronic or of some other kind)
could not be deployed before the 2008 California presidential primary voting.
The reaction to the California study by the manufacturers was typical. It
is the same reaction they have had to each and every study done of the
security of their devices: trivialize it. Each released a statement in
reaction to the study conclusions, essentially admitting the flaws, but
claiming that any "laboratory study" would find vulnerabilities. According
to these vendors, it is impossible to make a secure voting system.
As they certainly know, no one is asking these vendors to
break the laws of physics
or to produce perfectly secure code. It would appear that they expend far
more effort in deflecting criticism and lobbying various legislative bodies
than they spend trying to secure their code and equipment. It is not
necessary that the equipment be tamper-proof, merely that tampering can be
detected. At least minimal precautions, perhaps to the level taught to
computer science undergraduates, should be taken with the software.
This is not anywhere near as hard a problem as the vendors make it out to be.
Many of the techniques needed to secure voting machinery are well known and
well understood, at least outside of the vendors' labs. This is an area
where open source methods could be and should be applied.
Organizations like BlackBoxVoting.org and the NSF Accurate project should be
working on solutions. Private companies have shown themselves to be
completely incompetent at producing secure voting equipment, it is time for
another solution to be tried.
Comments (37 posted)
New vulnerabilities
gd: multiple vulnerabilities
| Package(s): | gd |
CVE #(s): | CVE-2007-3472
CVE-2007-3473
CVE-2007-3474
CVE-2007-3475
CVE-2007-3476
CVE-2007-3477
CVE-2007-3478
|
| Created: | August 6, 2007 |
Updated: | July 22, 2008 |
| Description: |
Integer overflow in gdImageCreateTrueColor function in the GD Graphics
Library (libgd) before 2.0.35 allows user-assisted remote attackers
to have unspecified remote attack vectors and impact. (CVE-2007-3472)
The gdImageCreateXbm function in the GD Graphics Library (libgd)
before 2.0.35 allows user-assisted remote attackers to cause a denial
of service (crash) via unspecified vectors involving a gdImageCreate
failure. (CVE-2007-3473)
Multiple unspecified vulnerabilities in the GIF reader in the
GD Graphics Library (libgd) before 2.0.35 allow user-assisted
remote attackers to have unspecified attack vectors and
impact. (CVE-2007-3474)
The GD Graphics Library (libgd) before 2.0.35 allows user-assisted
remote attackers to cause a denial of service (crash) via a GIF image
that has no global color map. (CVE-2007-3475)
Array index error in gd_gif_in.c in the GD Graphics Library (libgd)
before 2.0.35 allows user-assisted remote attackers to cause
a denial of service (crash and heap corruption) via large color
index values in crafted image data, which results in a segmentation
fault. (CVE-2007-3476)
The (a) imagearc and (b) imagefilledarc functions in GD Graphics
Library (libgd) before 2.0.35 allows attackers to cause a denial
of service (CPU consumption) via a large (1) start or (2) end angle
degree value. (CVE-2007-3477)
Race condition in gdImageStringFTEx (gdft_draw_bitmap) in gdft.c in the
GD Graphics Library (libgd) before 2.0.35 allows user-assisted remote
attackers to cause a denial of service (crash) via unspecified vectors,
possibly involving truetype font (TTF) support. (CVE-2007-3478) |
| Alerts: |
|
Comments (none posted)
gimp: integer overflows
| Package(s): | gimp |
CVE #(s): | CVE-2006-4519
|
| Created: | August 2, 2007 |
Updated: | August 8, 2007 |
| Description: |
The Gimp has multiple integer overflow vulnerabilities. If a user can be
tricked into opening specially crafted DICOM, PNM, PSD, PSP, RAS, XBM,
or XWD images, integer overflows can occur and arbitrary code can be
executed with the user's privileges. |
| Alerts: |
|
Comments (1 posted)
java-1.5.0-sun: multiple vulnerabilities
| Package(s): | java-1.5.0-sun |
CVE #(s): | CVE-2007-3503
CVE-2007-3655
CVE-2007-3698
CVE-2007-3922
|
| Created: | August 6, 2007 |
Updated: | June 24, 2008 |
| Description: |
The Javadoc tool was able to generate HTML documentation pages that
contained cross-site scripting (XSS) vulnerabilities. A remote attacker
could use this to inject arbitrary web script or HTML. (CVE-2007-3503)
The Java Web Start URL parsing component contained a buffer overflow
vulnerability within the parsing code for JNLP files. A remote attacker
could create a malicious JNLP file that could trigger this flaw and execute
arbitrary code when opened. (CVE-2007-3655)
The JSSE component did not correctly process SSL/TLS handshake requests. A
remote attacker who is able to connect to a JSSE-based service could
trigger this flaw leading to a denial-of-service. (CVE-2007-3698)
A flaw was found in the applet class loader. An untrusted applet could use
this flaw to circumvent network access restrictions, possibly connecting to
services hosted on the machine that executed the applet. (CVE-2007-3922)
|
| Alerts: |
|
Comments (none posted)
mediawiki: cross-site scripting
| Package(s): | mediawiki |
CVE #(s): | CVE-2007-1054
|
| Created: | August 7, 2007 |
Updated: | August 8, 2007 |
| Description: |
A cross-site scripting (XSS) vulnerability in the AJAX features in
index.php in MediaWiki 1.6.x through 1.9.2, when $wgUseAjax is enabled,
allows remote attackers to inject arbitrary web script or HTML via a UTF-7
encoded value of the rs parameter, which is processed by Internet Explorer. |
| Alerts: |
|
Comments (2 posted)
moodle: cross-site scripting
| Package(s): | moodle |
CVE #(s): | CVE-2007-3555
|
| Created: | August 7, 2007 |
Updated: | January 16, 2008 |
| Description: |
A cross-site scripting (XSS) vulnerability in index.php in Moodle 1.7.1
allows remote attackers to inject arbitrary web script or HTML via a style
expression in the search parameter. |
| Alerts: |
|
Comments (none posted)
openssl: private key attack
| Package(s): | openssl |
CVE #(s): | CVE-2007-3108
|
| Created: | August 7, 2007 |
Updated: | May 13, 2008 |
| Description: |
OpenSSL could allow a local user in certain circumstances to divulge
information about private keys being used. |
| Alerts: |
|
Comments (none posted)
xpdf: bounds checking issues
| Package(s): | xpdf |
CVE #(s): | |
| Created: | August 3, 2007 |
Updated: | August 8, 2007 |
| Description: |
XPDF had several bounds checking issues that were fixed in version 3.02
according to this change
log. A patch can be found here. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
apache2: information disclosure
| Package(s): | apache |
CVE #(s): | CVE-2007-1862
|
| Created: | June 20, 2007 |
Updated: | February 18, 2008 |
| Description: |
From the Mandriva advisory: "The recall_headers function in mod_mem_cache in Apache 2.2.4 does not
properly copy all levels of header data, which can cause Apache to
return HTTP headers containing previously-used data, which could be
used to obtain potentially sensitive information by unauthorized users." |
| Alerts: |
|
Comments (2 posted)
apache: multiple vulnerabilities
| Package(s): | apache |
CVE #(s): | CVE-2007-3304
CVE-2006-5752
|
| Created: | June 27, 2007 |
Updated: | February 18, 2008 |
| Description: |
The Apache HTTP Server did not verify that a process was an Apache child
process before sending it signals. A local attacker who has the ability to
run scripts on the Apache HTTP Server could manipulate the scoreboard and
cause arbitrary processes to be terminated, which could lead to a denial of
service. (CVE-2007-3304)
A flaw was found in the Apache HTTP Server mod_status module. Sites with
the server-status page publicly accessible and ExtendedStatus enabled were
vulnerable to a cross-site scripting attack. On Red Hat Enterprise Linux
the server-status page is not enabled by default and it is best practice to
not make this publicly available. (CVE-2006-5752) |
| Alerts: |
|
Comments (1 posted)
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)
Asterisk: two SIP denial of service vulnerabilities
| Package(s): | Asterisk |
CVE #(s): | CVE-2007-1561
CVE-2007-1594
|
| Created: | April 3, 2007 |
Updated: | August 27, 2007 |
| Description: |
The Madynes research team at INRIA has discovered that Asterisk contains a
null pointer dereferencing error in the SIP channel when handling INVITE
messages. Furthermore qwerty1979 discovered that Asterisk 1.2.x fails to
properly handle SIP responses with return code 0. A remote attacker could
cause an Asterisk server listening for SIP messages to crash by sending a
specially crafted SIP message or answering with a 0 return code. |
| Alerts: |
|
Comments (none posted)
avahi: denial of service
| Package(s): | avahi |
CVE #(s): | CVE-2007-3372
|
| Created: | June 28, 2007 |
Updated: | September 18, 2007 |
| Description: |
Avahi is vulnerable to a local denial of service that can be caused by
making an erroneous call to the assert() function. |
| Alerts: |
|
Comments (none posted)
bind: DNS cache poisoning
| Package(s): | bind |
CVE #(s): | CVE-2007-2926
|
| Created: | July 24, 2007 |
Updated: | August 20, 2007 |
| Description: |
A flaw was found in the way BIND generates outbound DNS query ids. If an
attacker is able to acquire a finite set of query IDs, it becomes possible
to accurately predict future query IDs. Future query ID prediction may
allow an attacker to conduct a DNS cache poisoning attack, which can result
in the DNS server returning incorrect client query data. |
| Alerts: |
|
Comments (none posted)
bochs: buffer overflow
| Package(s): | bochs |
CVE #(s): | CVE-2007-2893
|
| Created: | July 20, 2007 |
Updated: | November 19, 2007 |
| Description: |
A heap-based buffer overflow in the bx_ne2k_c::rx_frame function in
iodev/ne2k.cc in the emulated NE2000 device in Bochs 2.3 allows local users
of the guest operating system to write to arbitrary memory locations and
gain privileges on the host operating system via vectors that cause TXCNT
register values to exceed the device memory size, aka "RX Frame heap
overflow." |
| 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)
centericq: buffer overflows
| Package(s): | centericq |
CVE #(s): | CVE-2007-3713
|
| Created: | July 20, 2007 |
Updated: | December 17, 2007 |
| Description: |
Multiple buffer overflows in Konst CenterICQ 4.9.11 through 4.21 allow
remote attackers to execute arbitrary code via unspecified vectors. NOTE:
the provenance of this information is unknown; the details are obtained
solely from third party information. NOTE: this might overlap
CVE-2007-0160. |
| Alerts: |
|
Comments (none posted)
clamav: denial of service
| Package(s): | clamav |
CVE #(s): | CVE-2007-3725
|
| Created: | July 24, 2007 |
Updated: | February 27, 2008 |
| Description: |
A NULL pointer dereference has been discovered in the RAR VM of Clam
Antivirus (ClamAV) which allows user-assisted remote attackers to
cause a denial of service via a specially crafted RAR archives. |
| Alerts: |
|
Comments (none posted)
cups: denial of service
| Package(s): | cups |
CVE #(s): | CVE-2007-0720
|
| Created: | March 26, 2007 |
Updated: | February 7, 2008 |
| Description: |
Previous versions of the cups package could be forced to hang via a client
"partially negotiating" an ssl connection. In this state, cups would not
allow other connections to be made, a denial of service. |
| Alerts: |
|
Comments (none posted)
gpdf: integer overflow
| Package(s): | cups poppler xpdf |
CVE #(s): | CVE-2007-3387
|
| Created: | July 31, 2007 |
Updated: | November 28, 2007 |
| Description: |
The gpdf library contains an integer overflow which can be exploited via a malicious PDF file. This code finds its way into multiple packages, including xpdf, kpdf, poppler, cups, and more. |
| 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)
dovecot: directory traversal
| Package(s): | dovecot |
CVE #(s): | CVE-2007-2231
|
| Created: | May 8, 2007 |
Updated: | May 21, 2008 |
| Description: |
Directory traversal vulnerability in index/mbox/mbox-storage.c in Dovecot
before 1.0.rc29, when using the zlib plugin, allows remote attackers to
read arbitrary gzipped (.gz) mailboxes (mbox files) via a .. (dot dot)
sequence in the mailbox name. |
| Alerts: |
|
Comments (none posted)
drupal: cross site request forgery
| Package(s): | drupal |
CVE #(s): | |
| Created: | July 27, 2007 |
Updated: | August 1, 2007 |
| Description: |
From DRUPAL-SA-2007-017:
"Several parts in Drupal core are not protected against cross site
request forgeries due to inproper use of the Forms API, or by taking action
solely on GET requests. Malicious users are able to delete comments and
content revisions and disable menu items by enticing a privileged users to
visit certain URLs while the victim is logged-in to the targeted
site." |
| Alerts: |
|
Comments (2 posted)
emacs21: denial of service
| Package(s): | emacs21 |
CVE #(s): | CVE-2007-2833
|
| Created: | June 21, 2007 |
Updated: | August 29, 2007 |
| Description: |
The emacs21 editor has a denial of service vulnerability.
emacs21 can be made to crash by viewing "certain types of images". |
| Alerts: |
|
Comments (none posted)
evolution: format string error
| Package(s): | evolution |
CVE #(s): | CVE-2007-1002
|
| Created: | March 27, 2007 |
Updated: | February 27, 2008 |
| Description: |
A format string error in the "write_html()" function in calendar/gui/
e-cal-component-memo-preview.c when displaying a memo's categories can
potentially be exploited to execute arbitrary code via a specially crafted
shared memo containing format specifiers. |
| Alerts: |
|
Comments (1 posted)
evolution-data-server: malicious server arbitrary code execution
| Package(s): | evolution-data-server |
CVE #(s): | CVE-2007-3257
|
| Created: | June 18, 2007 |
Updated: | November 7, 2007 |
| Description: |
From the GNOME
bugzilla: "The "SEQUENCE" value in the GData of the IMAP code
(camel-imap-folder.c) is converted from a string using strtol. This allows
for negative values. The imap_rescan uses this value as an int. It checks
for !seq and seq>summary.length. It doesn't check for seq <
0. Although seq is used as the index of an array." |
| Alerts: |
|
Comments (1 posted)
pop mail man-in-the-middle attacks
| Package(s): | evolution thunderbird mutt fetchmail |
CVE #(s): | CVE-2007-1558
|
| Created: | May 8, 2007 |
Updated: | August 7, 2007 |
| Description: |
The APOP protocol allows remote attackers to guess the first 3 characters
of a password via man-in-the-middle (MITM) attacks that use crafted message
IDs and MD5 collisions. NOTE: this design-level issue potentially affects
all products that use APOP, including (1) Thunderbird, (2) Evolution, (3)
mutt, and (4) fetchmail. |
| Alerts: |
|
Comments (none posted)
festival: privilege escalation
| Package(s): | festival |
CVE #(s): | |
| Created: | July 26, 2007 |
Updated: | August 1, 2007 |
| Description: |
The festival text-to-speech converter has a privilege escalation
vulnerability. The festival daemon runs with root privileges,
a local attacker can connect to to the daemon and execute arbitrary
commands as root. |
| Alerts: |
|
Comments (1 posted)
file: integer overflow
| Package(s): | file |
CVE #(s): | CVE-2007-2799
|
| Created: | June 1, 2007 |
Updated: | October 19, 2007 |
| Description: |
Colin Percival from FreeBSD reported that the previous fix for the
file_printf() buffer overflow introduced a new integer overflow. A remote
attacker could entice a user to run the file program on an overly large
file (more than 1Gb) that would trigger an integer overflow on 32-bit
systems, possibly leading to the execution of arbitrary code with the
rights of the user running file. |
| Alerts: |
|
Comments (3 posted)
firebird: buffer overflow
| Package(s): | firebird |
CVE #(s): | CVE-2007-3181
|
| Created: | July 2, 2007 |
Updated: | March 27, 2008 |
| Description: |
The Firebird DBMS has a buffer overflow vulnerability involving
the processing of connect requests with an overly large p_cnct_count
value. Remote attackers can send a specially crafted
request to the server in order to potentially execute arbitrary code with
the permissions of the Firebird user. |
| Alerts: |
|
Comments (none posted)
firefox: multiple vulnerabilities
| Package(s): | firefox |
CVE #(s): | CVE-2007-3844
CVE-2007-3845
|
| Created: | August 1, 2007 |
Updated: | February 20, 2008 |
| Description: |
A flaw was discovered in handling of "about:blank" windows used by
addons. A malicious web site could exploit this to modify the contents,
or steal confidential data (such as passwords), of other web pages.
(CVE-2007-3844)
Jesper Johansson discovered that spaces and double-quotes were
not correctly handled when launching external programs. In rare
configurations, after tricking a user into opening a malicious web page,
an attacker could execute helpers with arbitrary arguments with the
user's privileges. (CVE-2007-3845) |
| Alerts: |
|
Comments (none posted)
firefox: multiple vulnerabilities
| Package(s): | firefox mozilla seamonkey thunderbird |
CVE #(s): | CVE-2007-1362
CVE-2007-2867
CVE-2007-2868
CVE-2007-2869
CVE-2007-2870
CVE-2007-2871
|
| Created: | June 4, 2007 |
Updated: | August 29, 2007 |
| Description: |
Various flaws were discovered in the layout and JavaScript engines. By
tricking a user into opening a malicious web page, an attacker could
execute arbitrary code with the user's privileges. (CVE-2007-2867,
CVE-2007-2868)
A flaw was discovered in the form autocomplete feature. By tricking a user
into opening a malicious web page, an attacker could cause a persistent
denial of service. (CVE-2007-2869)
Nicolas Derouet discovered flaws in cookie handling. By tricking a user
into opening a malicious web page, an attacker could force the browser to
consume large quantities of disk or memory while processing long cookie
paths. (CVE-2007-1362)
A flaw was discovered in the same-origin policy handling of the
addEventListener JavaScript method. A malicious web site could exploit
this to modify the contents, or steal confidential data (such as
passwords), of other web pages. (CVE-2007-2870)
Chris Thomas discovered a flaw in XUL popups. A malicious web site
could exploit this to spoof or obscure portions of the browser UI,
such as the location bar. (CVE-2007-2871) |
| Alerts: |
|
Comments (3 posted)
firefox, thunderbird, seamonkey: multiple vulnerabilities
| Package(s): | firefox, thunderbird, seamonkey |
CVE #(s): | CVE-2007-3738
CVE-2007-3656
CVE-2007-3670
CVE-2007-3285
CVE-2007-3737
CVE-2007-3089
CVE-2007-3736
CVE-2007-3734
CVE-2007-3735
|
| Created: | July 18, 2007 |
Updated: | May 12, 2008 |
| Description: |
shutdown and moz_bug_r_a4 reported two separate ways to modify an
XPCNativeWrapper such that subsequent access by the browser would result in
executing user-supplied code. (CVE-2007-3738)
Michal Zalewski reported that it was possible to bypass the same-origin
checks and read from cached (wyciwyg) documents It is possible to access
wyciwyg:// documents without proper same domain policy checks through the
use of HTTP 302 redirects. This enables the attacker to steal sensitive
data displayed on dynamically generated pages; perform cache poisoning; and
execute own code or display own content with URL bar and SSL certificate
data of the attacked page (URL spoofing++). (CVE-2007-3656)
Internet Explorer calls registered URL protocols without escaping quotes
and may be used to pass unexpected and potentially dangerous data to the
application that registers that URL Protocol. (CVE-2007-3670)
Ronald van den Heetkamp reported that a filename URL containing %00
(encoded null) can cause Firefox to interpret the file extension
differently than the underlying Windows operating system potentially
leading to unsafe actions such as running a program. This is only
accessible locally. (CVE-2007-3285)
An attacker can use an element outside of a document to call an event
handler allowing content to run arbitrary code with chrome
privileges. (CVE-2007-3737)
Ronen Zilberman and Michal Zalewski both reported that it was possible to
exploit a timing issue to inject content into about:blank frames in a
page. When opening a window from a script, it is possible to spoof the
content of the newly opened window's frames within a short time frame,
while the window is loading. (CVE-2007-3089)
Mozilla contributor moz_bug_r_a4 demonstrated that the methods
addEventListener and setTimeout could be used to inject script into another
site in violation of the browser's same-origin policy. This could be used
to access or modify private or valuable information from that other
site. (CVE-2007-3736)
As part of the Firefox 2.0.0.5 update releases Mozilla developers fixed
many bugs to improve the stability of the product. Some of these crashes
that showed evidence of memory corruption under certain circumstances and
we presume that with enough effort at least some of these could be
exploited to run arbitrary code. Note: Thunderbird shares the browser
engine with Firefox and could be vulnerable if JavaScript were to be
enabled in mail. This is not the default setting and we strongly discourage
users from running JavaScript in mail. Without further investigation we
cannot rule out the possibility that for some of these an attacker might be
able to prepare memory for exploitation through some means other than
JavaScript, such as large images. (CVE-2007-3734, CVE-2007-3735) |
| Alerts: |
|
Comments (none posted)
flac123: arbitrary code execution
| Package(s): | flac123 |
CVE #(s): | CVE-2007-3507
|
| Created: | July 13, 2007 |
Updated: | October 22, 2007 |
| Description: |
A stack-based buffer overflow in the local__vcentry_parse_value function in
vorbiscomment.c in flac123 (aka flac-tools or flac) before 0.0.10 allows
user-assisted remote attackers to execute arbitrary code via a large
comment value_length. |
| Alerts: |
|
Comments (none posted)