LWN.net Logo

Advertisement

E-Commerce & credit card processing - the Open Source way!

Advertise here

LWN.net Weekly Edition for January 18, 2007

lca2007: Christopher Blizzard

[Jeff Waugh and Chris Blizzard] The keynote speaker on the second day of linux.conf.au 2007 was Christopher Blizzard, currently with Red Hat. His topic was "relevance," and, in particular, the relevance of the free software movement to the rest of the world.

One way to be relevant is to create top-quality products. There was an emphasis on the word "product," rather than "project"; Chris was talking about making things for people. The best products, he says, are those which genuinely change the way we live. The example he used was cellular telephones, which have truly changed the ways in which people communicate. Your editor, often reduced to communicating with his children via text message, is not convinced that all these changes are for the better, but the talk did not address this side of things.

The next slide was a marketing shot of the iPhone. Is this a product which will change how people live? Nobody in the audience was willing to argue that it was.

Then came Firefox - a project which Chris worked on for some years. Firefox "makes the web less annoying," and makes a point of respecting its users, which is important. It's still not clear that Firefox has changed the way people live, however. Even so, Firefox had some lessons to offer:

  • You can't change the web from the back end. No matter how much good and innovative work is being done on the server side, the software which controls the user experience will shape the web. Firefox has been successful because it is "driving from the front," and influencing how the users see and work with the net.

  • Going direct to users is important; you can't count on others to distribute your software for you.

  • Stick to your core values. The Mozilla project gets significant amounts of money from its sponsors, but it is unwilling to consider sponsorships which would require user-hostile changes.

  • Have a mission. A project will only produce a great project if it has a strong idea of what it is trying to accomplish.

How many years, asked Chris, has it been the year of the Linux desktop? Is Linux relevant for desktop users. In general, his answer was "no." Linux is showing up in interesting places, however: the Nokia N800, telephones, and the One Laptop Per Child project.

OLPC, says Chris, truly is a relevant project which will be changing lives. It has a well-defined mission - providing computing technology in a way which furthers the education of children in the developing world - and it is creating a product which furthers that mission. To that end, a number of interesting innovations have been made; these include the OLPC display (which, among other things, is readable in full sunlight), the mesh networking feature, and the ability to power it with a hand-operated generator. The sugar user interface also rates high on the list; it has tossed out much of the standard desktop metaphor in favor of a new design aimed at the OLPC's target user base.

So, based on this, how should a project make itself relevant? Chris suggests:

  • Find an important set of clients, and work toward their needs. In the OLPC example, the clients are developing-world children (or, perhaps, the governments which represent them).

  • Find good designers and trust them. Free software developers are often dismissive of the need for good design, but you cannot create a great product without it. Once you have found people who can do this design, you must trust them, even if their work takes you in directions which are surprising and unfamiliar.

  • Make your product for other people. Doing so requires developing a certain amount of empathy for the intended clients and getting past the "itch scratching" mode of development.

A project which follows these guidelines, says Chris, has a good chance of being relevant well into the future.

Comments (9 posted)

Interview with Second Life's Cory Ondrejka

January 17, 2007

This article was contributed by Glyn Moody

Cory Ondrejka, CTO of Linden Lab, has some serious programming credentials. Before joining Linden Lab in late 2000, he worked on US government projects and Nintendo games; as well as writing much of the original core code for Second Life, he also designed the Linden Scripting Language (LSL), and wrote the LSL execution engine. He talks to Glyn Moody about the background to Linden Lab's decision to take the Second Life client open source, how things will work in practice, and what's going to happen server-side.

When did Linden Lab start to think about the possibility of opening up Second Life's source code?

We've been thinking about it fairly seriously for, gosh, nearly three years now. The effort to really get there is something that got kicked off pretty early in 2006.

Was there any particular stimulus at that time?

We started looking at what our residents were doing in preparation for some speaking we did at [O'Reilly's] ETech in March. One of the things that we discovered was that a very large percentage of our residents – something on the order of 15% of people who logged in - were using the scripting language. So you start realising that there are tens of thousands of people at least, probably more like hundreds of thousands at this point, who have written code related to Second Life. And so it seems a little bit silly to not enable that creative horsepower to be applied to our code as well.

Was the decision to open the viewer's code a difficult one?

I think internally, as an organisation, buying into the idea is something that we were able to get to relatively quickly. People sometimes don't realise that the kind of work you have to do to be able to open source is exactly the same work that you're doing to close exploits and fix bugs. It's actually not a separate set of tasks in many ways.

Over 2006 there was also a very active reverse-engineering effort called libsecondlife that has something like 50 or 60 developers on their mailing list. They've been doing a very impressive job of reverse engineering the protocols and figuring out what's going on. They were finding exploits quite regularly and doing a good job of sending them to us, and saying: Hey, we found this, you guys might want to fix it.

What we found, of course, is that it doesn't really matter whether we open source or not, the exploits are going to get found - that's what has happened in all software. And so why not make it easier for folks like libsecondlife, if they're going to be poking around anyway? Let them have the code so that they're more likely be able to fix things that they find, and broaden it to a larger community of developers than just the developers who wanted to get involved in a reverse-engineering effort.

Why did you choose GNU GPLv2 license for the code?

We ended up talking about that a lot. We were basically surveying what license is still the dominant license in the open source community: it's GPLv2, and so in our minds it has a lot of legitimacy. It's also the one that gives us the most flexibility down the road, where if we want to do a dual-licensing scheme, or a more-than-dual licensing scheme, it's a lot easier to come from GPL than sort of back into it.

In fact, you already offer a commercial license, I believe?

We do. I think that for now we would be sort of surprised if a lot of people jumped on the commercial license today, but we have a lot to learn. This is a very big step: there's never been a product that was in the dominant position that then open sourced. Open source is usually used by folk who are either trying to gain market share, or projects that are very early stage. So in that sense, we're trying to be pretty careful and conservative in our decision-making process, because this is in some ways new ground. Much like three years ago, when we gave intellectual property rights back to our residents, and allowed them to own what they made, that was a very new step in this space, and so I think we're continuing the tradition of bleeding edge in our decision making.

When did you start the detailed preparatory work, and what did that entail in terms of preparing the viewer code for release?

It really got started in May and that process continued until the release. It was everything from doing external security audits, hiring additional staff, making sure that you could build it on all the platforms, and building the manifests for all the zip and tarballs we were going to distribute.

Did you have to do much in terms of making the code more legible or more modular?

I think we haven't done as much of that as we would like. Now, of course, nobody who has actually written code and then released it ever thinks the code is clean or modular enough; in fact there are pretty big changes coming down the pike to make the code better.

And that was a pretty active topic of debate: do we wait until after those changes to release the code? We decided that it made more sense to get the code out there. You can always find reasons not to open source, and ultimately it's better to let people begin getting expertise in the code even if we warn them: Hey, this part of the code is going to be changing. And what's neat is that less than 24 hours after we put the code out we've already accepted a user patch.

Could you say a little about these big changes that are coming through?

What we need is to be able not to have to update monolithically. Right now, we take down the grid, we update everybody's viewer, and everything comes back up. And obviously that's neither scalable nor testable. And so there's this long series of changes to be made to let us upgrade in a more heterogeneous way. And we are beginning to publish what those changes are going to be so that people know that they're coming and what to expect.

What are the things that you haven't been able to open source?

Well, for example, streaming textures in Second Life use the JPEG2000 compression standard, j2c, and we use a proprietary bit of code to do the decompression. Now libjpeg, which is the open source version of this, does j2c, but it's way too slow. So one of our first challenges to our user base is: Hey, go smack libjpeg around a bit, and optimise it and then we will happily swap it in.

Why do you distribute binary copies of libraries that are almost certain to be found on any GNU/Linux system -- zlib and ogg/vorbis, for example?

It just seems simpler to give people really complete sets and say: If you go through these steps you will build successfully. There are few things more frustrating than getting all excited about getting some code and you go to build it and it barfs. So we've really been trying to take steps to make sure that doesn't happen. Within about an hour and a half of us putting the code up, there was a picture up on Flickr of somebody who had compiled and made a change already.

In terms of the timing, Linden Lab's been very circumspect in talking about this move: the signals were later this year rather than at the beginning. Why is it happening now, much earlier than you originally indicated?

Linden Lab has always been probably more open than is good for us about what we're trying to do when. We have always talked about features that we're working on, and given estimates of when we were trying to release them. Like most software, we usually end up being a little bit later on those than we'd like to be. And so going forward, we're trying to do a better job of underpromising and overdelivering rather than the opposite. So if people get mad at me because I deliver stuff faster than I was going to, I think I can live with that. I like to beat expectations from here on out.

What do you hope to gain from open sourcing the viewer?

First of all, we expect to get a better viewer. We think we will do a better job of finding bugs and exploits with the Second Life community looking at the code. If you go out medium to longer term, I think we will see active feature development as the community gains expertise with the code and we continue to implement protocol changes to make it easier to implement the features. More importantly, I think we're going to be building expertise in running an open source project because this is just step one for us in terms of where we think Second Life needs to go.

Second Life is growing very rapidly at this point. We think that it is a Web-scale project, not a game-scale project. We will not be happy if at the end of the day we only have ten million users; I think we would all see that as a tremendous failure. So, if we're going to scale to Web levels, obviously we need to keep open-sourcing the pieces that make sense to open source. In order to do that, we need to build expertise at running open source projects, and being part of open source projects, and engaging the open source community. So we've taken the piece that we were first able to do that with, and we're going to learn a lot over the next couple of quarters.

Were you surprised by the large number of positive comments on the blog posting that announced the move?

There's no question that the Second Life community is the most creative, capable, intelligent, community ever targeted on one project in history. To give them the ability to make the project even more their own - it does not surprise me that they're pretty psyched about that.

What are the resources that you've put in place to work with the community that you hope to build around the code?

Right now, we basically have an army of one, Rob Lanphier, who did this before. He was at RealNetworks, and spearheaded the Real server open source project Helix.

What's he going to be doing, and how will the code submissions be processed?

He is going to be helping to hire a team, because we're eventually going to need a whole team to be just managing the ingress of code. Right now, he help set up JIRA, the project management software, which the users can register on and submit bugs and patches. They have a wiki for the open source project, and he has been pretty much managing that.

The QA team is also directly plugged in to the patch submission process so that they can pull patches in, test them on private set-ups, see what's going on. The developers will be keeping an eye on things as well. Like a lot of what Linden Lab does, it's going to be a relatively diffuse project.

You mentioned JIRA for issue tracking, what about the actual code management?

We use Subversion. There isn't yet a public Subversion repository, but we're getting there.

Will you be giving accounts on that to outside contributors?

I don't know exactly what Rob's plan is for that, but I would assume that there's going to be something like that. I expect the libsecondlife people will have a Subversion repository up before we do anything, anyway. They may host the code also -- they're pretty aggressive about doing that.

To foster external contributions, how about moving to a plug-in architecture?

I think that all of us agree that a plug-in structure on the client makes sense. It's just a matter of figuring out whether we want to leverage an existing one or re-invent the wheel.

You've indicated that you view opening up the client as a learning experience for open-sourcing the server in the right way: what additional issues will you need to address here - presumably the proprietary Havok physics engine is going to be a problem?

Certainly, there is the question of proprietary code. We may be able to do exactly what we did on the client side, where we are distributing binaries. In six months, when this [move to open up the client] is successful, it may make for very interesting conversations with folks. We can say: Hey, look, you are the leader in this sector, you should open source, here's why we did it and it worked. And I think the fact that there aren't any proof-points of that is maybe part of what scares companies from doing that. I think we're going to be a very interesting test case.

Obviously the server raises a host of security issues. We have a roadmap that we think solves those, and we're going to be sharing that roadmap sometime this quarter with the community, once we get it sufficiently refined that we're happy with it. We see a host of use-cases for servers where we need to make some pretty profound architectural changes in terms of how trust is established between user and server, between servers and each other, and servers and backend systems. But we see a path, and so it's just a matter of applying development resources to that path and moving along it.

What kind of things are you having to deal with?

In broad security terms, [it's] about code running on hostile machines. Right now, all of the simulator machines are machines that we own in our co-los. It's very different to have that code running on a machine in your garage, even though you're probably a trustworthy guy. That raises issues of trust. Once you have code running on hostile machines, it doesn't really matter whether you have the source or not: you can start doing things. And so we need to trust the simulators less, which means moving some of the things that the simulators currently do in a trusted fashion, out of them.

Does that mean centralizing certain Second Life services?

That depends. Let's say you were a large research organization and you wanted to be able at times use Second Life in a more private way. You might want to control even some of the centralized services. But what you don't want is just a fragmented set of parallel universes that can't talk to each other because you then lose the benefit that makes Second Life so strong, which is the fact that all these communities can connect across traditional geographic and community boundaries. And so the secret sauce becomes how do you architect it in a way that allows both Internet and intranet use.

Do you think that these future worlds will be part of the main Second Life geography or will there be portals from them through to your world?

Well, I think the answer is "yes", because there are some use-cases where it makes sense to be part of the big world, and other cases it makes sense to be a portal away.

Presumably you've also got to deal with issues like identity as avatars move between different worlds, and the tricky one of money?

It's almost like you've read my list: you're dead-on. What's good is, unlike six and half years ago, when we got rolling on this stuff, some of these have been partially solved by the Web. There are much better exemplars today than there were six and half years ago. And so for a lot of what we're going to be doing we can use existing technologies.

What does that imply about the convergence of 3D virtual worlds with the Web?

I think that when you look at anything in problem space, there's some things that the Web does very well. Text, it does it really well; one-to-many, it does it very well; sequential solo consumption of content, it does really well. But there are some things that shared collaborative space and virtual worlds and 3D do really well: if you need place, or you need people to be consuming the content together, where the audience matters, or knowing that we're consuming at the same time matters, or when you need simultaneous interaction.

So I think it's a little odd to imagine that either of those hammers will solve all problems. Instead, what you want is to be able take problems and move into them into the correct space. If you're doing text entry, doing it in 3D is just a big pain in the butt. So there are places for the Web, and there are places for virtual worlds, and I think what you want is as much data to flow between those two as smoothly as you can.

Finally, once you've opened up the code to the client and server, what will be left for Linden Lab to make some money from?

I think that would be a little bit like implying there's no business to be had on the Web if you give away Apache. The Web has shown us where a lot of the value is: identity, transactions, search, communities. And so nothing that we've talked about requires that Linden Lab give up any of those pieces. I think the key is for us to enable growth, building a much, much bigger market, and attempt to make money where it makes sense.

Glyn Moody writes about open source and virtual worlds at opendotdotdot.

Comments (4 posted)

The Grumpy Editor's Guide to graphical IRC clients

This article is part of the LWN Grumpy Editor series.
IRC (Internet Relay Chat) is a venerable protocol which allows people to type messages at each other across the net. Your editor remembers a fascinating day in 1991, when observers in Moscow used an IRC channel to report on the Soviet coup attempt; it was an early example of the power the net would come to have. In subsequent years, however, your editor has had little time for IRC. Getting LWN together every week requires a strong focus on getting things done, and IRC can be a real productivity killer. Pretending that IRC does not exist has been most helpful in getting the Real Work done.

Recently, however, your editor has had reason to wander into IRC again. Having not done much in this area for a while, your editor lacked a favorite IRC client - or any IRC client at all. Thus began the search for the best tool for this particular job - and, eventually, this article.

Anybody who has investigated the topic knows that there is no shortage of IRC clients to choose from. It would appear that free software developers are often afflicted with this particular itch. There is no real hope of reviewing them all, so your editor will not even try. Instead, this review is restricted to graphical clients which appear to have a real user base and which are under active development. Your editor also lacks access to AOL instant messaging, MSN messaging, etc., so this review will be focused on IRC functionality. Some clients can work with many networks; that capability will be mentioned when appropriate, but it will not be reviewed further. Finally, your editor has little to say about channel operator commands, file downloads, or other such features of IRC; this article will focus on the basics.

Gaim

[Gaim] Gaim is a longstanding GNOME messaging client. It does IRC, along with AIM, ICQ, MSN Messenger, Yahoo, Jabber, Gadu-Gadu, and so on. If it's a messaging protocol, Gaim can probably handle it. Those using it for IRC only will find that Gaim brings a certain amount of baggage ("buddy lists" and such) which is not useful in that context, and that some of the terminology used ("rooms") does not quite match the IRC conventions. None of this is particularly problematic in real use, however.

The main Gaim window is tab-oriented, with each IRC channel in its own tab. This organization is space-efficient, but it can make it hard to monitor more than one channel - though the color-coded tab tags help. Tabs can be detached, however, allowing the user to fill the screen with single-channel windows. Gaim windows use smooth scrolling, a feature your editor got tired of back in the VT100 days; unfortunately, there appears to be no easy way to turn it off. On the other hand, users can turn off the insertion of cloyingly cute smiley graphics into the message stream.

Private messages result in the quiet creation of a new tab - something which can be easy for the user to miss. In general, the handling of private messages in IRC clients seems a little awkward.

Gaim has support for IRC servers which can authenticate nicknames with passwords. It also has a plugin feature which can be used to extend the client; available plugins add support for additional protocols, expose more preference options, perform encryption, and more.

Finally, on your editor's system, the Gaim client was a huge process. It should not be that hard to create an IRC client which requires less that a 50MB resident set, but the Gaim developers have not done that. Running Gaim made the whole system visibly slower. Gaim also doesn't take the hint when all of its windows are closed; one must explicitly tell it to go away by selecting "Quit" from the "Buddies" menu in the "Buddy list" window - something your editor found less than entirely intuitive.

Konversation

[Konversation] Konversation is a KDE-based client centered around IRC. Like many KDE clients, it is feature-heavy and visually pleasing.

Like Gaim, Konversation is based on a single window with tabs. In this case, however, there does not appear to be any way to detach the tabs into their own windows. One nice feature in Konversation is "remember lines," lines drawn in each conversation window when it goes out of view. When returning to a channel, the user knows just where to start reading to catch up on the new stuff. This feature gets a little aggressive at times, drawing several lines together in low-activity channels; one presumes this little glitch can be ironed out. Konversation also has an option to suppress all of the channel event lines (comings and goings) which tend to clutter up the conversation.

Konversation can handle passwords, but it required a bit more setup work than some other clients. Also available is a "URL catcher" tab which simply accumulates URLs posted on subscribed channels.

Overall, Konversation comes across as a featureful and useful IRC client. The documentation which comes with it is well-done and comprehensive; it helped your editor get past his initial questions ("how do I make it stop joining #kde?") quickly. Detachable tabs would make it nearly perfect.

ERC

[ERC] Perhaps your editor is pushing it a bit by including ERC in this list. ERC is an emacs-based IRC client; it can be added onto emacs 21, and it has been bundled into the upcoming emacs 22 release. Emacs is a strongly graphical environment these days, and ERC offers all of the point-and-click configuration and operation options that the other clients reviewed here have.

ERC maintains a separate buffer for each open IRC channel. It tends to hide those buffers, and there is no simple tab bar for switching between them. It is a simple matter for an emacs user to configure the display as desired, with different channels displayed in different windows or frames. Somebody who is not familiar with the emacs way of doing things would have a harder time of it, however.

There is a separate buffer for managing the connection with the IRC server, and that is where private messages show up. It is probably safe to say that very few users will keep that buffer visible, with the result that private messages tend to go unnoticed. ERC also arguably features the ugliest, most unreadable channel list window of any of the clients reviewed.

Display is highly configurable. By default, ERC is less color-happy than most other graphical clients, a feature which your editor appreciates. There is a full list of options for filtering users and message types, performing text transformations, etc. And, of course, the experienced emacs user can simply attach elisp functions to any events requiring more involved customization.

There is no provision for marking the last-read text in ERC. This functionality is easily obtained by moving point off the end of the buffer, essentially saving the current location - but the user must remember to do it.

Overall, your editor likes the feel of working with ERC - but, then, he is known to be sympathetic to emacs-based solutions. There is no need to figure out how to search for specific text, for example - all of the normal text searching functions work as expected. Saving text or a partial log is straightforward. There is no one-line text window to type into; one simply types into the buffer and long lines are broken naturally. And so on. Emacs users will probably be happy with ERC; the rest of the world is unlikely to pick up emacs to be able to use it.

XChat

[XChat] XChat is a popular client with a relatively long history. Your editor tried out the GNOME version of XChat on several networks. Finding servers was relatively easy, since XChat comes equipped with a long list built into it. One thing which becomes immediately apparent, however, is that XChat grabs the channel list in a blocking operation. The client can go completely unresponsive for several minutes until the listing is complete - not the friendliest introduction possible.

The main XChat window features a tree listing of servers and open panels on the left, and a display of one of those channels in the main pane. There does not appear to be any way to view more than one channel's traffic at any given time. The left pane marks channels with unread activity - with a separate mark if the only activity is enter and leave events.

The XChat feature list is long. It has a "last read" line in each window, though how it decides when something was read remains a bit of a mystery. It is not directly related to expose, focus, or mouse button events. Those who are relatively uninterested in actually reading IRC traffic can set up window transparency and background images. There is a plugin mechanism which can used to set up a URL grabber window or to script the client in Perl or Python. Moving the pointer over a correspondent's name yields a popup with that person's name and origin information. There is no password support, however. Unlike some other clients, XChat appears to have relatively little support for channel operator functions.

Graphically, XChat is reasonably pleasing, with a use of color which is not entirely excessive. Private messages are handled in a relatively straightforward and visible way - but the dialog for selecting a user to talk to is painful. Overall, it is a capable and easy client adequate for the needs of a large subset of IRC users.

SeaMonkey

[SeaMonkey] Once upon a time, the Mozilla client looked as if it were about to grow to encompass the functionality of most other programs found on a typical desktop system. The Mozilla project eventually decided to redirect its efforts toward the more focused Firefox and Thunderbird tools, leaving the old, comprehensive application behind. There were users who did not like that state of affairs, and who dedicated some time to continuing its development. The result was the SeaMonkey project. Tucked into one corner of this tool is an IRC client.

Your editor's introduction to this tool was somewhat rocky. It offered up Undernet as one of its connection possibilities. Your editor decided to check it out and see what channels were available. After a long period where the client was completely unresponsive (attempting to list information for over 20,000 channels), it simply crashed. Note to the SeaMonkey developers: if you must crash, please have the courtesy to do so before making the user wait for a long network transfer.

When SeaMonkey is operating, it provides a single, tabbed window with nicknames on the left. There is no way to have more than one channel on-screen at a time. There is no password support. All told, the SeaMonkey IRC client ("ChatZilla") comes across as unfinished and rough compared to a number of the alternatives. Your editor has seen nothing here to convince him that web browsers need to support IRC too.

ksirc

[ksirc] Ksirc is a simple IRC client shipped with KDE; it does not appear to have a web page dedicated to it. It offers less help than many other clients; your editor's install of ksirc did not know about any IRC servers, for example. Once configured, however, it operates well enough.

The bulk of the interface is done through a single window, with each channel represented by a tab. It is possible to detach the tabs into separate windows, making it possible to see multiple windows at once. There is also a "ticker mode" where messages scroll by in a single-line window, but this mode did not render properly on your editor's system. A separate window shows the list of servers and open channels, but it does not appear to actually be useful for much.

Your editor appreciates restraint in the use of color, but ksirc, perhaps, takes the idea too far by default. The window is essentially monochromatic, dense, and difficult to read. The use of color can be configured, however, and there is a set of filters which can be used to highlight messages with text of interest. When the automatic colorizing mode is enabled, however, it has an unhealthy tendency to pick gray for some of the more active users - a bit of a pain considering that the window background is, by default, gray.

Overall, ksirc is a sufficiently capable tool for most needs. It gives the impression of having been left behind by some of the other KDE-based IRC clients, however, and of not getting much development attention in recent times.

Kopete

[Kopete] A more contemporary KDE client is Kopete. This tool, perhaps, is the KDE answer to Gaim; it appears to have support for just about any messaging protocol one can imagine. Once again, your editor only looked at the IRC functionality.

If ksirc is dense and hard to read, Kopete is the opposite. The default display is full of white space, divider bars, icons, smilies, and more. Here, too, it can be hard to follow a conversation for the simple reason that very little of it actually fits into the window. Kopete supports themes, however, and it does not take long to find a theme which makes a little better use of screen real estate.

At the outset, Kopete's interface is a bit intimidating. The small window that comes up seems to offer little in the way of interesting operations - joining a channel, say. For that, one must know to right-click on the little icon which shows up in the taskbar tray and wander through the menus. It all works fine once one gets the hang of it, but a new user trying to get started without having read the manual is likely to be frustrated for a while.

It is hard to miss private messages in Kopete - the application creates a new window and throws it at you. For the serious messaging user, there is a whole set of options for configuring just how hard the client tries to let you know about various sorts of events. About the only thing that is lacking is a "last read" line. With that in place, and with an appropriate theme, Kopete is a powerful and attractive tool.

KVirc

[KVirc] Finally, your editor tried out KVirc, which is a bit of a different approach to IRC clients. Unlike Kopete, which leaves the first-time user trying to figure out what to do, KVirc starts with a set of configuration windows - one of which even displays the GPL text for approval. The user ends up with a big window containing another for server selection. It would appear that just about every IRC server on the planet has been put into this dialog; it's a long list.

After selecting a server (and, perhaps. entering password information), the user encounters one of the more peculiar aspects of KVirc. Every channel has its own window, but all of those windows are contained within the big KVirc window. There is a background image in the big window, and the channel windows are all translucent. It is all visually striking, but your editor could not help wondering why the developers felt the need to implement their own window manager. It even has options for tiling all of the subwindows - with a choice of several different algorithms.

KVirc also has KVS, its own, special-purpose scripting language "inspired by C++, sh, perl, php and mIrc". There is a separate window for monitoring socket operations, no end of options for playing sounds, a set of anti-spam and anti-flood filters, and more. It's all powerful and striking, but it's hard to help wondering if all that brilliant development energy couldn't have gone into something more generally useful than another IRC client.

For people who spend much of their lives in IRC, KVirc might well be the tool of choice. It's visually striking, feature-rich, and users can script their own bots directly within the client. For your editor's purposes, however, KVirc is an overly heavy tool, wanting the full screen and ongoing attention.

Conclusion

Some readers will certainly note the biggest omission from this review: bitchx. It is, beyond doubt, a powerful client; bitchx was left out primarily because it is not a graphical client. Those who are determined to remain in the curses world are unlikely to be much interested in the other clients listed here, so there doesn't seem to be much point in trying to compare them.

So which client will your editor use when he wishes to be grumpy with others in real time, one line at a time? ERC probably remains at the top of the list, but XChat is also a useful and capable client. If your editor were a user of other messaging protocols as well, it would pretty much come down to Gaim or Kopete, depending on one's desktop orientation. Your editor's high-school son tends to quickly minimize windows when others walk into the room, but he would appear to have settled on Gaim.

In the end, however, just about any of these clients is adequate for the job. One cannot help but wonder why the free software community has produced such a large set of IRC clients. Yes, IRC is an important communication channel, and a well-designed client can make IRC more pleasant to work with, but it still does not seem like there would be room for that many applications doing essentially the same thing. One cannot fault developers for scratching an itch and giving the result to the world. Perhaps, once they have achieved the creation of the world-dominating IRC client, some of these developers will move on to the creation of something truly revolutionary.

Comments (37 posted)

Page editor: Rebecca Sobol

Security

Security news

Chaostables for confusing nmap scans

January 17, 2007

This article was contributed by Jake Edge.

Chaostables is a recently released collection of code that provides a means to confuse an nmap scan. The author, Jan Engelhardt, has provided these capabilities as both netfilter modules for Linux 2.6.18-20 and as iptables rules. He has an excellent description of what he is trying to accomplish and how he does it, as well.

Utilities like nmap (described in an LWN article last year) are often used by those with malicious intent to discover available hosts, open ports, OS versions, and the like to help target their attacks. Chaostables seeks to generate confusing results to these probes. To that end, Engelhardt has derived a set of behaviors that correspond to these types of scans and a set of rules to detect and deflect them.

Since 2.4, the standard way of doing Linux packet filtering is by using the iptables utility which provides a userspace interface to the netfilter kernel modules. Netfilter provides a set of kernel hooks for examining and manipulating network packets and is the framework for Linux firewall implementations. Administrators define rules that identify particular kinds of packets and specify what to do with them; those rules are ordered and collected into chains which are then grouped into tables. All of this packet policy can then be pushed into the kernel via the iptables utility.

The chaostables rules start with dropping some ICMP packets that could reveal the existence of the host and then start concentrating on the kinds of packets sent by scanning utilities. Techniques like TCP stealth, SYN, connect and grab scans are detected and dropped to attempt to hide the host while still allowing 'real' network traffic. These rules are then rolled up into the 'portscan' netfilter module in order to reduce the complexity of the chains that need to be installed.

A second kind of chain provides ways to disguise the underlying system by making Linux appear to be another OS entirely. Network scanning utilities often try to throttle their scans when they detect a system that limits the number of ICMP or RST packets sent per second. Linux is not one of those kinds of systems, but the CHAOS chain makes it look as if it is by limiting RST and ICMP packets to two per second. It also uses the 'random' netfilter rule to generate negative responses on closed ports only some of the time. The net effect is that the scanner will get inconsistent results, sometimes ports will appear closed and sometimes not with the added bonus of potentially slowing down the scan.

The CHAOS chain can be combined with the TARPIT chain to cause ports to appear to be open when in fact they are not. This can slow down a network scan as it attempts to elicit additional information from a seemingly open port. The TARPIT chain can consume router and/or firewall resources by appearing to be an open connection, so chaostables provides the DELUDE chain. It will make ports appear to be open on an initial connect (SYN), but revert to their true closed state for any additional traffic.

Chaostables is quite an interesting use of the netfilter technology and probably uses it in ways that the authors never expected. It may be that only the most paranoid of system administrators will want to implement these chains, but they will be available if needed. In addition, the techniques and code provided in the package are very useful as examples for other applications.

Comments (3 posted)

Security reports

Phishing Attacks Continue to Grow in Sophistication (Netcraft)

Netcraft examines the latest trends in the world of Phishing. "Phishing attacks are continually evolving, as fraudsters develop new strategies and quickly refine them in an effort to stay a step ahead of banking customers and the security community. Here are some of the phishing trends and innovations we noted in 2006".

Comments (none posted)

New vulnerabilities

acroread: multiple vulnerabilities

Package(s):acroread CVE #(s):CVE-2006-5857 CVE-2007-0045 CVE-2007-0046
Created:January 11, 2007 Updated:January 23, 2007
Description: Adobes acrobat reader has the following vulnerabilities:

The Adobe Reader Plugin has a cross site scripting vulnerability that can be triggered by processes malformed URLs. Arbitrary JavaScript can be served by a malicious web server, leading to a cross-site scripting attack.

Maliciously crafted PDF files can be used to trigger two vulnerabilities, if an attacker can trick a user into viewing the files, arbitrary code can be executed with the user's privileges.

Alerts:
Red Hat RHSA-2007:0021-01 2007-01-22
Gentoo 200701-16 2007-01-22
SuSE SUSE-SA:2007:011 2007-01-22
Red Hat RHSA-2007:0017-01 2007-01-11

Comments (1 posted)

bluez-utils: hidd vulnerability

Package(s):bluez-utils CVE #(s):CVE-2006-6899
Created:January 16, 2007 Updated:May 14, 2007
Description: hidd in BlueZ (bluez-utils) before 2.25 allows remote attackers to obtain control of the Mouse and Keyboard Human Interface Device (HID) via a certain configuration of two HID (PSM) endpoints, operating as a server, aka HidAttack.
Alerts:
Red Hat RHSA-2007:0065-01 2007-05-14
Ubuntu USN-413-1 2007-01-24
Mandriva MDKSA-2007:014 2006-01-15

Comments (none posted)

horde-kronolith: local file inclusion

Package(s):horde-kronolith CVE #(s):CVE-2006-6175
Created:January 17, 2007 Updated:March 7, 2008
Description: Kronolith contains a mistake in lib/FBView.php where a raw, unfiltered string is used instead of a sanitized string to view local files. An authenticated attacker could craft an HTTP GET request that uses directory traversal techniques to execute any file on the web server as PHP code, which could allow information disclosure or arbitrary code execution with the rights of the user running the PHP application (usually the webserver user).
Alerts:
Gentoo 200701-11 2007-01-16

Comments (none posted)

kdenetwork: denial of service

Package(s):kdenetwork CVE #(s):CVE-2006-6811
Created:January 11, 2007 Updated:February 1, 2007
Description: The KsIRC 1.3.12 utility in kdenetwork is vulnerable to a remote denial of service attack that can be caused by a malicious IRC server sending a long PRIVMSG string. This causes an assertion failure and an associated NULL pointer dereference.
Alerts:
Gentoo 200701-26 2007-01-29
rPath rPSA-2007-0007-1 2007-01-15
Ubuntu USN-409-1 2007-01-15
Mandriva MDKSA-2007:009 2007-01-10

Comments (none posted)

libgtop2: buffer overflow

Package(s):libgtop2 CVE #(s):CVE-2007-0235
Created:January 15, 2007 Updated:August 9, 2007
Description: The /proc parsing routines in libgtop are vulnerable to a buffer overflow. If an attacker can run a process in a specially crafted long path then trick a user into running gnome-system-monitor, arbitrary code can be executed with the user's privileges.
Alerts:
Fedora FEDORA-2007-657 2007-08-02
Red Hat RHSA-2007:0765-01 2007-08-07
Debian DSA-1255-1 2007-01-31
rPath rPSA-2007-0014-1 2007-01-23
Gentoo 200701-17 2007-01-23
Mandriva MDKSA-2007:023 2007-01-18
Ubuntu USN-407-1 2007-01-15

Comments (none posted)

libneon: denial of service

Package(s):libneon CVE #(s):CVE-2007-0157
Created:January 13, 2007 Updated:January 17, 2007
Description: The URI parser in neon versions 0.26.0 through 0.26.2 has a denial of service vulnerability. Remote servers can cause a crash by sending a URI with non-ASCII characters.
Alerts:
Mandriva MDKSA-2007:013 2007-01-12

Comments (none posted)

libsoup: denial of service

Package(s):libsoup CVE #(s):CVE-2006-5876
Created:January 13, 2007 Updated:January 29, 2007
Description: The libsoup HTTP library does not sanitize input sufficiently when parsing HTTP headers. This can be exploited to cause a denial of service.
Alerts:
Fedora FEDORA-2007-109 2007-01-29
Mandriva MDKSA-2007:029 2006-01-26
Ubuntu USN-411-1 2007-01-23
rPath rPSA-2007-0015-1 2007-01-23
Debian DSA-1248-1 2007-01-12

Comments (none posted)

oftpd: denial of service

Package(s):oftpd CVE #(s):CVE-2006-6767
Created:January 16, 2007 Updated:January 17, 2007
Description: By specifying an unsupported address family in the arguments to a LPRT or LPASV command, an assertion in oftpd will cause the daemon to abort. Remote, unauthenticated attackers may be able to terminate any oftpd process, denying service to legitimate users.
Alerts:
Gentoo 200701-09 2007-01-15

Comments (none posted)

opera: multiple vulnerabilities

Package(s):opera CVE #(s):CVE-2007-0126 CVE-2007-0127
Created:January 13, 2007 Updated:January 17, 2007
Description: The opera browser has a heap overflow vulnerability involving the DHT markers in JPEG files. If a specially crafted JPEG files is read on a web site, arbitrary code may be executed with the privileges of the user.

Also, the createSVGTransformFromMatrix() function does not correctly handle passed-in objects, this can be used to execute arbitrary code.

Alerts:
SuSE SUSE-SA:2007:009 2007-01-15
Gentoo 200701-08 2007-01-12

Comments (none posted)

wget: denial of service

Package(s):wget CVE #(s):CVE-2006-6719
Created:January 11, 2007 Updated:January 23, 2007
Description: The wget http file retriever application has a problem with the ftp_syst function in ftp-basic.c. A malicious FTP server which sends a large number of blank 220 responses to the SYST command can cause wget to crash, resulting in a denial of service.
Alerts:
rPath rPSA-2007-0011-1 2007-01-23
Mandriva MDKSA-2007:017 2006-01-15
Fedora FEDORA-2007-043 2007-01-10
Fedora FEDORA-2007-037 2007-01-10

Comments (2 posted)

wordpress: multiple vulnerabilities

Package(s):wordpress CVE #(s):CVE-2006-6808 CVE-2007-0107 CVE-2007-0109
Created:January 16, 2007 Updated:January 17, 2007
Description: When decoding trackbacks with alternate character sets, WordPress does not correctly sanitize the entries before further modifying a SQL query. WordPress also displays different error messages in wp-login.php based upon whether or not a user exists. David Kierznowski has discovered that WordPress fails to properly sanitize recent file information in /wp-admin/templates.php before sending that information to a browser. An attacker could inject arbitrary SQL into WordPress database queries. An attacker could also determine if a WordPress user existed by trying to login as that user, better facilitating brute force attacks. Lastly, an attacker authenticated to view the administrative section of a WordPress instance could try to edit a file with a malicious filename; this may cause arbitrary HTML or JavaScript to be executed in users' browsers viewing /wp-admin/templates.php.
Alerts:
Gentoo 200701-10 2007-01-15

Comments (none posted)

Updated vulnerabilities

apache: cross-site scripting

Package(s):apache CVE #(s):CVE-2006-3918
Created:August 9, 2006 Updated:April 4, 2008
Description: From the Red Hat advisory: "A bug was found in Apache where an invalid Expect header sent to the server was returned to the user in an unescaped error message. This could allow an attacker to perform a cross-site scripting attack if a victim was tricked into connecting to a site and sending a carefully crafted Expect header."
Alerts:
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)

apache-mod_auth_kerb: off-by-one error

Package(s):apache-mod_auth_kerb CVE #(s):CVE-2006-5989
Created:November 24, 2006 Updated:January 23, 2007
Description: An off-by-one error in the der_get_oid function in mod_auth_kerb 5.0 allows remote attackers to cause a denial of service (crash) via a crafted Kerberos message that triggers a heap-based buffer overflow in the component array.
Alerts:
Gentoo 200701-14 2007-01-22
Debian DSA-1247-1 2007-01-08
Red Hat RHSA-2006:0746-01 2006-12-06
Fedora FEDORA-2006-1341 2006-11-29
Mandriva MDKSA-2006:218 2006-11-23

Comments (none posted)

avahi: denial of service

Package(s):avahi CVE #(s):CVE-2006-6870
Created:January 5, 2007 Updated:January 15, 2007
Description: A flaw was discovered in Avahi's handling of compressed DNS packets. If a specially crafted reply were received over the network, the Avahi daemon would go into an infinite loop, causing a denial of service.
Alerts:
Fedora FEDORA-2007-019 2007-01-15
Mandriva MDKSA-2007:003 2007-01-08
Ubuntu USN-402-1 2007-01-05

Comments (none posted)

bind: denial of service

Package(s):bind CVE #(s):CVE-2006-4095 CVE-2006-4096
Created:September 7, 2006 Updated:February 1, 2007
Description: Bind has two denial of service vulnerabilities.

Recursive servers queries for SIG records will trigger an assertion failure if more than one RR set is returned.

An INSIST failure can be triggered by sending a large number of recursive queries.

Alerts:
Fedora FEDORA-2007-164 2007-01-31
Gentoo 200609-11 2006-09-15
Slackware SSA:2006-257-01 2006-09-15
Fedora FEDORA-2006-966 2006-09-11
Debian DSA-1172-1 2006-09-09
Mandriva MDKSA-2006:163 2006-09-08
rPath rPSA-2006-0166-1 2006-09-08
Ubuntu USN-343-1 2006-09-07
OpenPKG OpenPKG-SA-2006.019 2006-09-07

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:
Debian DSA-1208-1 2006-11-11
Gentoo 200611-04 2006-11-09

Comments (none posted)

busybox: insecure password generation

Package(s):busybox CVE #(s):CVE-2006-1058
Created:May 5, 2006 Updated:May 2, 2007
Description: The BusyBox 1.1.1 passwd command does not use a proper salt when generating passwords. This would create an instance where a brute force attack could take very little time.
Alerts:
Red Hat RHSA-2007:0244-02 2007-05-01
Fedora FEDORA-2006-511 2006-05-04
Fedora FEDORA-2006-510 2006-05-04

Comments (2 posted)

bzip2: race condition and infinite loop

Package(s):bzip2 CVE #(s):CAN-2005-0953 CAN-2005-1260
Created:May 17, 2005 Updated:January 10, 2007
Description: A race condition in bzip2 1.0.2 and earlier allows local users to modify permissions of arbitrary files via a hard link attack on a file while it is being decompressed, whose permissions are changed by bzip2 after the decompression is complete. Also specially crafted bzip2 archives may cause an infinite loop in the decompressor.
Alerts:
rPath rPSA-2007-0004-1 2007-01-09
Debian DSA-741-1 2005-07-07
Red Hat RHSA-2005:474-01 2005-06-16
OpenPKG OpenPKG-SA-2005.008 2005-06-10
SuSE SUSE-SR:2005:015 2005-06-07
Debian DSA-730-1 2005-05-27
Mandriva MDKSA-2005:091 2005-05-18
Ubuntu USN-127-1 2005-05-17

Comments (2 posted)

cacti: multiple vulnerabilities

Package(s):cacti CVE #(s):CVE-2006-6799
Created:January 1, 2007 Updated:January 26, 2007
Description: The network monitoring and graphing frontend Cacti has three vulnerabilities. The cmd.php script allows command line usage and is also installed in a web-accessible location. The cmd.php input is insufficiently sanitized, a passed-in URL can be used to inject arbitrary SQL code. The cmd.php script can be used by a remote attacker to execute arbitrary shell commands via improperly sanitized results from SQL queries.
Alerts:
Gentoo 200701-23 2007-01-26
Debian DSA-1250-1 2007-01-17
Mandriva MDKSA-2007:015 2007-01-15
SuSE SUSE-SA:2007:007 2007-01-12
OpenPKG OpenPKG-SA-2007.001 2007-01-01

Comments (none posted)

cpio: arbitrary code execution

Package(s):cpio CVE #(s):CVE-2005-4268
Created:January 2, 2006 Updated:May 8, 2007
Description: Richard Harms discovered that cpio did not sufficiently validate file properties when creating archives. Files with e. g. a very large size caused a buffer overflow. By tricking a user or an automatic backup system into putting a specially crafted file into a cpio archive, a local attacker could probably exploit this to execute arbitrary code with the privileges of the target user (which is likely root in an automatic backup system).
Alerts:
rPath rPSA-2007-0094-1 2007-05-07
Red Hat RHSA-2007:0245-02 2007-05-01
Ubuntu USN-234-1 2006-01-02

Comments (none posted)

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

Package(s):cyrus-sasl CVE #(s):CVE-2006-1721
Created:April 21, 2006 Updated:September 4, 2007
Description: Cyrus-SASL contains an unspecified vulnerability in the DIGEST-MD5 process that could lead to a Denial of Service. An attacker could possibly exploit this vulnerability by sending specially crafted data stream to the Cyrus-SASL server, resulting in a Denial of Service even if the attacker is not able to authenticate.
Alerts:
Red Hat RHSA-2007:0878-01 2007-09-04
Red Hat RHSA-2007:0795-01 2007-09-04
SuSE SUSE-SA:2006:025 2006-05-05
Fedora FEDORA-2006-515 2006-05-04
Debian DSA-1042-1 2006-04-25
Mandriva MDKSA-2006:073 2006-04-24
Ubuntu USN-272-1 2006-04-24
Gentoo 200604-09 2006-04-21

Comments (none posted)

dbus: denial of service

Package(s):dbus CVE #(s):CVE-2006-6107
Created:December 15, 2006 Updated:February 12, 2007
Description: Unspecified vulnerability in the match_rule_equal function in bus/signals.c in D-Bus before 1.0.2 allows local applications to remove match rules for other applications and cause a denial of service (lost process messages).
Alerts:
rPath rPSA-2006-0233-1 2007-02-09
Red Hat RHSA-2007:0008-01 2007-02-08
Ubuntu USN-401-1 2007-01-04
OpenPKG OpenPKG-SA-2006.041 2006-12-21
Fedora FEDORA-2006-1475 2006-12-19
Mandriva MDKSA-2006:233 2006-12-18
Fedora FEDORA-2006-1464 2006-12-14

Comments (none posted)

dovecot: index cache file handling error

Package(s):dovecot CVE #(s):CVE-2006-5973
Created:November 29, 2006 Updated:May 8, 2007
Description: The dovecot IMAP server has an error in its index cache file handling code which could be exploited by an authenticated user to execute arbitrary code. Only servers with the (non-default) mmap_disable=yes option setting are vulnerable.
Alerts:
Fedora FEDORA-2006-1504 2006-12-27
Fedora FEDORA-2006-1396 2006-12-18
rPath rPSA-2006-0220-1 2006-11-30
Ubuntu USN-387-1 2006-11-28

Comments (none posted)

drupal: code injection

Package(s):drupal CVE #(s):
Created:January 9, 2007 Updated:January 9, 2007
Description: A failure to properly sanitize arguments allows an attacker to inject code into a Drupal system (advisory). There is also a denial of service vulnerability exploitable by users with the ability to post content on the site (advisory).
Alerts:
OpenPKG OpenPKG-SA-2007.003 2007-01-08

Comments (none posted)

elinks: arbitrary file access

Package(s):elinks CVE #(s):CVE-2006-5925
Created:November 16, 2006 Updated:February 1, 2007
Description: The elinks text-mode browser has an arbitrary file access vulnerability in the Elinks SMB protocol handler. If a user can be tricked into visiting a specially crafted web page, arbitrary files may be read or written with the user's permissions.
Alerts:
Gentoo 200701-27 2007-01-30
OpenPKG OpenPKG-SA-2006.043 2006-12-26
Debian DSA-1240-1 2006-12-21
Gentoo 200612-16 2006-12-14
Debian DSA-1228-1 2006-12-05
Debian DSA-1226-1 2006-12-03
Fedora FEDORA-2006-1278 2006-11-21
Fedora FEDORA-2006-1277 2006-11-21
Mandriva MDKSA-2006:216 2006-11-20
Red Hat RHSA-2006:0742-01 2006-11-15

Comments (none posted)

fetchmail: password disclosure and DOS

Package(s):fetchmail CVE #(s):CVE-2006-5867 CVE-2006-5974
Created:January 9, 2007 Updated:March 16, 2007
Description: Fetchmail suffers from a password disclosure vulnerability due to a failure to use secure protocols (advisory) and a denial of service vulnerability (advisory).
Alerts:
SuSE SUSE-SR:2007:004 2007-03-16
Debian DSA-1259-1 2007-02-14
Red Hat RHSA-2007:0018-01 2007-01-31
Slackware SSA:2007-024-01 2007-01-25
Gentoo 200701-13 2007-01-22
Fedora FEDORA-2007-042 2007-01-16
Fedora FEDORA-2007-041 2007-01-16
Mandriva MDKSA-2007:016 2006-01-15
Ubuntu USN-405-1 2007-01-11
rPath rPSA-2007-0003-1 2007-01-09
OpenPKG OpenPKG-SA-2007.004 2007-01-08

Comments (none posted)

ffmpeg: buffer overflows

Package(s):ffmpeg CVE #(s):CVE-2006-4799 CVE-2006-4800
Created:September 14, 2006 Updated:May 28, 2007
Description: the AVI processing code in FFmpeg has a number of buffer overflow vulnerabilities. If an attacker can trick a user into loading a specially crafted crafted AVI, arbitrary code can be executed with the user's privileges.
Alerts:
Gentoo 200609-09 2006-09-13

Comments (2 posted)

Mozilla stuff: multiple vulnerabilities

Package(s):firefox thunderbird seamonkey CVE #(s):CVE-2006-6497 CVE-2006-6498 CVE-2006-6501 CVE-2006-6502 CVE-2006-6503 CVE-2006-6504 CVE-2006-6505
Created:December 20, 2006 Updated:March 12, 2007
Description: The Mozilla Project has released new versions of firefox, thunderbird, and seamonkey to address the usual pile of security issues; see this announcement or this CERT advisory for details.
Alerts:
Debian DSA-1265-1 2007-03-10
Debian DSA-1258-1 2007-02-07
Debian DSA-1253-1 2006-01-27
Ubuntu USN-398-4 2007-01-27
SuSE SUSE-SA:2007:006 2007-01-12
Mandriva MDKSA-2007:011 2007-01-11
Mandriva MDKSA-2007:010 2007-01-11
Gentoo 200701-04 2007-01-10
Ubuntu USN-400-1 2007-01-04
Gentoo 200701-03 2007-01-04
Gentoo 200701-02 2007-01-04
Ubuntu USN-398-2 2007-01-03
Ubuntu USN-398-3 2007-01-04
Ubuntu USN-398-1 2007-01-02
Fedora FEDORA-2006-004 2007-01-02
rPath rPSA-2006-0234-2 2006-12-22
SuSE SUSE-SA:2006:080 2006-12-29
Slackware SSA:2006-357-03 2006-12-25
Slackware SSA:2006-357-01 2006-12-25
Slackware SSA:2006-357-02 2006-12-25
rPath rPSA-2006-0234-1 2006-12-22
Fedora FEDORA-2006-1499 2006-12-21
Fedora FEDORA-2006-1491 2006-12-20
Fedora FEDORA-2006-1492 2006-12-20
Red Hat RHSA-2006:0759-01 2006-12-19
Red Hat RHSA-2006:0760-01 2006-12-19
Red Hat RHSA-2006:0758-01 2006-12-19

Comments (none posted)

freeradius: several vulnerabilities

Package(s):freeradius CVE #(s):CVE-2005-4745 CVE-2005-4746
Created:August 8, 2006 Updated:April 24, 2007
Description: Several remote vulnerabilities have been discovered in freeradius, a high-performance RADIUS server, which may lead to SQL injection or denial of service.
Alerts:
Mandriva MDKSA-2007:092 2007-04-23
Debian DSA-1145-1 2006-08-08

Comments (none posted)

freetype: integer overflows

Package(s):freetype CVE #(s):CVE-2006-0747 CVE-2006-1861 CVE-2006-2493 CVE-2006-2661 CVE-2006-3467
Created:June 8, 2006 Updated:October 10, 2007
Description: The FreeType library has several integer overflow vulnerabilities. If a user can be tricked into installing a specially crafted font file, arbitrary code can be executed with the privilege of the user.
Alerts:
Gentoo 200710-09 2007-10-09
Debian DSA-1178-1 2006-09-16
Ubuntu USN-341-1 2006-09-06
Gentoo 200609-04 2006-09-06
rPath rPSA-2006-0157-1 2006-08-25
Mandriva MDKSA-2006:148 2006-08-24
Red Hat RHSA-2006:0635-01 2006-08-21
Red Hat RHSA-2006:0634-01 2006-08-21
Fedora FEDORA-2006-912 2006-08-14
SuSE SUSE-SA:2006:045 2006-08-01
OpenPKG OpenPKG-SA-2006.017 2006-07-28
Ubuntu USN-324-1 2006-07-27
Slackware SSA:2006-207-02 2006-07-27
Mandriva MDKSA-2006:129 2006-07-20
Gentoo 200607-02 2006-07-09
SuSE SUSE-SA:2006:037 2006-06-27
Mandriva MDKSA-2006:099-1 2006-06-13
Mandriva MDKSA-2006:099 2006-06-12
rPath rPSA-2006-0100-1 2006-06-12
Debian DSA-1095-1 2006-06-10
Ubuntu USN-291-1 2006-06-08

Comments (none posted)

ftpd: privilege escalation

Package(s):ftpd CVE #(s):CVE-2006-5778
Created:November 10, 2006 Updated:February 14, 2007
Description: Ftpd is vulnerable to a privilege escalation attack, an incorrect seteuid() call can be used by an FTP user to gain unauthorized access to files or directories.
Alerts:
Gentoo 200611-05:02 2006-11-10
Debian DSA-1217-1 2006-11-20
Gentoo 200611-05 2006-11-10

Comments (none posted)

gcc: file overwrite vulnerability

Package(s):gcc CVE #(s):CVE-2006-3619
Created:September 6, 2006 Updated:March 14, 2008
Description: The fastjar utility found in the GNU compiler collection does not perform adequate file path checking, allowing the creation or overwriting of files outside of the current directory tree.
Alerts:
Mandriva MDVSA-2008:066 2007-03-13
Red Hat RHSA-2007:0473-01 2007-06-11
Red Hat RHSA-2007:0220-02 2007-05-01
Debian DSA-1170-1 2006-09-06

Comments (none posted)

gdb: buffer overflow

Package(s):gdb CVE #(s):CVE-2006-4146
Created:September 15, 2006 Updated:June 12, 2007
Description: A buffer overflow in dwarfread.c and dwarf2read.c debugging code in GNU Debugger (GDB) 6.5 allows user-assisted attackers, or restricted users, to execute arbitrary code via a crafted file with a location block (DW_FORM_block) that contains a large number of operations.
Alerts:
Red Hat RHSA-2007:0469-01 2007-06-11
Red Hat RHSA-2007:0229-02 2007-05-01
Ubuntu USN-356-1 2006-10-02
Fedora FEDORA-2006-975 2006-09-14

Comments (none posted)

gdm: improper file permissions

Package(s):gdm CVE #(s):CVE-2006-1057
Created:April 19, 2006 Updated:May 2, 2007
Description: The .ICEauthority file may be created with the wrong ownership and permissions; gdm 2.14.2 fixes the problem.
Alerts:
Red Hat RHSA-2007:0286-02 2007-05-01
Mandriva MDKSA-2006:083 2006-05-09
Ubuntu USN-278-1 2006-05-03
Debian DSA-1040-1 2006-04-24
Fedora FEDORA-2006-338 2006-04-19

Comments (none posted)

geoip: path traversal

Package(s):geoip CVE #(s):CVE-2007-0159
Created:January 10, 2007 Updated:January 24, 2007
Description: Geoip fails to do sanity checking on returned filenames, opening up a path traversal vulnerability.
Alerts:
Ubuntu USN-412-1 2007-01-23
Mandriva MDKSA-2007:004 2007-01-08

Comments (none posted)

gnupg: stack overwrite

Package(s):gnupg CVE #(s):CVE-2006-6235
Created:December 12, 2006 Updated:March 13, 2007
Description: A "stack overwrite" vulnerability in GnuPG (gpg) allows attackers to execute arbitrary code via crafted OpenPGP packets that cause GnuPG to dereference a function pointer from deallocated stack memory.
Alerts:
Fedora FEDORA-2007-316 2007-03-12
Fedora FEDORA-2007-315 2007-03-12
SuSE SUSE-SA:2006:075 2006-12-13
Mandriva MDKSA-2006:228 2006-12-11

Comments (3 posted)

gv: stack-based buffer overflow

Package(s):gv CVE #(s):CVE-2006-5864
Created:November 20, 2006 Updated:April 9, 2007
Description: Stack-based buffer overflow in the ps_gettext function in ps.c for GNU gv 3.6.2, and possibly earlier versions, allows user-assisted attackers to execute arbitrary code via a PostScript (PS) file with certain headers that contain long comments, as demonstrated using the DocumentMedia header.
Alerts:
Gentoo 200704-06 2007-04-06
Gentoo 200703-24 2007-03-26
Debian DSA-1243-1 2006-12-28
Debian DSA-1214-2 2006-12-27
Mandriva MDKSA-2006:229 2006-12-13
rPath rPSA-2006-0230-1 2006-12-12
Fedora FEDORA-2006-1438 2006-12-11
Fedora FEDORA-2006-1437 2006-12-11
Ubuntu USN-390-3 2006-12-06
Ubuntu USN-390-2 2006-12-06
Mandriva MDKSA-2006:214-1 2006-12-04
Ubuntu USN-390-1 2006-11-30
Gentoo 200611-20 2006-11-24
Debian DSA-1214-1 2006-11-20
Mandriva MDKSA-2006:214 2006-11-17

Comments (none posted)

gzip: multiple vulnerabilities

Package(s)<