LWN.net Logo

LWN.net Weekly Edition for November 21, 2007

GCC unplugged

By Jonathan Corbet
November 19, 2007
Many programs - free and proprietary - offer a plug-in interface to make it easy to add new functionality. In many situations, the existence of a well-defined plugin interface has been a key driver for the success of the system as a whole; imagine Firefox, for example, without its extension mechanism. The GNU compiler collection (GCC) is an example of a complex system which could benefit from such an interface, but which currently lacks one. GCC developers have been talking about adding a plugin API, but it is far from clear that this will be done; how this decision goes may have major consequences for how GCC works with its wider development community and the free software community as a whole.

GCC is designed as an extended pipeline of cooperating modules. Language-specific front-end code parses code in a specific source language and turns it into a generic, high-level, internal representation. Various optimization passes then operate on that representation at various levels. At the back end, an architecture-specific module turns the optimized internal code into something which will run on the target processor. It's a long chain of modules; at each point in the chain, there is an opportunity to see the code in a different stage of analysis and processing.

There can be a lot of value in hooking into an arbitrary point in that chain. Static analysis tools need to look at a program at different levels to get a sense for what is going on and look for problems or opportunities for improvement. New types of optimization passes could be added at specific points, making the compiler perform better. Project-specific modules could look for problems (violations of locking rules, perhaps) tied to a given code base. Language-specific modules can provide tighter checking for certain constructs. And so on.

Currently, adding this sort of extension to GCC is not a task for the faint of heart. The GCC build system is known to be challenging, and GCC's internal documentation is, one might say, not quite as complete as one might like. Researcher Alexander Lamaison described it this way:

Out of the 6 months, 4 were spent learning the GCC internals and fighting the GCC build process, 1 was spent writing up leaving 1 month of actual productive research... I fully understand that this can seems strange to people who know GCC like the back of their hand, but to a newcomer it is a huge task just to write a single useful line of code. I'm sure many give up before ever reaching that point.

Once they have overcome these problems, developers adding extensions to GCC run into another problem: if they want to distribute their work, they end up in the business of shipping a whole new compiler. Brendon Costa, who works on the EDoc++ GCC extension, noted:

I approached the debian maintainers list with a debian package for this project to see if they would include it in the official repositories. It was not accepted and the reason for that is because it includes another patched version of GCC which takes up too much disk space. They don't want to accept these sorts of projects because they all effectively require duplicates of the same code(GCC)

Both of these problems could be addressed by adding a plugin mechanism to GCC. A well-defined API would make it relatively easy for developers to hook a new tool into the compiler without having to understand its internals or fight with the build process. If an off-the-shelf GCC could accept plugins, distributors could ship those plugins without having to include multiple copies of the compiler. Given that we would all benefit from a more capable GCC, and given the many examples of how other systems have benefited from a plugin architecture, one would think that the addition of plugins to GCC would not be a controversial thing.

It seems that one would be wrong, however. In a recent discussion on plugins, two concerns were raised:

  • Adding plugins to GCC would make it easy for people to create and distribute proprietary enhancements.

  • A plugin API would have to be maintained in a stable manner, possibly impeding further GCC development.

There were also some suggestions that, if the effort put into a plugin API were, instead, put into documentation of GCC internals, the overall benefit would be much higher.

The proprietary extensions concern is clearly the big stumbling block, though. Some participants stated that Richard Stallman has blocked any sort of GCC plugin mechanism for just this reason - though it should be noted that Mr. Stallman has not contributed directly to this discussion. But, given that GCC remains a GNU project, it is not hard to imagine anything which could lead to proprietary versions of GCC would encounter a high level of opposition.

The attentive reader may have spied some similarities between this discussion and the interminable debate over kernel modules. The kernel's plugin mechanism has certainly enabled the creation of proprietary extensions. In the GCC case, it has been suggested that any plugins would have to be derived products and, thus, covered by the GPL. This, too, is an argument which has been heard in the kernel context. In that case, concerns over the copyright status of proprietary modules have kept them out of most distributions and, in general, cast a cloud over those modules. Something similar would probably happen to proprietary GCC modules: they would not be widely distributed, would be the subject of constant criticism, and would be an impetus for others to replace them with free versions. It is hard to imagine that there would be a thriving market for proprietary GCC extensions, just like there is no real market for proprietary GIMP extensions - even though Photoshop has created just that kind of market.

It has also been pointed out that the status quo has not prevented the creation of proprietary GCC variants. As an example, consider GCCfss - GCC for Solaris systems. This compiler is a sort of Frankenstein-like grafting of the GCC front end onto Sun's proprietary SPARC code generator. Back when Coverity's static analysis tools were known as the "Stanford checker," they, too, were a proprietary tool built on top of GCC (the current version does not use GCC, though). People wanting to do proprietary work with GCC have been finding ways to do so even without a plugin mechanism.

The GCC developers could also look to the kernel for an approach to the API stability issue and simply declare that the plugin API can change. That would make life harder for plugin developers and distributors, but it would make it even harder for any proprietary plugin vendors. An unstable API would not take away the value of the plugin architecture in general, but it would avoid putting extra demands onto the core GCC developers.

In general, GCC is at a sort of crossroads. There are a number of competing compiler projects which are beginning to make some progress; they are a long way from rivaling GCC, but betting against the ability of a free software project to make rapid progress is almost never a good idea. There is a pressing need for better analysis tools - it is hard to see how we will make the next jump in code quality without them. Developers would like to work on other enhancements, such as advanced optimization techniques, but are finding that work hard to do. If GCC is unable to respond to these pressures, things could go badly for the project as a whole; GCC developer Ian Lance Taylor fears the worst in this regard:

I have a different fear: that gcc will become increasing irrelevant, as more and more new programmers learn to work on alternative free compilers instead. That is neutral with regard to freedom, but it will tend to lose the many years of experience which have been put into gcc. In my view, if we can't even get ourselves together to permit something as simple as plugins with an unstable API, then we deserve to lose.

Back at the beginning of the GNU project, Richard Stallman understood that a solid compiler would be an important building block for his free system. In those days, even the creation of a C compiler looked like an overly ambitious project for volunteer developers, but he made GCC one of his first projects anyway (once the all-important extensible editor had been released). His vision and determination, combined with a large (for the times) testing community with a high tolerance for pain, got the job done. When Sun decided that a C compiler was no longer something which would be bundled with a SunOS system, GCC was there to fill in the gap. When Linus created his new kernel, GCC was there to compile it. It is hard to imagine how the free software explosion in the early 1990's could have happened without the GCC platform (and associated tool chain) to build our code with.

The vision and determination that brought us GCC has always been associated with a certain conservatism which has held that project back, though. In the late 1990's, frustration with the management of GCC led to the creation of the egcs compiler; that fork proved to be so successful that it eventually replaced the "official" version of GCC. If enough developers once again reach a critical level of frustration, they may decide to fork the project anew, but, this time, there are other free compiler projects around as well. Perhaps, as some have suggested, better documentation is all that is really required. But, somehow, the GCC developers will want to ensure that all the energy which is going into improving GCC doesn't wander elsewhere. GCC needs that energy if it is to remain one of the cornerstones of our free system.

Comments (50 posted)

Piecing together free java

November 20, 2007

This article was contributed by Mark Wielaard

The libre-java movement got a huge boost on November 13 2006, "Java Liberation Day". On that day, Sun announced its intent to distribute all the source code for their implementations of Java Standard Edition (SE, code name OpenJDK), Enterprise Edition (EE, code name Glassfish) and Micro Edition (ME, code name PhoneME) as free software. All are licensed under the GPL, using the classpath exception clause for selected libraries.

Sun went out of its way to make its commitment to the GPL, with everything it implies, very clear in an extensive FAQ. Two things, unrelated to source code, are reserved: the specification and certification of Java is reserved for the JCP (Java Community Process), while Sun controls the usage of the Java(TM) trademark. Everybody is free to run, copy, distribute, study, change, share and improve the source code for any purpose as long as they follow the tit-for-tat, share-alike, copyleft rules of the GPL for all the code they release.

Sun not only contacted big Free Software names, like Richard Stallman and Eben Moglen, before the event, the company also made sure that the existing libre-java communities knew about the plans before it all hit the press. Jonathan Schwartz, the Sun CEO, himself explicitly reached out to the existing GNU Classpath, GCJ and Kaffe communities with an offer to collaborate with the developers making libre-java on GNU/Linux a reality. The Sun OpenJDK engineers came to the Fosdem conference to have a DevJam and share their ideas with the existing libre-java communities.

Sun couldn't liberate all the code at once, but did so in stages for anything it could get all the rights to over the last year. At the same time, Sun has been slowly opening up the internal development process and switching to a public repository for all the code (Kelly O'Hair keeps a blog that is a great case study for moving a large project to Mercurial). Currently all code for Glassfish and phoneME have been released, while about 96% of the OpenJDK code base is available (almost all the parts not released yet are because Sun couldn't get the rights from some third party). Rich Sands gives a great overview of how all this looked from inside Sun in his one year retrospective on java liberation day.

Meanwhile, an effort called IcedTea was started to put OpenJDK into GNU/Linux distributions by moving it quickly towards that 100% free software line. As Andrew Haley explained during the official announcement, it is an experimental build tree that tries to stay close to the OpenJDK upstream but does not contain any non-free proprietary blobs. Those pieces are either stubbed out or replaced with code from GNU Classpath. IcedTea can be built using only free software. In particular, you can use GCJ for the first build phase to bootstrap those parts that depend on a working java compiler and runtime. It can be easily built on a modern GNU/Linux distribution with a simple ./configure && make; or at least that is the theory. It builds out of the box on Fedora 7 or 8. For Debian and Gentoo some additional steps are still needed.

Because OpenJDK didn't have a open bug database and (until recently) a source code repository, IcedTea has an open public bugtracker and a mercurial repository. All discussions about the code are done on the public OpenJDK distro-pkg-dev mailing list.

IcedTea is what most GNU/Linux distributions ship now for x86 and x86_64 in addition to GCJ for other architectures. IcedTea also adds some things that make things easier for distribution packagers. It adds patches so that the runtime and core libraries link to system shared libraries, like zlib and libjpeg, which should make security updates simpler. It adds support for using things like the system wide tzdata files for the TimeZone utility classes. It also supports using the system installed certificate authority files for security related checks as used in the ssl network classes. Thomas Fitzsimmons, who helped with the above items, keeps a Packager's Wishlist for OpenJDK.

IcedTea also contains some bug fixes from people who submitted patches to the OpenJDK upstream, which haven't been accepted yet, to give them a wider testing audience. Others have offered alternative backends for existing packages that make java applications integrate better in a GNU/Linux system. An example is the GConf backend for the java.util.prefs package by Mario Torre, which he ported from GNU Classpath.

Lastly, IcedTea is a testbed for porting OpenJDK to other architectures beyond the currently supported x86, x86_64 and sparc. There are two different approaches. The first is to start with the Hotspot C++ Interpreter. HotSpot is the runtime of OpenJDK and actually contains another byte code interpreter by default, the Template Interpreter which is a bit harder to port. After requests from the community, Sun also released its older C++ based interpreter to help the porting effort. Gary Benson recently made a breakthrough and got that working for PowerPC (both 32 and 64 bit). He wrote a guide to porting IcedTea that will hopefully help people porting to other architectures. Of course the interpreter alone is slow, but the benefit is that you get a full system up and running that is similar to the existing architectures with full support for all features. The next step is to add support for the HotSpot just-in-time (JIT) compilers, which will be a lot of work.

Another approach is taken by the Cacao team who are working on replacing the whole HotSpot runtime with a libjvm.so based on the Cacao JITs, but reusing all of the core libraries. This now works for s390 and powerpc. Cacao also supports alpha, arm and mips, so this is an interesting path for getting a faster port. You will have to replace all of the Hotspot runtime to get it. The Cacao VM is still missing some features, like annotations and full debugging support.

There are some other interesting developments around former GNU Classpath-based projects that are now experimenting with combining their code and the new OpenJDK and/or PhoneME projects. Dalibor Topic worked on a Google Summer of Code project to make the OpenJDK javac compiler a source-to-bytecode front end for the GCJ native compiler. The MIDPath project combines elements of SE and ME, plus different backends (SDL, FB, AWT, X11, Gtk+ and Qt) to provide access to MIDP2, a mobile devices standard used on many phones for various platforms. JaLiMo provides all of the above packaged for the Maemo and OpenMoko platforms. JNode is a full operating system written in java that is now built upon a hybrid of OpenJDK and GNU Classpath libraries. There is also the IKVM project that is providing a java implementation, translation and interoperability framework for .net implementations like Mono.

With all this one could safely say that The Java Trap has been dismantled. But even with some replacements from GNU Classpath, IcedTea/OpenJDK is still missing some small parts. The java.sound implementation isn't complete, but Sun released the parts so it could. The Java Management Extensions (JMX) implementation is missing SNMP support. Applets are currently supported through gcjwebplugin, which has the benefit that there is finally a 64-bit plugin, but it is still missing LiveConnect (Java/JavaScript integration). And finally there is no support yet for Java Network Launch Protocol (JNLP aka Java Web Start), although there is netx, which might be added to IcedTea soon.

So when you put all the above together, what Java version do we get? Officially what the GNU/Linux distributions ship now isn't Java(TM) since it isn't certified. And IcedTea comes with the following warning:

IcedTea is derived from OpenJDK, Sun's open-source implementation of the Java SE platform. At this time the build from which IcedTea was constructed corresponds to an early build (b21) of JDK 7. When JDK 7 is complete it will implement the Java SE 7 Platform Specification. Work on that specification is underway, but far from final. Any APIs in the JDK 7 implementation, whether new or old, are therefore subject to minor adjustments, major revisions, or even outright removal between now and the time that the Java SE 7 Platform Specification is finalized. Please take these facts into account before depending upon IcedTea.

Red Hat has recently signed the OpenJDK Community TCK License Agreement. This gives them access to the test suite that determines whether an implementation that is derived from the OpenJDK project complies with the Java SE 6 specification. This will cover the binary releases that they ship (while the source code will of course still be available under the GPL). This agreement does, however, contain an NDA which prevents talking about how compatible the current code is. The test compatibility kit itself is still proprietary, so it will be hard to work together with the community at large on this.

One year after Java Liberation Day modern GNU/Linux distributions are starting to ship with a more complete free java-like stack than ever before, but there are still some small loose ends to tie up. It was a learning experience for all communities involved as suddenly the whole free java ecosystem changed. There was certainly a lot of frustration about the speed with which things opened up. On the other side, there was frustration with the fact that shipping something purely-free seemed more important than compatibility. But Sun consistently kept its promises about opening up. The existing libre-java communities learned to respect and take advantage of the now free reference implementation of the code that they worked so hard to replace over the last decade. Now the fruits of collaboration and reusing each others code is materializing. In less than another year, it will be common to have a full, free, java stack, either SE, ME or EE, wherever you find GNU/Linux running.

[ Mark Wielaard has been doing libre-java development since 1999. He is also the maintainer of GNU Classpath. He is currently employed as an engineer by Red Hat on non-java related projects. ]

Comments (12 posted)

An interview with a Mozilla evangelist

By Jake Edge
November 20, 2007

Long-time Red Hat employee and Mozilla contributor Christopher Blizzard recently took a new job as a member of the Evangelism team at Mozilla Corporation. Just settling in – he started just over a week ago – he graciously agreed to be interviewed. His answers provide a look at evangelism at Mozilla, what his role will be, along with a bit of a retrospective on his days at Red Hat.

LWN: What does it mean to be on the Evangelism team at Mozilla? What kinds of things does the team do?

The Evangelism team at Mozilla has quite a few roles to play. We handle a lot of external communications, including some amount of press, although there's a separate press team that handles most of that. Sometimes it's tactical – responding to a bad blog entry or press result and repairing misleading facts or conclusions when that's possible. But it's strategic as well in the sense that we try and understand and compose the story of Mozilla into a consumable form and then try and tell that to the world. Mozilla has a good story to tell and helping people understand who we are and what we're doing opens doors both for us and for others. It's an important role in any organization, but especially ours.

We also do a bit of internal communications facilitating as well. As the project and the company grow past certain sizes that kind of "internal understanding" role is going to be more and more critical. Organizations that don't understand themselves get into trouble in pretty short order. We're around to keep that from happening as best we can. Think of it as guarding the culture as new people come on board.

We also do a lot of technical evangelism as well. Just as examples you can see that work in Mark Finkle's weblog where he does a lot of work describing add-ons and extensions and what's going on in that area. John Resig also does a lot of work telling the story of JavaScript and the upcoming ES4 work to the world as well. Asa Dotzler and Seth Bindernagel do a lot of work with the community directly while Deb Richardson and Eric Shepherd both do a lot of work on documentation and external communications.

We're a diverse group with a lot of different roles, but that's the nature of the audiences we face.

But these systems are under attack by companies like Microsoft and Adobe, attempting to replace them with a proprietary platform under the control of a single company. These represent an attack on the web itself, and should be taken very seriously. LWN: What are your specific near-term tasks as part of the team?

My role is really to figure out how to work with other open source projects and help them figure out how to properly leverage what we're doing in Mozilla. This includes organizational development. For example, we are a non-profit, public benefit organization that acts like a business. But we are also an open source project with a very active non-corporate contributor base, targets a consumer market and has a strong product focus and over 100 million users - we would love to see that replicated in other places as well and we would love the chance to teach others how to do it.

We also share a common alignment with a huge number of other open source projects. Open source projects require an open playing field to build on. These usually take the form of "open standards" and right now form the basis of the web that we see today, and many of the forms of communication used on the Internet. HTTP, HTML, CSS, SMTP, Jabber, etc. These were standards that anyone was able to implement and saw an explosive growth in use as a result. But these systems are under attack by companies like Microsoft and Adobe, attempting to replace them with a proprietary platform under the control of a single company. These represent an attack on the web itself, and should be taken very seriously. Remember that the web is still the killer app, and keeping that open and protected is paramount.

Our role has to be larger than just delivering a browser that normal people can use. We also have to push the web itself forward to make sure that it remains competitive against other platforms and is the platform of choice for development. This means evolving the languages that the web uses, adding capabilities to the browser itself (video, audio, canvas, SVG, others) and then putting it into a consumable package that people love to use on the widest possible set of platforms.

That's the context for my role. What I will try and do is to make sure that well-aligned open source projects understand this story and know what we're doing on the ground so that we can help them and they can help us. Mozilla has a huge footprint of users and we want to make sure that other open source projects know how to take advantage of that. What this actually means in terms of actions is still something that's being figured out but we'll start to see movement in the next few weeks.

There are some easy first steps. First steps include helping with our embedded and mobile stories (where open source and Linux have a lot of leverage) and sparking discussions on performance and footprint. I will also continue with my Linux role and act as a contact for the Linux distributions that are shipping Firefox and Mozilla technologies today.

LWN: Are there specific ways that you will be using your Red Hat and Linux background in your new job?

I was at Red Hat for nearly 9 years, and I am a vastly changed person as a result of that time, so of course! But a lot of the work that I did there will be used indirectly. I learned a lot of things at Red Hat. I learned to think strategically, how to build and run teams, what makes successful projects and a nearly rabid devotion to building products that really help the people who are using them. How important design and a user focus is to building a successful product. The incredible importance of brand in the development of products and how to build messaging around that. I learned some important lessons about how to mix business and open source projects. That recognizing companies is an incredibly important part of making many projects successful and cultivating those relationships can create wins on both sides. I learned that open source itself isn't a business model, but requires a different way to think about how you deliver value to people and organizations. But the most important thing that I probably walked away with was that the most important factor that seems to make an organization successful (aside from having a market to work in!) is the people that you bring to the table. Red Hat was filled with wonderful people, and still is. I take that lesson to heart in choosing the people around me and who I will try and bring to Mozilla as well. It's incredibly important.

LWN: Will you still be involved in OLPC development? In an official capacity as part of your job with Mozilla? What kinds of things will you be working on?

I certainly won't be involved to the same level I was. I had day to day involvement in the software development and design process and what OLPC will deliver to the public is something that I both deserve much of the credit and much of the blame for. There are still some touch points with OLPC from time to time, largely around the browser that's included on the OLPC machine, but I'm not that involved with them right now.

I decided it was time to go somewhere that would let me affect a lot of people and create some leverage for open source. Mozilla is that place. LWN: What led to deciding to leave Red Hat after so many years?

The answer to that question is complicated and deeply personal. Some small part of it was just employment diversification. I had been there for 9 years, which is a huge portion of my young life, and I felt like I should experience something else.

But it was also a question of leverage for me. Red Hat is an enterprise company. They are doing well in that market and are doing a great job of developing value for that customer segment and bringing the story of open source along with them. The are a committed organization and are well-liked and continue to make good decisions.

But they aren't going to be able to change the world from the back office and have become far too conservative over the years to go out and touch human beings directly. And they aren't going to be large enough any time soon to be able to have credible experiments to grow into a "consumer" market. I learned that the hard way with both OLPC and Mugshot and I decided it was time to go somewhere that would let me affect a lot of people and create some leverage for open source. Mozilla is that place.

But, really, that question should be "why Mozilla?" Mozilla is still a pretty small organization, less than 150 people. I feel like I have a lot to bring to the organization, both based on my experience inside of Mozilla (which is longer than my Red Hat experience!) and from my work at Red Hat. Mozilla is trying to create change in the world in a very real way by touching people directly, and doing so using open source methodologies under the umbrella of a public benefit company. They have a fantastic team from the top to the bottom of the organization, want to compete and want to keep their users winning by creating a great product that protects the web. It's unique in the market, and I hope to do my part to keep it that way.

LWN: What things do you look back on that you did at Red Hat that you are most pleased with? Are there things you would have done differently?

I've always been pretty happy with the desktop work that happened at Red Hat. These days Ubuntu gets most of the credit for the Linux Desktop but it was _clearly_ Red Hat (and Ximian/Novell!) that did much of the heavy lifting to get it from where it was in the mid-1990s to where it is today, and that is still the case. GNOME in particular would have not gotten past the stages of its infancy without Red Hat's early involvement, and I like where it's gotten today. (Anyone else remember GNOME 0.27?) I had a part to play there with my early Mozilla development work, which I very carefully selected for that reason, and I think that helped things get on the right track. It was a good decision and I really like the outcome.

The OLPC work was quite satisfying. If not only because of the proposed effect - helping millions of poor kids gain a foothold in the world of knowledge that I take for granted every day - but also because I was able to take that decade of knowledge of what was broken in computing and apply it. A lot of what you will see in OLPC is a result of that, sometimes with me acting as the guy driving ideas and sometimes acting as a champion for the ideas of others. I can take some solace that even though I'm not working on it today, a lot of that work I can point at as my own. I hope that many of the other team members feel the same way.

But I made a huge number of mistakes. I passed on some very early leadership opportunities where I probably could have made an earlier difference and pushed things harder. Failing to grow out of an early engineering position and thinking about wider issues around teams, users, strategy, markets and business. I should have done that earlier and I think that if I had, we would all be a little better off.

But on reflection, it would be hard to point to many things that I would want to change. It's still a good company and I am happy to have worked there.

Our thanks to Christopher for taking time to respond, especially during his, probably rather busy, first week on the job.

Comments (17 posted)

Page editor: Jonathan Corbet

Security

Fingerprint recognition using fprint

By Jake Edge
November 20, 2007

Fingerprint scanners are becoming more commonplace, especially on laptops, to add a layer of biometric authentication. Linux support for these devices has been somewhat varied, with each scanner model supported by its own driver and API, or not supported at all. In addition, a number of the drivers are closed source; something that should worry anyone installing security software. The fprint project aims to change that by providing a standardized API for as many different scanners as it can.

Born out of a Computer Science academic project for founder Daniel Drake, fprint was released this month under the LGPL. Unlike other scanner projects, fprint is not targeted at a specific device, it supports quite a few using a half-dozen or so different drivers. The drivers, as the name would imply, handle the low-level details of talking to the devices using libusb.

Fingerprint scanners all work differently; some process the image of the print internally, while others present the image to the driver. In order to have a standard API, regardless of the scanner used, the libfprint library handles those differences internally. If required, it uses image processing code from the US National Institute of Standards and Technology that is specifically designed for fingerprint matching.

In order to use fingerprints for authentication, there must be a training or enrollment mode where the scanned fingerprint is stored away for later use. Once that has been done, fingerprints can be verified for a particular user. fprint does not yet support identification mode, where an unknown finger is scanned and a database of stored prints is checked for a match. The current code requires a username or other identifier, comparing the print stored for that user with the one scanned.

Because it handles multiple devices, there could be occasions where there is a print stored for a particular user, but it was scanned with a different device. Some fprint drivers can handle multiple similar scanners, so it distinguishes between them using a device type assigned by the driver. It tags each stored print with the driver ID as well as the device type. To be comparable, the prints must have come from the same driver with the same device type.

Application writers do not want to have to interface to multiple different library APIs to support fingerprint authentication. The libfprint API provides a single interface for applications. All phases of dealing with the scanners are available through the API: device discovery, print enrollment, print discovery, and verification. In addition, pam_fprint has integrated with Pluggable Authentication Modules (PAM) to handle logging in via fingerprint instead of password.

There are other projects out there solving similar problems, but none seems to have taken the big picture view that fprint has. The Debian FingerForce team has gathered a list of Linux fingerprint scanning solutions, most of which are specific to a particular scanner or family of scanners. BioAPI also tries to abstract away the specifics of biometric authentication, but it is not a free standard.

By trying to support as many scanners as they can, while providing a generic interface, fprint seems to have the right approach to fingerprint authentication. There is still plenty to be worked on, fingerprint data is currently stored unencrypted for example, but the approach seems sound. For anyone with a scanner on their laptop, or a USB version that they carry around, applications supporting fprint will be very welcome. Anyone creating software that is interested in supporting fingerprint authentication, will definitely want to give fprint a look.

Comments (18 posted)

Security news

Wordpress Cookie Authentication Vulnerability

A Wordpress cookie vulnerability exploit is floating around in the wild according to the advisory (Full Story link below). Anyone who has (or can get) access to the wp_users table can authenticate as any user, including the administrative user. Passwords are stored in the table as MD5 hashes, but the cookies contain the MD5 of that value (i.e. a double MD5 of the password). Attackers just need to provide the MD5 of the value they find in the database in a cookie to be authenticated as that user. There is no patch and there are no very satisfactory workarounds other than changing every user password and ensuring that no one can access the database after that.

Full Story (comments: 22)

Schneier: The Strange Story of Dual_EC_DRBG

Bruce Schneier has posted an interesting look at a U.S. random number generator standard. "What Shumow and Ferguson showed is that these numbers have a relationship with a second, secret set of numbers that can act as a kind of skeleton key. If you know the secret numbers, you can predict the output of the random-number generator after collecting just 32 bytes of its output. To put that in real terms, you only need to monitor one TLS internet encryption connection in order to crack the security of that protocol. If you know the secret numbers, you can completely break any instantiation of Dual_EC_DRBG."

Comments (4 posted)

Google as a password cracker (Light Blue Touchpaper)

Light Blue Touchpaper covers a somewhat surprising use of Google to crack Wordpress passwords. Other passwords stored as hashed values without salt would also be vulnerable to this kind of search. "Instead, I asked Google. I found, for example, a genealogy page listing people with the surname 'Anthony', and an advert for a house, signing off 'Please Call for showing. Thank you, Anthony'. And indeed, the MD5 hash of 'Anthony' was the database entry for the attacker. I had discovered his password."

Comments (6 posted)

New vulnerabilities

apache2: denial of service

Package(s):apache2 CVE #(s):CVE-2007-1863
Created:November 19, 2007 Updated:February 18, 2008
Description:

From the CVE entry:

cache_util.c in the mod_cache module in Apache HTTP Server (httpd), when caching is enabled and a threaded Multi-Processing Module (MPM) is used, allows remote attackers to cause a denial of service (child processing handler crash) via a request with the (1) s-maxage, (2) max-age, (3) min-fresh, or (4) max-stale Cache-Control headers without a value.

Alerts:
Fedora FEDORA-2008-1711 2008-02-15
SuSE SUSE-SA:2007:061 2007-11-19

Comments (1 posted)

bochs: denial of service

Package(s):bochs CVE #(s):CVE-2007-2894
Created:November 19, 2007 Updated:November 20, 2007
Description:

From the CVE entry:

The emulated floppy disk controller in Bochs 2.3 allows local users of the guest operating system to cause a denial of service (virtual machine crash) via unspecified vectors, resulting in a divide-by-zero error.

Alerts:
Gentoo 200711-21 2007-11-17

Comments (none posted)

mailman: error log spoof

Package(s):mailman CVE #(s):CVE-2006-4624
Created:November 15, 2007 Updated:November 20, 2007
Description: The Mailman mailing list manager is vulnerable to log file spoofing. A remote attacker can insert carriage return/line feed sequences, causing invalid error log messages to be recorded. This makes it possible to trick the administrator into visiting malicious URLs.
Alerts:
Red Hat RHSA-2007:0779-02 2007-11-15

Comments (1 posted)

MySQL: denial of service

Package(s):mysql CVE #(s):CVE-2007-5925
Created:November 19, 2007 Updated:February 8, 2008
Description:

From the CVE entry:

The convert_search_mode_to_innobase function in ha_innodb.cc in the InnoDB engine in MySQL 5.1.23-BK and earlier allows remote authenticated users to cause a denial of service (database crash) via a certain CONTAINS operation on an indexed column, which triggers an assertion error.

Alerts:
SuSE SUSE-SR:2008:003 2008-02-07
Ubuntu USN-559-1 2007-12-21
Red Hat RHSA-2007:1157-01 2007-12-19
Fedora FEDORA-2007-4471 2007-12-15
Mandriva MDKSA-2007:243 2007-12-10
Fedora FEDORA-2007-4465 2007-12-15
Red Hat RHSA-2007:1155-01 2007-12-18
Gentoo 200711-25 2007-11-18
Debian DSA-1413-1 2007-11-26

Comments (none posted)

net-snmp: denial of service

Package(s):net-snmp CVE #(s):CVE-2007-5846
Created:November 16, 2007 Updated:February 7, 2008
Description: A flaw was discovered in the way net-snmp handled certain requests. A remote attacker who can connect to the snmpd UDP port (161 by default) could send a malicious packet causing snmpd to crash, resulting in a denial of service.
Alerts:
Debian DSA-1483-1 2008-02-06
Ubuntu USN-564-1 2008-01-09
SuSE SUSE-SR:2007:025 2007-12-05
Gentoo 200711-31 2007-11-20
Mandriva MDKSA-2007:225 2007-11-19
Red Hat RHSA-2007:1045-01 2007-11-15
Fedora FEDORA-2007-3019 2007-11-20

Comments (none posted)

openssh: log file corruption

Package(s):openssh CVE #(s):CVE-2007-3102
Created:November 15, 2007 Updated:November 20, 2007
Description: The ssh server can incorrectly write account names to the audit subsystem. A remote attacker can inject strings with parts of audit messages in order to corrupt logs. This can mislead administrators and confuse log parsing tools.
Alerts:
Red Hat RHSA-2007:0703-02 2007-11-15
Red Hat RHSA-2007:0737-02 2007-11-15

Comments (1 posted)

pcre: CVE consolidation

Package(s):pcre CVE #(s):CVE-2005-4872 CVE-2006-7227 CVE-2006-7224
Created:November 15, 2007 Updated:May 13, 2008
Description: PCRE has flaws in the way it handles malformed regular expressions. If an application linked against PCRE, such as Konqueror, encounters a maliciously created regular expression, it may be possible to run arbitrary code. Vulnerabilities CVE-2005-4872 and CVE-2006-7227 have been combined into CVE-2006-7224.
Alerts:
Gentoo 200805-11 2008-05-12
Debian DSA-1570-1 2008-05-06
Mandriva MDVSA-2008:030 2008-01-31
SuSE SUSE-SA:2008:004 2008-01-29
Gentoo 200711-30 2007-11-20
SuSE SUSE-SA:2007:062 2007-11-23
Red Hat RHSA-2007:1052-02 2007-11-15

Comments (5 posted)

php5: multiple vulnerabilities

Package(s):php5 CVE #(s):CVE-2007-4783 CVE-2007-4840 CVE-2007-5898 CVE-2007-5899 CVE-2007-5900
Created:November 20, 2007 Updated:July 24, 2008
Description: The php5 package contains multiple vulnerabilities, the most serious of which involve several Denial of Service attacks (application crashes and temporary application hangs). It is not currently known that these vulnerabilities can be exploited to execute malicious code.
Alerts:
Ubuntu USN-628-1 2008-07-23
CentOS CESA-2008:0545 2008-07-16
CentOS CESA-2008:0544 2008-07-16
Red Hat RHSA-2008:0545-01 2008-07-16
Red Hat RHSA-2008:0546-01 2008-07-16
Red Hat RHSA-2008:0544-01 2008-07-16
Red Hat RHSA-2008:0582-01 2008-07-22
Mandriva MDVSA-2008:127 2008-07-03
Mandriva MDVSA-2008:125 2008-07-03
Mandriva MDVSA-2008:126 2007-07-03
Red Hat RHSA-2008:0505-01 2008-07-02
Fedora FEDORA-2008-3606 2008-06-20
Fedora FEDORA-2008-3864 2008-06-20
SuSE SUSE-SA:2008:004 2008-01-29
Debian DSA-1444-2 2008-01-23
Debian DSA-1444-1 2008-01-03
Ubuntu USN-549-2 2007-12-03
rPath rPSA-2007-0242-1 2007-11-19
Ubuntu USN-549-1 2007-11-29

Comments (none posted)

php-pear-MDB2: URL injection

Package(s):php-pear-MDB2-Driver-mysql CVE #(s):CVE-2007-5934
Created:November 16, 2007 Updated:December 10, 2007
Description: The PEAR MDB2 in versions prior to 2.5.0a1 can interpret a request to store a URL string as a request to retrieve and store the contents of the URL. This can allow remote attackers to obtain information by inserting a URL in a form field in an MDB2 application.
Alerts:
Gentoo 200712-05 2007-12-09
Fedora FEDORA-2007-3376 2007-11-15
Fedora FEDORA-2007-3369 2007-11-15

Comments (none posted)

pioneers: denial of service

Package(s):pioneers CVE #(s):CVE-2007-5933
Created:November 15, 2007 Updated:November 30, 2007
Description: Bas Wijnen discovered a vulnerability in the Pioneers server. Sessions objects may be freed while in use, allowing unauthorized memory access. A remote attacker can use this to cause a denial of service.
Alerts:
Gentoo 200711-20:04 2007-11-14
Gentoo 200711-20 2007-11-14

Comments (none posted)

rails: multiple vulnerabilities

Package(s):rails CVE #(s):CVE-2007-5380 CVE-2007-3227 CVE-2007-5379
Created:November 15, 2007 Updated:December 5, 2007
Description: Ruby on Rails has the following vulnerabilities: ActiveResource does not properly sanitize filenames in the Hash.from_xml() function.

The session_id can be set from the URL from the session management.

The to_json() function does not properly sanitize input before it is returned to the user.

Alerts:
SuSE SUSE-SR:2007:025 2007-12-05
SuSE SUSE-SR:2007:024 2007-11-22
Gentoo 200711-17 2007-11-14

Comments (none posted)

samba: buffer overflow

Package(s):samba CVE #(s):CVE-2007-5398
Created:November 15, 2007 Updated:December 11, 2007
Description: Samba's mechanism for creating NetBIOS replies is vulnerable to a buffer overflow. Samba servers that are configured to run as a WINS server can be crashed by a remote unauthenticated user, execution of arbitrary code may also be possible.
Alerts:
Gentoo 200711-29 2007-11-20
Mandriva MDKSA-2007:224-2 2007-11-23
Debian DSA-1409-2 2007-11-26
Debian DSA-1409-1 2007-11-22
Fedora FEDORA-2007-751 2007-11-21
Ubuntu USN-544-2 2007-11-16
Mandriva MDKSA-2007:224 2007-11-17
Fedora FEDORA-2007-3403 2007-11-16
Fedora FEDORA-2007-3402 2007-11-16
Red Hat RHSA-2007:1013-01 2007-11-15
Gentoo GLSA 200711-29:02 2007-11-20
SuSE SUSE-SA:2007:065 2007-12-05
Mandriva MDKSA-2007:224-3 2007-11-29
Debian DSA-1409-3 2007-11-29
Mandriva MDKSA-2007:224-1 2007-11-21
Slackware SSA:2007-320-01 2007-11-19
rPath rPSA-2007-0241-1 2007-11-16
Ubuntu USN-544-1 2007-11-16
Red Hat RHSA-2007:1017-01 2007-11-15
Red Hat RHSA-2007:1016-01 2007-11-15

Comments (none posted)

samba: buffer overflow

Package(s):samba CVE #(s):CVE-2007-4572
Created:November 15, 2007 Updated:July 1, 2008
Description: The Samba user authentication is vulnerable to a heap-based buffer overflow. Remote unauthenticated users can use this to crash the Samba server and cause a denial of service.
Alerts:
Ubuntu USN-617-2 2008-06-30
Ubuntu USN-617-1 2008-06-17
Red Hat RHSA-2007:1114-01 2007-12-10
Fedora FEDORA-2007-760 2007-12-03
Debian DSA-1409-3 2007-11-29
Gentoo 200711-29 2007-11-20
Mandriva MDKSA-2007:224-2 2007-11-23
Debian DSA-1409-1 2007-11-22
Mandriva MDKSA-2007:224-1 2007-11-21
Ubuntu USN-544-2 2007-11-16
Fedora FEDORA-2007-3403 2007-11-16
Fedora FEDORA-2007-3402 2007-11-16
SuSE SUSE-SA:2007:065 2007-12-05
Mandriva MDKSA-2007:224-3 2007-11-29
Debian DSA-1409-2 2007-11-26
Fedora FEDORA-2007-751 2007-11-21
Slackware SSA:2007-320-01 2007-11-19
rPath rPSA-2007-0241-1 2007-11-16
Mandriva MDKSA-2007:224 2007-11-17
Ubuntu USN-544-1 2007-11-16
Red Hat RHSA-2007:1017-01 2007-11-15
Red Hat RHSA-2007:1016-01 2007-11-15
Red Hat RHSA-2007:1013-01 2007-11-15

Comments (none posted)

teTeX: multiple vulnerabilities

Package(s):tetex CVE #(s):CVE-2007-5937 CVE-2007-5936 CVE-2007-5935
Created:November 19, 2007 Updated:May 9, 2008
Description:

From the Gentoo advisory:

Joachim Schrod discovered several buffer overflow vulnerabilities and an insecure temporary file creation in the "dvilj" application that is used by dvips to convert DVI files to printer formats (CVE-2007-5937, CVE-2007-5936). Bastien Roucaries reported that the "dvips" application is vulnerable to two stack-based buffer overflows when processing DVI documents with long \href{} URIs (CVE-2007-5935). teTeX also includes code from Xpdf that is vulnerable to a memory corruption and two heap-based buffer overflows (GLSA 200711-22); and it contains code from T1Lib that is vulnerable to a buffer overflow when processing an overly long font filename (GLSA 200710-12).

Alerts:
SuSE SUSE-SR:2008:011 2008-05-09
Foresight FLEA-2008-0006-1 2008-02-11
SuSE SUSE-SR:2008:001 2008-01-09
rPath rPSA-2007-0266-1 2007-12-17
Ubuntu USN-554-1 2007-12-06
Fedora FEDORA-2007-3308 2007-11-20
Fedora FEDORA-2007-3390 2007-11-20
Mandriva MDKSA-2007:230 2007-11-20
Gentoo 200711-26 2007-11-18

Comments (none posted)

tomcat: arbitrary file disclosure via path traversal

Package(s):tomcat5 CVE #(s):CVE-2007-5461
Created:November 19, 2007 Updated:April 28, 2008
Description:

From the CVE entry:

Absolute path traversal vulnerability in Apache Tomcat 4.0.0 through 4.0.6, 4.1.0, 5.0.0, 5.5.0 through 5.5.25, and 6.0.0 through 6.0.14, under certain configurations, allows remote authenticated users to read arbitrary files via a WebDAV write request that specifies an entity with a SYSTEM tag.

Alerts:
Red Hat RHSA-2008:0195-01 2008-04-28
Gentoo 200804-10 2008-04-10
Red Hat RHSA-2008:0042-01 2008-03-11
SuSE SUSE-SR:2008:005 2008-03-06
Fedora FEDORA-2008-1603 2008-02-13
Fedora FEDORA-2008-1467 2008-02-13
Debian DSA-1447-1 2008-01-03
Mandriva MDKSA-2007:241 2007-12-10
Fedora FEDORA-2007-3456 2007-11-17
Fedora FEDORA-2007-3474 2007-11-17

Comments (none posted)

VMware: unspecified vulnerability

Package(s):VMware CVE #(s):CVE-2007-5617
Created:November 19, 2007 Updated:November 20, 2007
Description:

From the CVE entry:

Unspecified vulnerability in VMware Player 1.0.x before 1.0.5 and 2.0 before 2.0.1, and Workstation 5.x before 5.5.5 and 6.x before 6.0.1, prevents it from launching, which has unspecified impact, related to untrusted virtual machine images.

Alerts:
Gentoo 200711-23 2007-11-18

Comments (none posted)

vmware-player-kernel: several vulnerabilities

Package(s):linux-restricted-modules-2.6.17/20, vmware-player-kernel-2.6.15 CVE #(s):CVE-2007-0061 CVE-2007-0062 CVE-2007-0063 CVE-2007-4496 CVE-2007-4497
Created:November 16, 2007 Updated:August 7, 2008
Description: Neel Mehta and Ryan Smith discovered that the VMWare Player DHCP server did not correctly handle certain packet structures. Remote attackers could send specially crafted packets and gain root privileges. (CVE-2007-0061, CVE-2007-0062, CVE-2007-0063)

Rafal Wojtczvk discovered multiple memory corruption issues in VMWare Player. Attackers with administrative privileges in a guest operating system could cause a denial of service or possibly execute arbitrary code on the host operating system. (CVE-2007-4496, CVE-2007-4497)

Alerts:
Gentoo 200808-05 2008-08-06
Gentoo 200711-23 2007-11-18
Ubuntu USN-543-1 2007-11-15

Comments (none posted)

Updated vulnerabilities

3proxy: denial of service

Package(s):3proxy CVE #(s):CVE-2007-5622
Created:November 9, 2007 Updated:November 14, 2007
Description: Double-free vulnerability in the ftpprchild function in ftppr in 3proxy 0.5 through 0.5.3i allows remote attackers to cause a denial of service (daemon crash) via multiple OPEN commands to the FTP proxy.
Alerts:
Gentoo 200711-13 2007-11-08

Comments (none posted)

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:
Fedora FEDORA-2008-1711 2008-02-15
Fedora FEDORA-2007-0704 2007-06-26
Mandriva MDKSA-2007:127 2007-06-19

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:
Fedora FEDORA-2008-1711 2008-02-15
SuSE SUSE-SA:2007:061 2007-11-19
Fedora FEDORA-2007-2214 2007-09-18
rPath rPSA-2007-0182-1 2007-09-14
Ubuntu USN-499-1 2007-08-16
Red Hat RHSA-2007:0662-01 2007-07-13
Red Hat RHSA-2007:0557-01 2007-07-13
Fedora FEDORA-2007-615 2007-07-12
Mandriva MDKSA-2007:142 2007-07-04
Mandriva MDKSA-2007:141 2007-07-04
Mandriva MDKSA-2007:140 2007-07-04
Fedora FEDORA-2007-617 2007-07-02
rPath rPSA-2007-0136-1 2007-06-27
Red Hat RHSA-2007:0556-01 2007-06-26
Red Hat RHSA-2007:0534-01 2007-06-26
Red Hat RHSA-2007:0533-01 2007-06-27
Red Hat RHSA-2007:0532-01 2007-06-26

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:
SuSE SUSE-SA:2008:021 2008-04-04
Ubuntu USN-575-1 2008-02-04
SuSE SUSE-SA:2006:051 2006-09-08
Debian DSA-1167-1 2005-09-04
Red Hat RHSA-2006:0619-01 2006-08-10
Red Hat RHSA-2006:0618-01 2006-08-08

Comments (none posted)

httpd: denial of service, cross-site scripting

Package(s):apache httpd CVE #(s):CVE-2007-3847 CVE-2007-4465
Created:September 25, 2007 Updated:February 15, 2008
Description: A flaw was found in the mod_proxy module. On sites where a reverse proxy is configured, a remote attacker could send a carefully crafted request that would cause the Apache child process handling that request to crash. On sites where a forward proxy is configured, an attacker could cause a similar crash if a user could be persuaded to visit a malicious site using the proxy. This could lead to a denial of service if using a threaded Multi-Processing Module. (CVE-2007-3847)

A flaw was found in the mod_autoindex module. On sites where directory listings are used, and the AddDefaultCharset directive has been removed from the configuration, a cross-site-scripting attack may be possible against browsers which do not correctly derive the response character set following the rules in RFC 2616. (CVE-2007-4465)

Alerts:
Slackware SSA:2008-045-02 2008-02-15
Ubuntu USN-575-1 2008-02-04
Red Hat RHSA-2008:0008-01 2008-01-15
Red Hat RHSA-2008:0006-01 2008-01-15
Red Hat RHSA-2008:0005-01 2008-01-15
Red Hat RHSA-2008:0004-01 2008-01-15
Mandriva MDKSA-2007:235 2007-12-03
SuSE SUSE-SA:2007:061 2007-11-19
Red Hat RHSA-2007:0747-02 2007-11-15
Gentoo 200711-06 2007-11-07
Red Hat RHSA-2007:0746-04 2007-11-07
Red Hat RHSA-2007:0911-01 2007-10-25
Fedora FEDORA-2007-707 2007-09-24

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:
Gentoo 200711-21 2007-11-17
Fedora FEDORA-2007-1778 2007-08-23
Debian DSA-1351-1 2007-08-07
Fedora FEDORA-2007-1153 2007-07-19

Comments (none posted)

cacti: denial of service

Package(s):cacti CVE #(s):CVE-2007-3112 CVE-2007-3113
Created:September 18, 2007 Updated:February 18, 2008
Description: A vulnerability in Cacti 0.8.6i and earlier versions allows remote authenticated users to cause a denial of service (CPU consumption) via large values of the graph_start, graph_end, graph_height, or graph_width parameters.
Alerts:
Fedora FEDORA-2008-1737 2008-02-15
Fedora FEDORA-2007-3683 2007-11-22
Fedora FEDORA-2007-2199 2007-09-18
Mandriva MDKSA-2007:184 2007-09-17

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:
Debian DSA-1433-1 2007-12-16
Debian-Testing DTSA-55-1 2007-09-03
Fedora FEDORA-2007-1160 2007-07-19

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:
SuSE SUSE-SR:2007:015 2007-08-03
Gentoo 200708-04 2007-08-09
Mandriva MDKSA-2007:150 2007-07-25
Debian DSA-1340-1 2007-07-24

Comments (none posted)

clamav: multiple vulnerabilities

Package(s):clamav CVE #(s):CVE-2007-4510 CVE-2007-4560
Created:September 3, 2007 Updated:February 13, 2008
Description: Several remote vulnerabilities have been discovered in the Clam anti-virus toolkit. The Common Vulnerabilities and Exposures project identifies the following problems:

CVE-2007-4510: It was discovered that the RTF and RFC2397 parsers can be tricked into dereferencing a NULL pointer, resulting in denial of service.

CVE-2007-4560: It was discovered clamav-milter performs insufficient input sanitizing, resulting in the execution of arbitrary shell commands.

Alerts:
Fedora FEDORA-2008-1608 2008-02-13
Fedora FEDORA-2008-0170 2008-01-22
Gentoo 200709-14 2007-09-20
Fedora FEDORA-2007-2050 2007-09-07
Mandriva MDKSA-2007:172 2007-08-31
Debian DSA-1366-1 2007-09-01

Comments (none posted)

conga: denial of service

Package(s):conga CVE #(s):CVE-2007-4136
Created:November 7, 2007 Updated:November 22, 2007
Description: A flaw was found in ricci during a code audit. A remote attacker who is able to connect to ricci could cause ricci to temporarily refuse additional connections, a denial of service (CVE-2007-4136).
Alerts:
Red Hat RHSA-2007:0983-01 2007-11-21
Red Hat RHSA-2007:0640-04 2007-11-07

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:
Mandriva MDVSA-2008:036 2007-02-06
Mandriva MDKSA-2007:086 2007-04-16
Red Hat RHSA-2007:0123-01 2007-04-16
Gentoo 200703-28 2007-03-31
Foresight FLEA-2007-0003-1 2007-03-25

Comments (none posted)

cups: buffer overflow

Package(s):cups CVE #(s):CVE-2007-4351
Created:October 31, 2007 Updated:November 19, 2007
Description: The CUPS code charged with dealing with TCP-based Internet Printer Protocol connections suffers from a buffer overflow which could possibly be exploitable remotely. The vulnerability is only present if remote hosts are allowed to connect to the IPP port, which is usually not the default setting.
Alerts:
Debian DSA-1407-1 2007-11-18
Gentoo 200711-16 2007-11-12
Mandriva MDKSA-2007:204-1 2007-11-12
Fedora FEDORA-2007-2982 2007-11-08
Ubuntu USN-539-1 2007-11-06
Fedora FEDORA-2007-740 2007-11-05
Slackware SSA:2007-305-01 2007-11-02
Fedora FEDORA-2007-2715 2007-11-01
Mandriva MDKSA-2007:204 2007-11-01
rPath rPSA-2007-0227-1 2007-10-31
SuSE SUSE-SA:2007:058 2007-10-31
Red Hat RHSA-2007:1020-01 2007-10-31

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:
Fedora FEDORA-2007-3390 2007-11-20
Fedora FEDORA-2007-3308 2007-11-20
Gentoo 200710-20 2007-10-18
Gentoo 200710-08 2007-10-09
Gentoo 200709-12 2007-09-19
Fedora FEDORA-2007-685 2007-08-30
Debian-Testing DTSA-54-1 2007-08-22
Fedora FEDORA-2007-669 2007-08-13
Fedora FEDORA-2007-644 2007-08-13
Debian DSA-1357-1 2007-08-19
Mandriva MDKSA-2007:162 2007-08-14
Mandriva MDKSA-2007:165 2007-08-15
Foresight FLEA-2007-0046-1 2007-08-14
Fedora FEDORA-2007-1614 2007-08-15
Mandriva MDKSA-2007:164 2007-08-14
Mandriva MDKSA-2007:163 2007-08-14
Foresight FLEA-2007-0045-1 2007-08-14
Foresight FLEA-2007-0044-1 2007-08-14
Mandriva MDKSA-2007:158 2007-08-13
Mandriva MDKSA-2007:160 2007-08-13
Mandriva MDKSA-2007:161 2007-08-13
Mandriva MDKSA-2007:159 2007-08-13
Fedora FEDORA-2007-1594 2007-08-13
Debian DSA-1355-1 2007-08-13
Slackware SSA:2007-222-05 2007-08-13
Slackware SSA:2007-222-02 2007-08-13
Fedora FEDORA-2007-1547 2007-08-10
Fedora FEDORA-2007-1541 2007-08-10
Debian DSA-1354-1 2007-08-13
rPath rPSA-2007-0154-1 2007-08-10
SuSE SUSE-SR:2007:016 2007-08-10
Ubuntu USN-496-2 2007-08-07
Debian DSA-1352-1 2007-08-07
Debian DSA-1350-1 2007-08-06
Debian DSA-1349-1 2007-08-05
Debian DSA-1348-1 2007-08-04
Debian DSA-1347-1 2007-08-04
SuSE SUSE-SR:2007:015 2007-08-03
Ubuntu USN-496-1 2007-08-03
Red Hat RHSA-2007:0731-01 2007-08-01
Red Hat RHSA-2007:0735-01 2007-07-30
Red Hat RHSA-2007:0732-01 2007-07-30
Red Hat RHSA-2007:0729-01 2007-07-30
Red Hat RHSA-2007:0730-01 2007-07-30
Red Hat RHSA-2007:0720-01 2007-07-30

Comments (1 posted)

debian-goodies: privilege escalation

Package(s):debian-goodies CVE #(s):CVE-2007-3912
Created:October 5, 2007 Updated:March 24, 2008
Description: Thomas de Grenier de Latour discovered that the checkrestart program included in debian-goodies did not correctly handle shell meta-characters. A local attacker could exploit this to gain the privileges of the user running checkrestart.
Alerts:
Debian DSA-1527-1 2008-03-24
Ubuntu USN-526-1 2007-10-04

Comments (none posted)

Django: denial of service

Package(s):Django CVE #(s):CVE-2007-5712
Created:November 12, 2007 Upd