Sponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
LWN.net Weekly Edition for January 31, 2008
Ten-year timeline part 4: the end and the beginning
When your editor started this series, the idea was to have four installments covering the ten-year life (so far) of LWN. Well, this is the fourth installment, and it gets less than halfway there. This is not, it seems, a topic which inspires brevity. So this series will continue past the anniversary, though your editor anticipates picking up the pace a bit for the second five years. There is less to be learned, arguably, by looking at events in the relatively recent past.Anyway, at the end of the third installment, LWN had been unacquired by Tucows and was, once again, on its own. The worst of the dotcom bust may have passed, but it was still a somewhat scary environment in which to be attempting to restart a business. It was, in fact, even scarier than we had thought when we so naively set out to show that we could do a better job of bringing in the cash than Tucows did.
- February 7, 2002: Linus
tries BitKeeper at last.
- February 14, 2002: Sun states that it will "ship a full implementation of the Linux operating system." Dave Whitinger joins LWN.net.
Dave Whitinger was, of course, one of the founders of LinuxToday. He joined LWN with the intent of helping us develop the advertising side of the business. That did not work out as intended, but it is hardly Dave's fault; it was a terrible time to be trying to sell advertising.
- February 28, 2002: Sun cuts off free access to StarOffice, but we had OpenOffice.org by then and didn't mind. BitKeeper starts to settle in as the kernel's source management system.
Linus stuck with BitKeeper after his initial trial, setting a number of things in motion. For the next few years, the use of proprietary software at the core of the kernel development process would be a constant source of unhappiness and worry - and, in fact, the story had just the sort of unhappy ending that some observers had feared. But this was also the move which rationalized the kernel work flow and made the whole system scale; the incredible rate of change we see now would not have been possible without it. The use of BitKeeper also made the community aware of what distributed source control could do and, eventually, inspired the creation of a number of free programs with the same essential features. One could say that the community would have eventually developed these systems on its own without the push from Larry McVoy and BitKeeper, and that's probably true. But the fact is: we didn't do it at that time, so we had no real alternative to BitKeeper.
- March 7, 2002: Martin
Dalecki's "IDE cleanup" patches start to raise concerns among kernel
developers, who have this strange notion that their disks should
actually work. A petition against the use of BitKeeper circulates on
the net. Eric Raymond goes around telling the world that the kernel
development process is "in crisis."
- March 14, 2002: Richard Stallman claims that the GNU HURD will be ready by the end of the year. MandrakeSoft pleads for donations to keep the business alive - and LWN does too. Martin Dalecki officially takes over IDE maintenance - and breaks more systems.
We got about $5,000 from our initial plea for donations. It was a real act of generosity on the part of our readers, but one does not keep a business with five employees going for very long with that sort of money.
- March 28, 2002: The
proposed "consumer broadband and digital television promotion act"
would require DRM technology in all software which touches digital
media. Lineo lays off more staff.
- April 25, 2002: More
BitKeeper flames. Lineo goes through a "recapitalization" effort to be
able to do things like pay its employees.
- May 2, 2002:
OpenOffice.org 1.0 is released.
- June 6, 2002: LWN switches to the "new" site code. Red Hat applies for a few software patents. ADEOS, a real-time system which avoids the RTLinux patent, is released. UnitedLinux launches. Mozilla 1.0 is released.
It is amazing how many readers hated the new code. Certainly there were a lot of silly things in the initial version of the site; we fixed a number of them in a hurry. Many readers disliked the ability to post comments - often posting comments to that effect. The addition of comments was something we thought about carefully for a long time; we were quite concerned that they could ruin the feel of the site. In the end, it seems, trusting our readers has paid off; the quality of the conversation here is often quite good.
UnitedLinux was a cooperative effort between Caldera, Conectiva, SuSE, and Turbolinux; the idea was to join together to create a common base from which each could then craft a separate product. The effort was never all that successful, and the presence of Caldera would, of course, doom it outright in the end. But it was a big deal at the time. It is interesting to see that Mandriva (despite MandrakeSoft's refusal to join UnitedLinux) and Turbolinux are now attempting a very similar sort of arrangement.
- June 13, 2002: Secure
Computing Corporation claims patents on SELinux.
- June 27, 2002: The 2002
kernel summit sets October 31 as the date for the 2.6 feature
freeze. GNOME 2.0 is released.
- July 4, 2002: Darl McBride
takes over at SCO.
- July 25, 2002: LWN announces "the end of the road." The "IDE cleanup" patch series (up to number 100) causes system lockups and file corruption. Debian GNU/Linux 3.0 ("woody") is released. Version 1.0 of the Ogg Vorbis codec is released.
By the end of July, we had come to realize that the advertising business was not going to work out for LWN, and we were short of other ideas. The bank account had reached a point where we could not pay even very small expenses. So we concluded that it was time to throw in the towel and try something else - though we had no clue of what "something else" might be. It was with a heavy heart that we announced our plan to shut down the site.
What happened next is that our donation box, which had sat mostly empty after the initial announcement, was suddenly topped up to the tune of about $35,000. Many of the donations came with notes to the effect of "use this to throw a big party." This, shall we say, got our attention. We decided that, just maybe, the subscription idea was worth a try after all, and decided to make a go of it. It was not the end after all.
- August 1, 2002: A new
beginning. HP tries to use the DMCA to shut down disclosure of
security holes.
- August 15, 2002: Distributions from MandrakeSoft, Red Hat, and SuSE are certified to be compliant with the Linux Standard Base.
This was when our credit card merchant bank at the time decided that all those donations might just be fraudulent. So they seized the money back out of our bank account. That, too, got our attention. It took a few months and some lawyer time to get the money you all had sent in our direction; during that time, it was money from PayPal (the subject of everybody else's horror stories) that kept the lights on while our main source of cash was blocked.
Needless to say, we got a new merchant bank, which we still use to this day. The new bank exhibits a rather higher clue level than the old one did, but we also learned a valuable lesson: don't mess with the credit card money pipeline. Every now and then, somebody asks why we don't accept pure donations; this is why.
- August 22, 2002: Martin
Dalecki quits and the entire series of 115 "IDE cleanup" patches is
deleted from the 2.5 kernel.
- August 29, 2002: British
Telecom's attempt to patent the web dies in court. The BitKeeper
license changes. Caldera becomes the SCO Group.
- September 12, 2002: Some patches get dropped after Linus starts running his mail through a spam filter.
It's hard to believe that, only 5+ years ago, somebody with an email address as well distributed as Linus's could get by without spam filtering. There are a lot of free "productivity" applications, but, arguably, few have actually increased productivity to the extent that SpamAssassin has.
- September 26, 2002: The first development release of the "Phoenix" browser is announced. UnitedLinux upsets the community by releasing a closed beta.
Phoenix was the Mozilla Foundation's answer to (relatively) lightweight browsers like Galeon, which had managed to turn the Gecko engine into something which was truly usable. The Phoenix browser proved popular, and eventually became the tool now known as Firefox.
- October 3, 2002: The first subscriber-only weekly edition. Eldred v. Ashcroft is argued in the U.S. Supreme Court.
Eldred v. Ashcroft, argued by Lawrence Lessig, was an attempt to roll back copyright extension in the US; it eventually was unsuccessful. To this day, there still has not really been a successful challenge to the extensions to copyright passed over the last few decades - though some especially nasty attempts to make things even worse were defeated.
With the October 3, 2002 edition, LWN adopted the new policy of requiring subscriptions in order to read our original content prior to the publication of the weekly edition. That policy has stayed essentially unchanged since then, despite the occasional temptation to increase the subscriber-only period. Subscription rates have also stayed unchanged, even though raising them is also tempting.
Subscriptions have certainly been successful, in that they have kept the operation going in the years since then. And there is a real joy associated with being truly answerable to our readers instead of advertisers. Nonetheless, it is a challenging business; people do not like to pay to read web-based content. The fact that so many of our readers are willing to do so is most gratifying. Trends in other parts of the net are moving away from this approach, though, with formerly subscription sites moving to pure advertising models. So it will be interesting to see how it all plays out in the future.
Meanwhile, next week's installment will look at how things went for Linux (and LWN) starting toward the end of 2002. Stay tuned.
LCA: Bruce Schneier on the two sides of security
The conference portion of linux.conf.au opened on Wednesday morning with a keynote by Bruce Schneier. LCA is a sold-out event; in fact, there are rather more attendees than can be fit into the hall where the keynotes are held. Thus the room was packed, with the second-class citizens - those with yellow badges who put off registration until late - watching a remote feed in a separate room. Those folks may have had a more distant experience, but it was almost certainly a cooler one too.Bruce's key point is that we need to rethink how we try to achieve security, though it took a while to explain just why that is. Security, he says, has two components:
- The feeling of security: that which helps us to sleep well
at night.
- The reality of security: whether we are, in fact, secure.
These two aspects of the problem are entirely separate from each other, but they both have to be addressed if our security goals are to be achieved.
Security is always a set of tradeoffs which we are all making every day. As an example, consider that, in all likelihood, nobody in the audience was wearing a bulletproof vest. It's not that the vests do not work; instead, nobody feels that the cost of wearing a bulletproof vest is justified given the risk. On a bigger scale, the answer to the question of how to prevent more 9/11-like attacks is clear: ban all aircraft. In fact, that was done in the US for a few days after those attacks, but, in the longer term, that is not a tradeoff that people are willing to make.
So the fundamental question for any security tradeoff is: is it worth it? As it happens, we are quite bad at making that decision. We tend to respond to feelings rather than reality. Spectacular risks drive us more than everyday risks. We fear the strange over the familiar and the personified (think Osama bin Laden) over the anonymous. Involuntary risks are seen as being bigger than those entered into voluntarily. In the end, evolution has equipped us quite well for making tradeoffs in the small communities we lived in many, many thousands of years ago. We are less well equipped for the world we live in now.
Since we respond to feelings more than reality, there are strong economic incentives for solutions which address feelings. The result is snake-oil products and security theater. Sometimes people notice that they are being sold bad security (later Bruce mentioned a US survey which indicated that the Transportation Security Agency is now less trusted than the taxation agency), but, all too often, they don't. They have a poor understanding of the risks and the costs involved, and there are plenty of people with strong interests in confusing the issue.
The security market is a lemons market, one where buyers and sellers have asymmetric access to information. Economic research shows that, in such markets, the bad products tend to drive the good ones out of the market. There is no easy way to evaluate the work which has gone into the creation of a truly secure product, so buyers respond to other, less reliable signals. Things like price, sales claims, or the Gartner Group. These signals are sloppy and prone to manipulation. When security is outsourced to outside agencies - governments, say - the problem gets even worse.
In the business world, information eventually brings some order to a lemons market. As businesses learn about what really works, access to information evens out - though there is always a problem with very rare, high-cost events where information is not available. In the individual world, though, it is much harder, because fear plays a much bigger role.
The fact of the matter is that fear is wired deeply into how we work - it is a result of a very old part of our brain. As humans, we have the ability to override our fears when reason indicates that we should, but it is a hard thing to do. The default state is that fear rules. So this is Bruce's core point: the feelings matter. All that security theater out there is not entirely stupid; any security solution must address the fears that people feel. We must address both aspects of security.
The problem is where the feeling of security and the reality of security diverge from each other. If only feelings are addressed, security has not really been achieved. If only the reality of security is addressed, people feel insecure and may make bad decisions. Either way, the full problem has not been solved. Addressing this all-too-common problem is hard, though; Bruce knows of no better way than the spreading of good information.
Your editor's perspective follows - nothing from this point on was said during the talk. It seems that he has a point here. Consider some common situations in the free software world:
- A large number of security updates from a distributor may be an
indication that the reality of security is being achieved: problems
are being found and fixed before they are exploited. But all those
updates can undermine the feeling of security. The seemingly endless
stream of Wireshark updates is a case in point; most of these problems
are found through proactive auditing by the developers and have never
been exploited by the Bad Guys. But the feeling of insecurity
associated with Wireshark can be strong. This feeling can push users
toward other software which, while not having that long history of
security updates, is actually less secure.
- A system running SELinux may, in fact, be highly secure. But many administrators still turn it off. SELinux does not make them feel secure because they do not understand it, and they fear (rightly or wrongly) that it will interfere with the proper operation of the system. But, by turning it off, they undoubtedly expose themselves to a number of attacks which SELinux would block.
We should hear Bruce's point and think a bit more about how we can ensure that free software creates the feeling of security - but a feeling which is backed up by real security. It's a hard problem, one which lacks technical solutions. But we'll find ourselves less secure than we would otherwise be if we do not address that side of the issue.
A ten-year retrospective from LWN's other co-founder
Hello to all LWN readers! For the tenth anniversary of LWN, I've been dragged out of my closet to say a few words. Am I stunned that LWN is still going after 10 years? Not really. Much more stunning to me is the realization that the number of years LWN has been published without me are now almost double the number of years it was published with me. That is much harder to get over. As a result, all new readers from 2002 on have no reason to know who I am or what I've written in the past. For those of you that remember me and have asked about me, thank you and rest assured that I haven't forgotten you either.My name is Elizabeth Coolbaugh (Liz) and I was there for the very first issue as well as many issues that followed in 1998 through 2001. I've always said it was the very best job I ever had. I wish for all of you, if you haven't experienced it yet, a job where your first weeks of work are greeted with happy, enthusiastic letters. As the years went by, letters of praise, though much sparser, never totally ceased. You couldn't have a better incentive to work harder and harder!
Jon has done an excellent job of going over the history of the first few years already, so all I can add is some tidbits or personal viewpoints. I'll mention that for me, the start of LWN was actually back in the early 1980's, when Jon, Becky and I came together as a programming team in the then infamous "Assembly Language Programming" class offered through the Engineering School at CU Boulder. We got a chance to experience lots of late nights, interesting hardware experiences and how to keep going with pizza, chocolate, caffeine, etc. That is a good way to get to know your future business partners. Jon and Becky never let me down and we all found different strengths to add to the mix. Forrest was around, too, though not working with us directly at the time.
Jon mentioned that I was between jobs at the time we began. In fact, I had left NCAR three months pregnant. I loved working at NCAR for many, many years, but I had always said that I would leave it when the work stopped being fun. It actually stopped being fun about two years before that, but I had weathered rough times before and waited to make sure the situation wasn't going to turn-around before choosing to move on. The challenge of a new baby on the way (and the continuing challenge of the Multiple Sclerosis that eventually led to my departure from LWN) finally made it "the right time".
So I'd actually had most of a year off to recuperate, re-organize,
have a baby and test the job market waters. What I wanted was a job
that used my professional skills and yet was part-time, to help me
keep the health I'd regained. What a pipe-dream! Companies that
![[Liz in Singapore]](/2001/features/Singapore/images/liz-sm.jpg)
would have gladly recruited me full-time just tossed my resume into
the nearest recycle bin. The nicer ones told me to go out and find
someone else with identical skills who wanted to job-share a full-time
job and they would be willing to consider the possibility. Not
bloody likely.
So when Jon and I were having lunch and he suggested we might be able to work together to create something giving me what I wanted and allowing him to eventually leave NCAR, it seemed to be the right idea at the right time. I never regretted the decision, but in fact, I had a full-time working spouse to cushion the decision. Brandon's reaction (my husband) to becoming the sole support of the family and a new father in one fell swoop was a little different -- much like a deer full-blinded by headlights.
In the spirit of true confessions, though I had fifteen years experience in the computing field and had worked with many different operating systems, VMS and Solaris being primary, I'd never actually touched a Linux system. Jon's unwavering belief in my ability to pick it all up in a heartbeat was both daunting and encouraging at the same time. So I installed my first Linux system only three or four months before we first started publishing. It did give me a fresh, unbiased view of the whole community, though. Okay, not totally unbiased. I did sit on the emacs side of the whole emacs/vi war.
To get started, I subscribed to say, a hundred different newsgroups and mailing lists full of people I'd never met, topics I'd never heard of and flame wars I didn't care to read. It was truly a new skill to develop to learn to skim through them searching for the topics people cared about, the posts that actually carried real information and gently lift each little kernel of "news" out and place in into the newsletter, then wait to hear how well I'd done.
The response was totally overwhelming. I will never, ever forget the emails we received those first couple of months. New people were finding us each week and so the responses kept coming in. They drove me to try and make my contributions worthy of the praise they sent. It is because of those emails that I'm not surprised LWN is still out there today. People wanted and needed what we had to offer. Jon's vision of what people liked and wanted has always been clear and that is another important piece of why LWN is still going strong.
My take on the Red Hat Support fiasco: I have no hard feelings. Although my work as a systems administrator had always included supporting people and I had enjoyed the interaction, I had no idea what I was getting into offering 24 hour support from my home. Just as my daughter was getting old enough to give me a full-night's sleep, I was getting phone calls at 2am and 3am, having to wake up to a fully alert state and go into emergency fix-it mode. I'm surprised I survived until all the contracts we had sold finally expired. In the long run, Red Hat's ideas gave us the courage to start our own business and since writing for LWN was what I learned to love, I consider the end result to have worked out for the best. I also carefully noted for the future that telephone support work was definite going to be a last resort for any future career moves.
Meanwhile, since the few contracts we had didn't bring in enough to pay the bills, let alone enough to support Jon's full-time entry, I also did contract work as a technical writer, remote or on-site administration of Linux for some local companies and I don't even remember what else. Eventually, Jon had to take the risk, forgo waiting for a reliable income and quit his day job in order to increase the income stream. Note that his early work on LWN was always done in addition to continuing his full-time job and trying to increase our income stream at the same time. No wonder he got grumpy if I was out sick or worse, got to head to a fun Linux conference, leaving him to pick up the slack! Of course, it was terrifying in turn for me when the situation reversed and Jon was unavailable. Picking up the kernel page for the week? Ack! I didn't usually complain. Instead, I kept my head low, worked hard and hoped not to see too many corrections or criticisms come in.
It was wonderful for both Jon and I when we were finally able to add Becky to the mix. I think initially we were only able to scrape up enough to pay her for 10 hours a week, but every hour helped. I haven't forgotten, Becky (okay, it should be Rebecca, but she'll always be Becky to me), the hours you put in at a very low rate of pay. Of course, we did pay you first -- the downside to being the business owners for us.
Over the course of the next couple of years, we continued to bring in our income from other sources. We did actually initiate putting some advertising on our site and it brought in a tiny amount of money, but the bread and butter of the company continued to be contract work done in addition to the weekly publication. That included our most successful side foray, building and teaching Linux classes.
What else did I love about LWN? I so enjoyed the friendships I made throughout so many different communities. Will Rogers once said he never met a man he didn't like. Well, I've met many! But truly, in all the years I worked for LWN, I never met anyone I didn't like. Sometimes people I liked said things or did things that I didn't like, but underneath it, they were all good people, smart, idealistic and very strongly opinionated. That was part of what I liked and enjoyed, so I never held people's opinions against them.
The conferences I attended and at which I spoke were like the icing on the cake. I got to meet in-person people I had only come to know through newsgroups and mailing lists or occasionally personal correspondence. I got to meet even more people and share in the excitement. And yes, I do remember the late nights going out for food, drink and conversation with you -- the Atlanta Showcase, LinuxWorld San Jose, Embedded Systems Conference San Jose, LinuxWorld New York, the Colorado Linux Info Quest and the Singapore Linux Conference. Each one provides me with rich memories. My trip out to Singapore was one high-point. So many good and wonderful people and such a wonderful experience. I thought it was to be the first of many international conferences that I would be attending and I am still so sad that it was my last. I particularly regret never making it out to any of early Linux conferences in India, despite invitations.
Professionally, though, the highlight of the work was actually developing myself as a journalist, rather than a computer expert. I enjoyed researching more in-depth articles. When rumors floated my way, I loved actually going out and contacting the people involved first hand by telephone -- short-circuiting email and the rest, to discuss the issues and get their first-hand viewpoints. Since our community wasn't exactly hounded by the media back then, everybody actually wanted to talk to me and was more than happy to give me the straight scoop, instead of just seeing themselves misquoted elsewhere the next day, with the resultant flames. Best of all, I was occasionally able to get the sources of both sides of a controversy together and talk. I can think of at least twice where problems got resolved as a result, people got together and I got the scoop on a story the next day that had literally changed as a result of my work. Very heady stuff.
Jon has already done an excellent job of covering our experience with the dot-com bubble, so I won't add to his description. It was truly a unique life experience that we enjoyed to the fullest, knowing that another like it was unlikely to come by us again. We were very fortunate in our decisions and I agree that the people at Tucows were extremely good to us.
Well, at this point, all this happened a long time ago. I had a great time and regret nothing I did, only the things I didn't get time to do. For those who have asked after me personally, be assured that health-wise, giving up my job was again the right choice at the right time and I'm doing much, much better than I was in August of 2001. You're still not likely to see me back any time in the near future. I focus my research skills now-a-days on tracking traditional and alternative medical discoveries, implementing what seems good to me and serving as an ad-hoc resource for other family members. Oh yes, and serving as a chauffeur to my daughter, who is now ten years old, just as LWN is. Take care, all of you, remember to be proud of what you are achieving and *always* have fun doing it. I stand by my opinion that when work ceases to be fun, it is time for a change.
Page editor: Jake Edge
Security
Finding bugs lurking in the DOM
The Document Object Model (DOM) for HTML is quite useful for handling a variety of dynamic effects for web pages, but it is complex. It interacts with Javascript and CSS (or they with it) in ways that are sometimes surprising—the DOM has often been the source of browser bugs. A new project, from well-known DOM bug finder Michal Zalewski, seeks to systematically exercise the DOM in browsers to eliminate as many holes as it can.
The project, with the unassuming name of DOM access checker (or dom-checker) was just announced on the full-disclosure mailing list (along with Bugtraq and others). Zalewski and colleague Filipe Almeida, both of Google, describe their tool as follows:
![[DOM Checker]](/images/dom-checker_sm.png)
The checker consists of a three HTML files and a Javascript configuration file that can be loaded from the internet via HTTP (a live version is available from the project website) or from the local disk, using the file:// protocol. Ideally, they should be loaded from both places and give the same results. The screenshot for a sample run using Firefox 3 (Fedora/3.0b3pre-0.beta2.12.nightly20080121.fc9 for the curious) is at left.
After pressing the "Click here to begin tests" button, the Javascript test harness runs 15 major tests, each with many separate subtests. Each subtest reports success or failure to the screen as it runs. Firefox 3 failed 15 of the 1500 or so checks in the standard set of tests.
According to the announcement, "DOM Checker had been used to find a number of major security bypass and information disclosure problems in several popular browsers." Zalewski and Almeida worked with the browser teams to resolve the most serious issues. But, common browsers will still fail up to 30 of the less important tests—for privacy, rather than security, holes.
The hope is that the browser vendors pick up these tests to use as part of their quality assurance process. They could also be used for regression testing to find problems that have crept in while fixing other bugs or adding new features. The checker is a framework that could easily be extended with additional tests covering other areas of DOM functionality. With the advent of AJAX, DOM manipulations via Javascript are being used more and more by web sites, so tools to discover these kinds of bugs are welcome.
New vulnerabilities
gforge: cross-site scripting
| Package(s): | gforge | CVE #(s): | CVE-2007-0176 | |||
| Created: | January 28, 2008 | Updated: | January 30, 2008 | |||
| Description: | From the NVD entry: Cross-site scripting (XSS) vulnerability in search/advanced_search.php in GForge 4.5.11 allows remote attackers to inject arbitrary web script or HTML via the words parameter. | |||||
| Alerts: |
| |||||
icu: arbitrary code execution
| Package(s): | icu | CVE #(s): | CVE-2007-4770 CVE-2007-4771 | ||||||||||||||||||||||||||||||
| Created: | January 25, 2008 | Updated: | April 18, 2008 | ||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory: Will Drewry reported multiple flaws in the way libicu processed certain malformed regular expressions. If an application linked against ICU, such as OpenOffice.org, processed a carefully crafted regular expression, it may be possible to execute arbitrary code as the user running the application. | ||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||
kernel: several vulnerabilities
| Package(s): | linux-2.6 | CVE #(s): | CVE-2007-2878 CVE-2007-6151 | ||||||||||||||||||||||||||||||
| Created: | January 29, 2008 | Updated: | April 15, 2008 | ||||||||||||||||||||||||||||||
| Description: | From the Debian advisory: Bart Oldeman reported a denial of service (DoS) issue in the VFAT filesystem that allows local users to corrupt a kernel structure resulting in a system crash. This is only an issue for systems which make use of the VFAT compat ioctl interface, such as systems running an 'amd64' flavor kernel. ADLAB discovered a possible memory overrun in the ISDN subsystem that may permit a local user to overwrite kernel memory leading by issuing ioctls with unterminated data. | ||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||
mysql: buffer overflows
| Package(s): | mysql-dfsg-5.0 | CVE #(s): | CVE-2008-0226 CVE-2008-0227 | ||||||||||||
| Created: | January 29, 2008 | Updated: | April 3, 2008 | ||||||||||||
| Description: | From the Debian advisory: Luigi Auriemma discovered two buffer overflows in YaSSL, an SSL implementation included in the MySQL database package, which could lead to denial of service and possibly the execution of arbitrary code. | ||||||||||||||
| Alerts: |
| ||||||||||||||
netkit-ftpd: denial of service
| Package(s): | netkit-ftpd | CVE #(s): | CVE-2007-6263 | |||
| Created: | January 30, 2008 | Updated: | January 30, 2008 | |||
| Description: | From the Gentoo advisory: A remote attacker can send specially crafted FTP data to a server with passive mode and SSL support, causing the ftpd daemon to crash. | |||||
| Alerts: |
| |||||
ngircd: denial of service
| Package(s): | ngircd | CVE #(s): | CVE-2008-0285 | |||
| Created: | January 28, 2008 | Updated: | January 30, 2008 | |||
| Description: | From the NVD entry: ngIRCd 0.10.x before 0.10.4 and 0.11.0 before 0.11.0-pre2 allows remote attackers to cause a denial of service (crash) via crafted IRC PART message, which triggers an invalid dereference. | |||||
| Alerts: |
| |||||
pulseaudio: ignores setuid() return value
| Package(s): | pulseaudio | CVE #(s): | CVE-2008-0008 | ||||||||||||||||||
| Created: | January 25, 2008 | Updated: | February 14, 2008 | ||||||||||||||||||
| Description: | Pulseaudio ignores setuid() return value. A user can cause the call to fail by exhausting the resources in some cases. | ||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||
tikiwiki: multiple vulnerabilities
| Package(s): | tikiwiki | CVE #(s): | CVE-2007-6528 CVE-2007-6526 CVE-2007-6529 | |||
| Created: | January 24, 2008 | Updated: | January 30, 2008 | |||
| Description: | From the Gentoo alert:
Jesus Olmos Gonzalez from isecauditors reported insufficient sanitization of the "movies" parameter in file tiki-listmovies.php (CVE-2007-6528). Mesut Timur from H-Labs discovered that the input passed to the "area_name" parameter in file tiki-special_chars.php is not properly sanitised before being returned to the user (CVE-2007-6526). redflo reported multiple unspecified vulnerabilities in files tiki-edit_css.php, tiki-list_games.php, and tiki-g-admin_shared_source.php (CVE-2007-6529). | |||||
| Alerts: |
| |||||
yarssr: arbitrary code execution
| Package(s): | yarssr | CVE #(s): | CVE-2007-5837 | |||
| Created: | January 28, 2008 | Updated: | January 30, 2008 | |||
| Description: | From the NVD entry: GUI.pm in yarssr 0.2.2, when Gnome default URL handling is disabled, allows remote attackers to execute arbitrary commands via shell metacharacters in a link element in a feed. | |||||
| Alerts: |
| |||||
Updated vulnerabilities
cairo: integer overflow
| Package(s): | Cairo | CVE #(s): | CVE-2007-5503 | |||||||||||||||||||||||||||||||||
| Created: | November 29, 2007 | Updated: | April 10, 2008 | |||||||||||||||||||||||||||||||||
| Description: | Cairo has an integer overflow vulnerability in the PNG image processing code. If a user processes a specially crafted PNG image with an application that is linked against cairo, arbitrary code can be executed with the user's privileges. | |||||||||||||||||||||||||||||||||||
| Alerts: |
| |||||||||||||||||||||||||||||||||||
MySQL: privilege escalation
| Package(s): | MySQL | CVE #(s): | CVE-2007-3781 CVE-2007-5969 | ||||||||||||||||||||||||||||||
| Created: | December 11, 2007 | Updated: | April 7, 2008 | ||||||||||||||||||||||||||||||
| Description: | MySQL Community Server before 5.0.51, when a table relies on symlinks created through explicit DATA DIRECTORY and INDEX DIRECTORY options, allows remote authenticated users to overwrite system table information and gain privileges via a RENAME TABLE statement that changes the symlink to point to an existing file. (CVE-2007-5969)
MySQL Community Server before 5.0.45 does not require privileges such as SELECT for the source table in a CREATE TABLE LIKE statement, which allows remote authenticated users to obtain sensitive information such as the table structure. (CVE-2007-3781) | ||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||
Sun JDK/JRE: multiple vulnerabilities
| Package(s): | Sun JDK/JRE | CVE #(s): | CVE-2007-2435 CVE-2007-2788 CVE-2007-2789 | ||||||||||||||||||
| Created: | June 1, 2007 | Updated: | April 18, 2008 | ||||||||||||||||||
| Description: | An unspecified vulnerability involving an "incorrect use of system classes" was reported by the Fujitsu security team. Additionally, Chris Evans from the Google Security Team reported an integer overflow resulting in a buffer overflow in the ICC parser used with JPG or BMP files, and an incorrect open() call to /dev/tty when processing certain BMP files. | ||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||
Xorg: multiple vulnerabilities
| Package(s): | Xorg | CVE #(s): | CVE-2007-5760 CVE-2007-5958 CVE-2007-6427 CVE-2007-6428 CVE-2007-6429 CVE-2008-0006 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | January 17, 2008 | Updated: | April 4, 2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the X.org security advisory: Several vulnerabilities have been identified in server code of the X window system caused by lack of proper input validation on user controlled data in various parts of the software, causing various kinds of overflows. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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: |
| |||||||||||
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: |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
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: |
| ||||||||||||||||||||
apache: several vulnerabilities
| Package(s): | apache | CVE #(s): | CVE-2007-5000 CVE-2007-6388 CVE-2008-0005 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | January 15, 2008 | Updated: | April 4, 2008 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | A flaw was found in the mod_imap module. On sites where mod_imap was
enabled and an imagemap file was publicly available, a cross-site scripting
attack was possible. (CVE-2007-5000)
A flaw was found in the mod_status module. On sites where mod_status was enabled and the status pages were publicly available, a cross-site scripting attack was possible. (CVE-2007-6388) A flaw was found in the mod_proxy_ftp module. On sites where mod_proxy_ftp was enabled and a forward proxy was configured, a cross-site scripting attack was possible against Web browsers which did not correctly derive the response character set following the rules in RFC 2616. (CVE-2008-0005) | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
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: |
| |||||||||||||||||||||||||||||||||||||||||
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: |
| ||||||||
apt-listchanges: arbitrary code execution
| Package(s): | apt-listchanges | CVE #(s): | CVE-2008-0302 | |||||||||
| Created: | January 17, 2008 | Updated: | January 23, 2008 | |||||||||
| Description: | From the Debian alert: Felipe Sateler discovered that apt-listchanges, a package change history notification tool, used unsafe paths when importing its python libraries. This could allow the execution of arbitrary shell commands if the root user executed the command in a directory which other local users may write to. | |||||||||||
| Alerts: |
| |||||||||||
asterisk: possible SQL injection
| Package(s): | asterisk | CVE #(s): | CVE-2007-6170 | |||||||||
| Created: | December 3, 2007 | Updated: | April 15, 2008 | |||||||||
| Description: | Tilghman Lesher discovered that the logging engine of Asterisk, a free software PBX and telephony toolkit, performs insufficient sanitizing of call-related data, which may lead to SQL injection. | |||||||||||
| Alerts: |
| |||||||||||
bind: off-by-one error
| Package(s): | bind | CVE #(s): | CVE-2008-0122 | ||||||||||||
| Created: | January 22, 2008 | Updated: | March 14, 2008 | ||||||||||||
| Description: | Off-by-one error in the inet_network function in libc in FreeBSD 6.2, 6.3, and 7.0-PRERELEASE and earlier allows context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via crafted input that triggers memory corruption. | ||||||||||||||
| Alerts: |
| ||||||||||||||
boost: denial of service
| Package(s): | boost | CVE #(s): | CVE-2008-0171 CVE-2008-0172 | |||||||||||||||||||||
| Created: | January 17, 2008 | Updated: | March 14, 2008 | |||||||||||||||||||||
| Description: | From the Ubuntu alert: Will Drewry and Tavis Ormandy discovered that the boost library did not properly perform input validation on regular expressions. An attacker could send a specially crafted regular expression to an application linked against boost and cause a denial of service via application crash. | |||||||||||||||||||||||
| Alerts: |
| |||||||||||||||||||||||
cacti: SQL injection vulnerability
| Package(s): | cacti | CVE #(s): | CVE-2007-6035 | ||||||||||||||||||||||||
| Created: | November 22, 2007 | Updated: | February 18, 2008 | ||||||||||||||||||||||||
| Description: | Versions of Cacti prior to 0.8.7a have an SQL injection vulnerability. Remote attackers can execute arbitrary SQL commands via unspecified vectors. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
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: |
| ||||||||||||||
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: |
| ||||||||||||||
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: |
| ||||||||||||||||||||
clamav: integer overflow and off-by-one
| Package(s): | clamav | CVE #(s): | CVE-2007-6335 CVE-2007-6336 | ||||||||||||||||||||||||
| Created: | December 19, 2007 | Updated: | February 13, 2008 | ||||||||||||||||||||||||
| Description: | ClamAV contains integer overflow and off-by-one errors which could be exploited (via specially-crafted email) to execute arbitrary code. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
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: |
| |||||||||||||||||
cups: buffer overflow
| Package(s): | cups | CVE #(s): | CVE-2007-5848 | ||||||||||||
| Created: | January 7, 2008 | Updated: | February 27, 2008 | ||||||||||||
| Description: | From the CVE entry: Buffer overflow in CUPS in Apple Mac OS X 10.4.11 allows local admin users to execute arbitrary code via a crafted URI to the CUPS service. From the rPath advisory: Previous versions of the cups package contain a buffer-overflow weakness. It is not believed that this weakness can be exploited to execute malicious code. | ||||||||||||||
| Alerts: |
| ||||||||||||||
cups: multiple vulnerabilities
| Package(s): | cups | CVE #(s): | CVE-2007-5849 CVE-2007-6358 CVE-2007-4352 CVE-2007-5392 CVE-2007-5393 | ||||||||||||||||||||||||
| Created: | December 19, 2007 | Updated: | April 3, 2008 | ||||||||||||||||||||||||
| Description: | The cups 1.3.5 release fixes a number of vulnerabilities in the PDF filters. Additionally, there is a buffer overflow in the SNMP code and a temporary file vulnerability. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
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: |
| ||||||||
e2fsprogs: integer overflows
| Package(s): | e2fsprogs | CVE #(s): | CVE-2007-5497 | |||||||||||||||||||||||||||
| Created: | December 7, 2007 | Updated: | February 12, 2008 | |||||||||||||||||||||||||||
| Description: | Rafal Wojtczuk of McAfee AVERT Research discovered that e2fsprogs, ext2 file system utilities and libraries, contained multiple integer overflows in memory allocations, based on sizes taken directly from filesystem information. These could result in heap-based overflows potentially allowing the execution of arbitrary code. | |||||||||||||||||||||||||||||
| Alerts: |
| |||||||||||||||||||||||||||||
emacs: buffer overflow
| Package(s): | emacs | CVE #(s): | CVE-2007-6109 | |||||||||
| Created: | December 10, 2007 | Updated: | February 8, 2008 | |||||||||
| Description: | From the National Vulnerability Database: Buffer overflow in emacs allows attackers to have an unknown impact, as demonstrated via a vector involving the command line. | |||||||||||
| Alerts: |
| |||||||||||
emacs: command execution via local variables
| Package(s): | emacs | CVE #(s): | CVE-2007-5795 | |||||||||||||||
| Created: | November 14, 2007 | Updated: | February 5, 2008 | |||||||||||||||
| Description: | From the original Debian problem report: "In Debian's version of GNU Emacs 22.1+1-2, the `hack-local-variables' function does not behave correctly when `enable-local-variables' is set to :safe. The documentation of `enable-local-variables' states that the value :safe means to set only safe variables, as determined by `safe-local-variable-p' and `risky-local-variable-p' (and the data driving them), but Emacs ignores this and instead sets all the local variables." When this setting (which is not the default) is in effect, opening a hostile file could lead to the execution of arbitrary commands. | |||||||||||||||||
| Alerts: |
| |||||||||||||||||
evolution: format string error
| Package(s): | evolution | CVE #(s): | CVE-2007-1002 | |||||||||||||||||||||
| Created: | March 27, 2007 | Updated: | February 27, 2008 | |||||||||||||||||||||
| Description: | A format string error in the "write_html()" function in calendar/gui/ e-cal-component-memo-preview.c when displaying a memo's categories can potentially be exploited to execute arbitrary code via a specially crafted shared memo containing format specifiers. | |||||||||||||||||||||||
| Alerts: |
| |||||||||||||||||||||||
exiftags: multiple vulnerabilities
| Package(s): | exiftags | CVE #(s): | CVE-2007-6354 CVE-2007-6355 CVE-2007-6356 | |||||||||
| Created: | December 31, 2007 | Updated: | April 1, 2008 | |||||||||
| Description: | From the Gentoo advisory: Meder Kydyraliev (Google Security) discovered that Exif metadata is not properly sanitized before being processed, resulting in illegal memory access in the postprop() and other functions (CVE-2007-6354). He also discovered integer overflow vulnerabilities in the parsetag() and other functions (CVE-2007-6355) and an infinite recursion in the readifds() function caused by recursive IFD references (CVE-2007-6356). | |||||||||||
| Alerts: |
| |||||||||||
exiv2: integer overflow
| Package(s): | exiv2 | CVE #(s): | CVE-2007-6353 | ||||||||||||||||||
| Created: | December 21, 2007 | Updated: | January 24, 2008 | ||||||||||||||||||
| Description: | Integer overflow in exif.cpp in exiv2 library allows context-dependent attackers to execute arbitrary code via a crafted EXIF file that triggers a heap-based buffer overflow. | ||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||
firebird: buffer overflow
| Package(s): | firebird | CVE #(s): | CVE-2007-3181 | ||||||
| Created: | July 2, 2007 | Updated: | March 27, 2008 | ||||||
| Description: | The Firebird DBMS has a buffer overflow vulnerability involving the processing of connect requests with an overly large p_cnct_count value. Remote attackers can send a specially crafted request to the server in order to potentially execute arbitrary code with the permissions of the Firebird user. | ||||||||
| Alerts: |
| ||||||||
firefox: multiple vulnerabilities
| Package(s): | firefox | CVE #(s): | CVE-2007-3844 |