Red Hat borrows $500 million
Red Hat has a balance sheet that many other companies would envy. The
company was lucky (and smart) enough to be the first Linux company to go
public during the brief Linux portion of the dotcom bubble; it even had
sufficient time to do a second offering to bring in another pile of cash.
That windfall, along with careful management, left the company with
$329 million in cash and investments at the end of November, 2003
(the last quarter for which numbers are available). That cash pile has
been growing in recent quarters; Red Hat certainly need not be concerned
about running out of money anytime soon.
So one might well wonder why Red Hat has just issued
$500 million in bonds. Why take on half a billion dollars in
long-term (20 years) debt when you haven't really figured out what to do
with the cash you already have? We asked the company, and were told:
We decided to take this great opportunity to capitalize our company
for the purpose of achieving our goal to become the defining
technology company of the 21st century. We are focused on building
and expanding our organization long term.
There are no specific plans for the cash at this time.
In other words, they aren't telling. One may well speculate that there are
acquisitions (big ones) in the works; this idea is reinforced by this
(Raleigh) News & Observer article:
"We believe the time for us as a company to take control of the
market is now," said chief financial officer Kevin Thompson. "What
we've done is capitalize ourselves so that we can react very
quickly to opportunities that come up in the marketplace."
Customers are demanding products that Red Hat can't offer, Thompson
said. It likely will have to buy other companies to add new
products and services.
One assumes that Red Hat has some "opportunities" in mind, but they are not
ready to talk about them at this time.
The truth of the matter is that Red Hat was able to get this money on great
terms. The interest rate on this loan is 0.5%. So Red Hat could simply
put the money into certificates of deposit (currently paying 4% or so in
the U.S. for long terms), pay off the loan in 20 years, and pocket the
interest. If Red Hat invests this money in this way, it has just acquired
a few million dollars per year in free income for the next two decades.
This is not a deal the company could afford to turn down.
The real question, perhaps, is why the (unnamed) investors decided to loan
money to Red Hat on such terms. Long-term U.S. treasury bills pay 4.2% as
of this writing - eight times what Red Hat is paying. The U.S. government
is unlikely to reinvest such money as wisely as Red Hat, but it has the
advantage of its coercive powers when payback time comes. Treasury bills
pay more, and are safer too.
The answer to that question can only lie in the conversion feature of these
bonds. The purchasers can convert the bonds to stock at a rate of about
$25/share at any time. That rate is significantly above Red Hat's current
stock price ($18.50, as of this writing) but, remember, these investors are
working with a twenty-year horizon. The bonds are, essentially, a
long-term call option which enables the investors to get their funds back
if the stock price never goes above $25. Unless Red Hat goes into
bankruptcy, the bond holders will probably do OK.
Red Hat started the first Linux financial boom with its IPO. What we may
be seeing here is the beginning of the second, more sustainable boom.
Serious money is, once again, flowing into Linux companies. The first boom
changed the industry in many ways, and left numerous investors rather
poorer than they were before. The second boom may be seen as when Linux
really took off; it will doubtless bring changes as well. As
always, it is going to be interesting to watch.
Comments (5 posted)
LWN's Obviously Incorrect 2004 Predictions
The new year is upon us, and so, like many other publications, we feel an
irrational urge to wave our hands in the air and make predictions for what
we think the coming year will bring us. So here we go. Needless to say,
anybody who is thinking of acting on any of the following would be well
advised to get a second opinion...
Enterprise Linux
The "enterprise Linux" business came into its own in 2003, as Red Hat, in
particular, found a steady stream of willing customers which drove the
company into a profitable state. Red Hat's enterprise offerings must be
providing value to the company's customers, given the claimed 90% renewal
rate on enterprise support contracts. But the per-system licensing of Red
Hat Enterprise Linux has rubbed some community members the wrong way; many
developers feel that Red Hat's contracts do not reflect the sort of world
they thought they were helping to build.
So, we predict that, in 2004, the enterprise Linux backlash will
grow, and we will begin to see whether that backlash can change the
enterprise Linux market. A number of free enterprise Linux projects are
out there, including CaOS, Whitebox Linux, and UserLinux. These projects
have an uphill road ahead of them; to be successful, they will have to
convince skeptical companies that they will be able to provide high-quality
support for many years into the future. They will also have to make
independent vendors see them as important enough to certify applications
for. Oh, and, of course, they will have to create a top-quality
distribution aimed at the needs of this sort of customer. Creating that
distribution will not be easy, but it may prove to be the simplest of the
challenges faced by any would-be challenger to Red Hat's enterprise
offerings.
The interesting thing is, of course, that these challenges look remarkably
similar to those faced by Linux itself a few years ago, when
the idea that Linux could pull the rug out from under proprietary Unix
systems and challenge Microsoft seemed ludicrous to many. But it
happened. Now, challenging enterprise Linux with truly free Linux looks
like a daunting task. But it may yet be that a free distribution combined
with a distributed network of supporters could supplant today's enterprise
offerings in just the same way that Linux has taken Unix's place. The
community is capable of amazing things. Not everybody would see such an
event as a good thing, but it could happen.
Desktop Linux
The desktop wars will heat up again in 2004. For those of us who
remember the KDE/GNOME flame wars of years past, the relative calm and
cooperation which has prevailed more recently has been a welcome thing.
But there are pressures building which threaten to upset the peace.
The first of those pressures is licensing. Ironically, KDE's choice of the
GPL for its libraries may work against it here. The looser GNOME library
licensing allows its toolkits to be used, royalty-free, with proprietary
applications. Proprietary KDE applications can only be distributed by
paying royalties to Trolltech, which owns the Qt libraries. Many users and
developers
would rather not see proprietary applications exist at all, or, at least,
not without paying those who have developed the underlying toolkit. These people
are happy with KDE's licensing. Most users, of course, don't care.
Distributors, however, usually want to
enable vendors to sell applications on their platforms. This interest will
push them toward the GNOME camp.
The other point, however, is that distributors are increasingly under
pressure to make a choice. Supporting two desktop systems adds to the
total workload of maintaining a distribution, and that costs money which
may not be available. There is a common perception at this point that the
two desktops are functionally identical in all the ways that matter; if
that is true, why bother with two of them?
In 2004, these pressures will lead to rising emotions in the camps of both
desktops as they see decisions being made for or against them. Perhaps the
result will be a greater degree of cooperation between the two development
communities via freedesktop.org or
other mechanisms. Or, perhaps, our newsgroups, web sites, and mailing lists
will once again play host to heated debates and flame wars in vain attempts
to establish one desktop as being superior to the other.
Beyond that, however, the hackers will stay busy and
desktop Linux will amaze us again. In 2003, it was widely
recognized that Desktop Linux has everything that many, if not most,
business users need to get their jobs done. 2004 will be the year that
desktop Linux stops playing catch-up (in some areas, at least) and truly
begins to blaze interesting trails of its own. Projects like Dashboard, GNOME Storage, and Reiser4 are just the beginning
of a wave of innovative projects which will change how we use our
computers.
2004 may not, however, bring Linux into many more homes. A Linux system is
more than adequate for Grandma to send email and wander around on the web.
Your editor insists that his children use Linux for their email, browsing,
and homework tasks, and it handles those jobs well. The sad truth,
however, is that there still needs to
be a Windows system around for other vital tasks - such as playing games.
Home users are not interested in dual-boot systems; until Linux can do
everything they need, they will stick with the same old stuff. Linux may
eventually have a free application base which replaces many of the
commercial offerings currently filling the shelves of computer stores,
but it remains hard to imagine free games, for example, which can compete
with the hit-driven commercial variety. Until there is a lively market for
commercial Linux applications, there will be some hard limits to how many
desktops we can occupy.
Legal issues
The SCO case will drag on, and become more complicated, in 2004.
IBM may well succeed in getting many of SCO's complaints dismissed early in
the year, but SCO probably has a good chance of keeping some of its breach
of contract charges alive. SCO may have to retreat to some of its earliest
charges (i.e. JFS, RCU, NUMA, SMP), but IBM may have to go to trial to
prove that its code in those areas is not derived from SCO's Unix. SCO
can probably muddy the waters enough to keep the judge from dismissing the
case outright.
Even if the IBM case is dismissed in 2004, however, there is the issue of
SCO's threats of copyright infringement suits against Linux users. One may
be tempted to dismiss these threats as just that much more empty SCO
bluster. It is worth considering, however, the pressures that SCO will be
under, including the agenda of its lawyers and the looming "dividend"
payments on the BayStar investment. SCO has no hopes for increasing
revenue from its remaining software products at this point; it must
litigate further to bring in cash. With the lawyers in charge, chances are
that SCO will, indeed, launch new suits.
In fact, the company may well find backbone-challenged Linux users that
will cave in and pay up rather than risk a court battle. Such an event
will do short-term wonders for SCO's stock price and cash flow.
The simple fact is, however, that the SCO Group has still put forward very
little evidence to back up its claim, and what evidence it has
presented has mostly been laughed off the stage. The company's claims to
own the "Unix ABI" will get no further. Beyond that, Novell's new
copyright assertions have the potential to stop the show dead, at least
until that dispute has its own day in court. But, regardless of the validity
of Novell's claims, SCO's case is empty and the world, increasingly, is
seeing that. By the end of 2004, the SCO cases will probably still be
alive in some form, but the end will be in sight.
As an aside, Novell will face a severe test of its credibility in the eyes
of the community. Nobody wants to see the SCO case resurrected in the
future by a Novell which, perhaps after a management change or two, decides
that its Unix copyrights (if they are Novell's) might yet be worth
something. If Novell is serious about being a part of the Linux community,
it needs to make a statement, soon, about just what it intends to do with
the Unix copyrights it claims to own.
The GPL may have its day in court. The SCO Group has, of course,
stated its intent to break the GPL in court. But that company's arguments,
thus far, have failed to impress. SCO's GPL challenges should not get
far. More interesting GPL-oriented cases may come from a different
direction.
Many developers working in the industry are full of stories of rampant GPL
violations, especially where embedded systems are involved. Last year's
episode with the LinkSys WRT54G router is just the small tip of a large iceberg in
this regard. To an extent, people have been willing to look the other way;
it just hasn't seemed worth the trouble to challenge closed-source uses of
GPL-licensed code in many cases. There are developers, however, who are
increasingly unwilling to close their eyes to violations of their
licenses. Expect more challenges against vendors using GPL-licensed code
in non-licensed ways. The lack of any court decisions on the GPL will
eventually embolden a violator to try his luck in front of a judge. At
that point, we will begin to see what the judicial system really
thinks of the GPL.
Security
2004 will make us care more about security. In 2003, we saw an
ominous string of attacks against the servers which support the Linux
development community. There is no reason to believe that these attacks
will stop anytime soon. Sooner or later, perhaps in 2004, somebody is
going to do some
real damage on a scale we have not yet seen. A
major breach, perhaps compromising the systems of many Linux users, will
cost us money, time, and much credibility.
In recent years, most attacks against Linux systems have exploited known
vulnerabilities for which patches existed. A well-managed site is nearly
immune to attacks using known vulnerabilities; all of the major
distributors are quite good (usually) about quickly preparing updates when
a problem comes to light. The attacks we saw at the end of 2003, however,
made use of previously unknown holes in rsync and the kernel. Defending
against unknown vulnerabilities is much harder, and there do exist
attackers who realize this, and who are smart enough to find such
problems. In the coming year, we may well see some truly scary exploits of
this sort of "zero-day" vulnerability.
There is some good news, however. By the end of 2004, we will see wider
deployment of hardened Linux systems. The incorporation of SELinux and
various other security technologies into the Fedora Core distribution
(and, from there, into Red Hat Enterprise Linux) will drive much of this
deployment, and threats from the outside will do the rest. Adding SELinux
is a significant step in the evolution of Linux distributions; if this work
is done properly, Linux users should soon have a much higher level of
security available with a default system install. Proper containment of
security breaches should, for example, make that next web server buffer
overflow be much less of a threat than it is now.
Kernel
2.7 kernel development will begin after the 2.6.0 kernel has had a
few months to stabilize. Expect the 2.7 development series to be quite
different from 2.5, however. By the time that 2.5.0 came out, there was a
massive backlog of patches waiting for inclusion. The 2.4 stabilization
process had taken nearly a year, and there was a long shopping list of
planned changes for 2.5, including the block layer rewrite, expanding the
dev_t device number type, a new loadable module subsystem, a new
kernel build mechanism, asynchronous and direct I/O, and many others.
On the eve of 2.7, the "patch pressure" is far lower. There's no end of
ideas for 2.7, including virtual memory work (page clustering, shareable
page tables, etc), the never-ending desktop interactivity work, and much
internal reworking to eliminate race conditions, and so on.
But many users are (or will be) far happier with
2.6 than they were with 2.4, and the list of features that the Linux kernel
must have to not be jealous of its Unix predecessors is shrinking. The
Linux kernel is maturing, in other words. It may well be that, with 2.7,
the pace of change begins to slow a little.
Or maybe the kernel hackers will come up with some amazing new ideas and
run with them; at that point, all bets are off.
To conclude...
It's going to be an interesting year.
That, perhaps, is the only
truly safe prediction to be found among all the others on this page. All
the rest are offered with no warranty as to their veracity, suitability for
any particular purpose, or connection with any sort of reality whatsoever.
LWN.net does not provide indemnification for users of its predictions -
though purchasers of our "predictions license" (available for a
limited-time special half-price deal through January, 2007) will get a
promise from us to not sue them.
Comments (29 posted)
Some LWN notes
We recently received a message complaining about the lack of "LWN status
update" news in recent times. It is true we have backed off on such
articles; LWN should carry the news, not
be the news. But, for
those who are wondering, here's a brief update.
When we started the subscription program, we set our goal at 4000
individual subscribers as a minimum needed to keep going. We have not
achieved that goal; there were just over 3000 subscribers when the "great
expiration" hit at the end of September. At that point, about 1000
subscriptions ran out over the course of a few weeks. We have since clawed
our way back up to just under 3000 subscribers again. It is gratifying, to
say the least, that the renewal rate was so high.
3000 subscriptions is sufficient to keep us going for now, but we still
need to find a way to increase that number substantially. We are pondering
various ideas; stay tuned over the next few months as we figure out how to
proceed.
Meanwhile, thanks to the generosity of the folks at HP, LWN editor Jonathan
Corbet will be attending (and speaking at) Linux.Conf.Au
from January 14 to 18. We look forward to reporting from what
is, by all accounts, an outstanding conference. There is also a distinct
appeal to going to a place where the temperature is above freezing.
Finally, LWN.net will celebrate its sixth anniversary in about two weeks.
Six years ago, we could never have dreamed of the directions LWN would take
us - it was, after all, simply intended to be an attention-getter for a
Linux consulting and support company. It has been (and continues to be) a
great ride, however, and we expect to keep doing this for a long time.
Thanks to all of you for being such a great and supportive reader
community.
Comments (6 posted)
Page editor: Jonathan Corbet
Security
The Savannah Compromise - what really happened?
2003 hasn't been a banner year for computer security, and that includes
Linux. The CVS repository for the Linux kernel was
attacked (if clumsily),
several servers related to the Debian project were compromised, and the GNU
Project's
Savannah server was also
broken into recently. Since there has been little information published
about the nature of the Savannah compromise, we contacted Bradley Kuhn,
executive director of the Free Software Foundation for more information.
Kuhn described the Savannah compromise as "almost identical to what
happened to Debian." (A detailed account of the Debian compromise can be
found here.)
Kuhn said that he believes that the Savannah compromise and the Debian
attacks were related, and happened at about the same time. However, he said
that the project has not put a great deal of time and effort into analyzing
the attacks because it was more important to put Savannah back online and
to try to harden the system to see to it that a similar compromise doesn't
happen again. The hard drives from Savannah have been saved for future
reference, but the project is not putting its efforts into thoroughly
analyzing the attacks.
For the most part, Savannah has been restored
and changes have been made to try to ensure a similar attack will not be
possible. However, there are still some features that remain unavailable,
including Web CVS access and new projects are not being approved for the
time being. According to the Savannah website, new projects will probably
be accepted sometime before the end of January, 2004.
Has there been an attempt to insert a trojan into any of the code residing
on Savannah? Kuhn says that they've asked the owners of projects on
Savannah to go through and verify the code that is on Savannah to be sure
that it hasn't been trojaned. So far, there have been no reports of tainted
code. However, not all of the projects have reported their status. Kuhn
also noted that projects on the Savannah website will soon have an
indicator to report whether or not the developers have verified that they
have checked the integrity of their software.
We also asked if there was any sensitive information on Savannah that may
have been compromised. Kuhn said that the useful information on Savannah
mostly consists of the code for the various projects, and that the only
other information of interest would be developers' passwords. The passwords
on Savannah have been reset, of course, and the developers have been
encouraged to "investigate their own personal security."
For now, the GNU Project is not actively pursuing criminal prosecution of
the attacker or attackers. Kuhn says that the project is not "ethically
opposed" to prosecuting the intruder, but that with limited resources he'd
rather divert time and energy to restoring the services and trying to
harden systems to make future attacks more difficult and easier to contain.
To that end, the compromise may actually be a good thing in the long
run. Kuhn said that they have contacted the CVS maintainers and have
offered to pay for development of features that would allow GPG signing of
commits through CVS -- making it much more difficult for changes to be
inserted unnoticed into code held in a CVS repository. He said that they
have also contacted the GNU Arch maintainer about adding GPG
signing. Though it may take some time to develop, the addition of GPG
signing to commits would be a welcome feature.
Kuhn said that he expects that the future will bring more attacks on the
community, as free and open source software become more
prevalent. Opponents of the open development model will no doubt be using
these events as an illustration of the "dangers" of open source. Though the
recent intrusions have mostly been an inconvenience, it's important that
the community learn from these attacks, and redouble efforts to prevent
them in the future.
Comments (21 posted)
New vulnerabilities
cvs: possible root compromise
| Package(s): | cvs |
CVE #(s): | CAN-2003-0977
|
| Created: | December 29, 2003 |
Updated: | February 13, 2004 |
| Description: |
Stable CVS 1.11.11 has been released,
adding code to the CVS server to prevent it from continuing as root after a
user login, as an extra failsafe against a compromise of the CVSROOT/passwd
file. |
| Alerts: |
|
Comments (none posted)
fsp: buffer overflow and directory traversal
| Package(s): | fsp |
CVE #(s): | CAN-2003-1022
CAN-2004-0011
|
| Created: | January 7, 2004 |
Updated: | January 7, 2004 |
| Description: |
fsp suffers from both a buffer overflow vulnerability (which can be exploited to run arbitrary code) and a directory traversal problem. |
| Alerts: |
|
Comments (none posted)
jabber: denial of service
| Package(s): | jabber |
CVE #(s): | CAN-2004-0013
|
| Created: | January 7, 2004 |
Updated: | January 26, 2004 |
| Description: |
A vulnerability was discovered in jabber, an instant messaging server,
whereby a bug in the handling of SSL connections could cause the
server process to crash, resulting in a denial of service. |
| Alerts: |
|
Comments (1 posted)
kernel: two vulnerabilities in 2.4.23
| Package(s): | kernel |
CVE #(s): | CAN-2003-0984
CAN-2003-0985
|
| Created: | January 5, 2004 |
Updated: | January 19, 2004 |
| Description: |
Paul Starzetz discovered a flaw in bounds checking in mremap() in the Linux
kernel versions 2.4.23 and previous which may allow a local attacker to
gain root privileges. No exploit is currently available; however, it is
believed that this issue is exploitable (although not trivially.) The
Common Vulnerabilities and Exposures project has assigned the name
CAN-2003-0985 to this issue. There is also a minor information leak in the
real time clock (rtc) routines. The Common Vulnerabilities and Exposures
project has assigned the name CAN-2003-0984 to this issue. See this advisory for
more information. |
| Alerts: |
|
Comments (1 posted)
mpg321: format string vulnerability
| Package(s): | mpg321 |
CVE #(s): | CAN-2003-0969
|
| Created: | January 6, 2004 |
Updated: | March 28, 2005 |
| Description: |
A vulnerability was discovered in mpg321, a command-line mp3 player,
whereby user-supplied strings were passed to printf(3) unsafely. This
vulnerability could be exploited by a remote attacker to overwrite
memory, and possibly execute arbitrary code. In order for this
vulnerability to be exploited, mpg321 would need to play a malicious
mp3 file (including via HTTP streaming). |
| Alerts: |
|
Comments (none posted)
nd: buffer overflows
| Package(s): | nd |
CVE #(s): | CAN-2004-0014
|
| Created: | January 6, 2004 |
Updated: | January 7, 2004 |
| Description: |
Multiple vulnerabilities were discovered in nd, a command-line WebDAV
interface, whereby long strings received from the remote server could
overflow fixed-length buffers. This vulnerability could be exploited
by a remote attacker in control of a malicious WebDAV server to
execute arbitrary code if the server was accessed by a vulnerable
version of nd. |
| Alerts: |
|
Comments (none posted)
xsok: bad privilege handling
| Package(s): | xsok |
CVE #(s): | CAN-2003-0949
|
| Created: | January 7, 2004 |
Updated: | January 7, 2004 |
| Description: |
Steve Kemp discovered a problem in xsok, a single player strategy game
for X11, related to the Sokoban game, which leads a user to execute
arbitrary commands under the GID of games. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
apache: buffer overflows in mod_alias, mod_rewrite
| Package(s): | apache |
CVE #(s): | CAN-2003-0542
CAN-2003-0789
|
| Created: | October 28, 2003 |
Updated: | February 13, 2004 |
| Description: |
André Malo discovered
buffer overflows in the mod_alias and mod_rewrite modules of the Apache
webserver. These occurred if a regular expression with more than 9
capturing parenthesis was configured. To exploit this, an attacker would
need to be able to locally create a carefully crafted configuration file
(.htaccess or httpd.conf).
CAN-2003-0542
Another buffer overflow in Apache 2.0.47 and earlier in mod_cgid's
mishandling of CGI redirect paths could result in CGI output going to the
wrong client when a threaded MPM is used.
CAN-2003-0789. |
| Alerts: |
|
Comments (none posted)
apache2: Denial of Service vulnerability
| Package(s): | apache2 |
CVE #(s): | |
| Created: | September 29, 2003 |
Updated: | March 25, 2004 |
| Description: |
A problem was discovered in Apache2 where CGI scripts that write more than
4k to the standard error stream will hang the script's execution. This problem can lead to a
denial of service situation. See this bug
report for additional details. |
| Alerts: |
|
Comments (none posted)
bind: cache poisoning
| Package(s): | bind |
CVE #(s): | CAN-2003-0914
|
| Created: | November 26, 2003 |
Updated: | February 19, 2004 |
| Description: |
A cache poisoning vulnerability in BIND may be exploited causing a
temporary denial of service until the bad record expires from the cache. |
| Alerts: |
|
Comments (none posted)
CUPS: denial of service
| Package(s): | CUPS |
CVE #(s): | CAN-2003-0788
|
| Created: | November 3, 2003 |
Updated: | March 4, 2004 |
| Description: |
Paul Mitcheson reported a situation where the CUPS Internet Printing
Protocol (IPP) implementation in CUPS versions prior to 1.1.19 would get
into a busy loop. This could result in a denial of service. In order to
exploit this bug an attacker would need to have the ability to make a TCP
connection to the IPP port (by default 631).
|
| Alerts: |
|
Comments (none posted)
ethereal: protocol dissector and other vulnerabilities
| Package(s): | ethereal |
CVE #(s): | CAN-2003-0925
CAN-2003-0926
CAN-2003-0927
CAN-2003-1012
CAN-2003-1013
|
| Created: | December 18, 2003 |
Updated: | February 13, 2004 |
| Description: |
Serious issues have been discovered in two ethereal protocol dissectors.
Both vulnerabilities will make the Ethereal application crash. The Q.931
vulnerability also affects Tethereal. It is not known if either
vulnerability can be used to make Ethereal or Tethereal run arbitrary
code. (CAN-2003-1012 and CAN-2003-1013) |
| Alerts: |
|
Comments (none posted)
Filename disclosure vulnerability in fam
| Package(s): | fam |
CVE #(s): | CAN-2002-0875
|
| Created: | August 19, 2002 |
Updated: | January 5, 2005 |
| Description: |
"fam" (file alteration monitor) watches files and directories for changes and lets interested applications know when something happens. This package has a flaw in its group handling that blocks some legitimate operations while, at the same time, exposing the names of files that should otherwise be invisible. |
| Alerts: |
|
Comments (none posted)
fetchmail may crash on specially crafted message
| Package(s): | fetchmail |
CVE #(s): | CAN-2003-0792
|
| Created: | October 16, 2003 |
Updated: | April 8, 2004 |
| Description: |
A bug was discovered in fetchmail 6.2.4 where a specially crafted email
message can cause fetchmail to crash.
|
| Alerts: |
|
Comments (none posted)
fileutils/wu-ftpd: denial of service
| Package(s): | fileutils |
CVE #(s): | CAN-2003-0854
|
| Created: | October 22, 2003 |
Updated: | March 2, 2004 |
| Description: |
There is, it seems, an integer overflow vulnerability in "ls" which can be exploited via wu-ftpd to create a denial of service situation. See this advisory from Georgi Guninski for details. |
| Alerts: |
|
Comments (none posted)
glibc: DNS stub resolvers contain buffer overflow vulnerability
| Package(s): | glibc |
CVE #(s): | CAN-2002-1146
|
| Created: | November 7, 2002 |
Updated: | February 5, 2004 |
| Description: |
DNS stub resolvers from multiple vendors contain a buffer overflow
vulnerability. The impact of this vulnerability appears to be limited to
denial of service. (See CERT Vulnerability Note
VU#738331)
The BIND 4 and BIND 8.2.x stub resolver libraries, and other libraries such
as glibc 2.2.5 and earlier, libc, and libresolv, uses the maximum buffer
size instead of the actual size when processing a DNS response, which
causes the stub resolvers to read past the actual boundary ("read buffer
overflow"), allowing remote attackers to cause a denial of service
(crash).
|
| Alerts: |
|
Comments (none posted)
GnuPG: ElGamal signing keys compromised
| Package(s): | gnupg |
CVE #(s): | CAN-2003-0971
|
| Created: | November 28, 2003 |
Updated: | March 3, 2004 |
| Description: |
A severe vulnerability was discovered in GnuPG by Phong Nguyen relating to
ElGamal sign+encrypt keys. This
email message from Werner Koch contains more information. "Phong
Nguyen identified a severe bug in the way GnuPG creates and uses ElGamal
keys for signing. This is a significant security failure which can lead to
a compromise of almost all ElGamal keys used for signing. Note that this
is a real world vulnerability which will reveal your private key within a
few seconds." |
| Alerts: |
|
Comments (3 posted)
gtkhtml: malformed messages cause crash
| Package(s): | gtkhtml |
CVE #(s): | CAN-2003-0133
CAN-2003-0541
|
| Created: | April 14, 2003 |
Updated: | April 18, 2005 |
| Description: |
GtkHTML is the HTML rendering widget used by the Evolution mail reader.
GtkHTML supplied with versions of Evolution prior to 1.2.4 contain a bug
when handling HTML messages. Alan Cox discovered that certain malformed
messages could cause the Evolution mail component to crash. |
| Alerts: |
|
Comments (none posted)
iproute: local denial of service
| Package(s): | iproute net-tools |
CVE #(s): | CAN-2003-0856
|
| Created: | November 25, 2003 |
Updated: | December 14, 2004 |
| Description: |
The iproute utility is susceptible to spoofed netlink messages sent by local users, with the result that denial of service attacks are possible. |
| Alerts: |
|
Comments (none posted)
kernel: local root exploit in 2.4.22
| Package(s): | kernel |
CVE #(s): | CAN-2003-0961
|
| Created: | December 1, 2003 |
Updated: | April 5, 2004 |
| Description: |
A vulnerability was discovered in the Linux kernel versions 2.4.22 and
previous. A flaw in bounds checking in the do_brk() function can allow a
local attacker to gain root privileges. This vulnerability is known to be
exploitable.
The 2.4.23 kernel contains the fix. For more details on how this vulnerability works, see this LWN article. |
| Alerts: |
|
Comments (1 posted)
kernel-utils: setuid vulnerability
| Package(s): | kernel-utils |
CVE #(s): | CAN-2003-0019
|
| Created: | February 7, 2003 |
Updated: | January 21, 2005 |
| Description: |
The kernel-utils package contains several utilities that can be used to
control the kernel or machine hardware. In Red Hat Linux 8.0 this package
contains user mode linux (UML) utilities.
The uml_net utility in kernel-utils packages with Red Hat Linux 8.0 was
incorrectly shipped setuid root. This could allow local users to control
certain network interfaces, add and remove arp entries and routes, and put
interfaces in and out of promiscuous mode.
All users of the kernel-utils package should update to these packages that
contain a version of uml_net that is not setuid root.
Alternatively, as a work-around to this vulnerability issue the following
command as root:
chmod -s /usr/bin/uml_net |
| Alerts: |
|
Comments (none posted)
lftp buffer overflows
| Package(s): | lftp |
CVE #(s): | CAN-2003-0963
|
| Created: | December 15, 2003 |
Updated: | February 13, 2004 |
| Description: |
According to this advisory versions of lftp
prior to 2.6.10 are vulnerable to two exploitable buffer overflow
problems. Both occur when you connect to a web server with lftp using HTTP
or HTTPS, and then use lftp's "ls" or "rels" commands on specially prepared
directories on the web server. |
| Alerts: |
|
Comments (none posted)
libnids: remotely exploitable buffer overflow
| Package(s): | libnids |
CVE #(s): | CAN-2003-0850
|
| Created: | October 29, 2003 |
Updated: | January 6, 2004 |
| Description: |
libnids (a NIDS plugin which emulates the Linux 2.0 IP stack) contains a buffer overflow vulnerability which can be exploited remotely. Version 1.18 fixes the problem. |
| Alerts: |
|
Comments (none posted)
libpng, libpng3: buffer overflow
| Package(s): | libpng, libpng3 |
CVE #(s): | CAN-2002-1363
|
| Created: | December 19, 2002 |
Updated: | July 14, 2004 |
| Description: |
Glenn Randers-Pehrson discovered a problem in connection with 16-bit
samples from libpng, an interface for reading and writing PNG
(Portable Network Graphics) format files. The starting offsets for
the loops are calculated incorrectly which causes a buffer overrun
beyond the beginning of the row buffer. |
| Alerts: |
|
Comments (none posted)
mikmod: buffer overflow
| Package(s): | mikmod |
CVE #(s): | CAN-2003-0427
|
| Created: | June 16, 2003 |
Updated: | June 16, 2005 |
| Description: |
Ingo Saitz discovered a bug in mikmod whereby a long filename inside
an archive file can overflow a buffer when the archive is being read
by mikmod. |
| Alerts: |
|
Comments (none posted)
mpg123: heap overflow
| Package(s): | mpg123 |
CVE #(s): | CAN-2003-0865
|
| Created: | November 12, 2003 |
Updated: | February 19, 2004 |
| Description: |
Versions of mpg123 through 0.59s contain a heap overflow which may be exploited remotely (by a hostile server). See this advisory for details. |
| Alerts: |
|
Comments (none posted)
mplayer: remotely exploitable buffer overflow vulnerability
| Package(s): | mplayer |
CVE #(s): | CAN-2003-0835
|
| Created: | September 29, 2003 |
Updated: | April 6, 2004 |
| Description: |
A remotely exploitable buffer overflow vulnerability was found in
MPlayer. A malicious host can craft a harmful ASX header, and trick MPlayer
into executing arbitrary code upon parsing that header. Read the full advisory
for details. |
| Alerts: |
|
Comments (none posted)
Nessus NASL scripting engine security issues
| Package(s): | nessus |
CVE #(s): | |
| Created: | May 27, 2003 |
Updated: | August 12, 2004 |
| Description: |
Some some vulnerabilities exsist in the Nessus NASL scripting engine. To
exploit these flaws, an attacker would need to have a valid Nessus account
as well as the ability to upload arbitrary Nessus plugins in the Nessus
server (this option is disabled by default) or he/she would need to trick a
user somehow into running a specially crafted nasl script. Read the full
advisory for additional information. |
| Alerts: |
|
Comments (none posted)
Net-SNMP: security bugs in versions before 5.0.9
| Package(s): | Net-SNMP |
CVE #(s): | CAN-2003-0935
|
| Created: | December 2, 2003 |
Updated: | February 13, 2004 |
| Description: |
The Net-SNMP project includes various Simple Network Management Protocol
(SNMP) tools. A security issue in Net-SNMP versions before 5.0.9 could
allow an existing user/community to gain access to data in MIB objects that
were explicitly excluded from their view.
Version 5.0.9 of Net-SNMP is not vulnerable to this issue. In addition,
Net-SNMP 5.0.9 fixes a number of other minor bugs. |
| Alerts: |
|
Comments (none posted)
nfs-utils xlog() off-by-one bug
| Package(s): | nfs-utils |
CVE #(s): | CAN-2003-0252
|
| Created: | July 14, 2003 |
Updated: | March 8, 2004 |
| Description: |
Linux NFS utils package contains remotely exploitable off-by-one bug.
A local or remote attacker could exploit this vulnerability by sending
specially crafted request to rpc.mountd daemon. See this BugTraq post for more details. |
| Alerts: |
|
Comments (none posted)
openssh: timing attack leads to information disclosure
| Package(s): | openssh |
CVE #(s): | CAN-2003-0190
|
| Created: | May 2, 2003 |
Updated: | November 30, 2004 |
| Description: |
From the advisory:
"During a pen-test we stumbled across a nasty bug in OpenSSH-portable
with PAM support enabled (via the --with-pam configure script switch). This
bug allows a remote attacker to identify valid users on vulnerable systems,
through a simple timing attack. The vulnerability is easy to exploit and
may have high severity, if combined with poor password policies and other
security problems that allow local privilege escalation." |
| Alerts: |
|
Comments (1 posted)
postfix: denial of service vulnerabilities
| Package(s): | postfix |
CVE #(s): | CAN-2003-0468
CAN-2003-0540
|
| Created: | August 5, 2003 |
Updated: | May 27, 2004 |
| Description: |
The postfix MTA, versions through 1.1.12 (but not 2.0) is subject to two remotely exploitable denial of service vulnerabilities; see this advisory from Michal Zalewski for details. |
| Alerts: |
|
Comments (none posted)
proftpd: remote root shell
| Package(s): | proftpd |
CVE #(s): | CAN-2003-0831
|
| Created: | September 24, 2003 |
Updated: | January 2, 2004 |
| Description: |
The ASCII translation mechanism in ProFTPD 1.2.8 contains a vulnerability which will provide a remote attacker with a root shell - if the attacker is able to download a specially-crafted file. See this ISS advisory for more information. |
| Alerts: |
|
Comments (2 posted)
rsync - remotely exploitable heap overflow
| Package(s): | rsync |
CVE #(s): | CAN-2003-0962
|
| Created: | December 4, 2003 |
Updated: | March 3, 2004 |
| Description: |
An advisory has gone out warning of a
remotely exploitable heap overflow vulnerability in rsync versions 2.5.6
and prior. If you are running an rsync server, you will want to apply a
distributor patch or upgrade to 2.5.7 in the near future. |
| Alerts: |
|
Comments (none posted)
Multiple-use vulnerability in Safe.pm
| Package(s): | Safe.pm |
CVE #(s): | CAN-2002-1323
|
| Created: | October 9, 2002 |
Updated: | February 20, 2004 |
| Description: |
usePerl has a
description of a vulnerability in the Safe.pm Perl module. It seems
that if a Safe compartment is used more than once, it ceases to be safe.
The problem is fixed in Safe 2.08. |
| Alerts: |
|
Comments (none posted)
sane-backends: several vulnerabilities
| Package(s): | sane-backends |
CVE #(s): | CAN-2003-0773
CAN-2003-0774
CAN-2003-0775
CAN-2003-0776
CAN-2003-0777
CAN-2003-0778
|
| Created: | September 11, 2003 |
Updated: | February 20, 2004 |
| Description: |
Alexander Hvostov, Julien Blache and Aurelien Jarno discovered several
security-related problems in the sane-backends package, which contains
an API library for scanners including a scanning daemon (in the
package libsane) that can be remotely exploited. These problems allow
a remote attacker to cause a segfault fault and/or consume arbitrary
amounts of memory. The attack is successful, even if the attacker's
computer isn't listed in saned.conf.
You are only vulnerable if you actually run saned e.g. in xinetd or
inetd. If the entries in the configuration file of xinetd or inetd
respectively are commented out or do not exist, you are safe.
Try "telnet localhost 6566" on the server that may run saned. If you
get "connection refused" saned is not running and you are safe.
The Common Vulnerabilities and Exposures project identifies the
following problems:
-
CAN-2003-0773: saned checks the identity (IP address) of the remote
host only after the first communication took place (SANE_NET_INIT). So
everyone can send that RPC, even if the remote host is not allowed to
scan (not listed in saned.conf).
-
CAN-2003-0774: saned lacks error checking nearly everywhere in the
code. So connection drops are detected very late. If the drop of the
connection isn't detected, the access to the internal wire buffer leaves
the limits of the allocated memory. So random memory "after" the wire
buffer is read which will be followed by a segmentation fault.
-
CAN-2003-0775: If saned expects strings, it mallocs the memory
necessary to store the complete string after it receives the size of the
string. If the connection was dropped before transmitting the size,
malloc will reserve an arbitrary size of memory. Depending on that size
and the amount of memory available either malloc fails (->saned quits
nicely) or a huge amount of memory is allocated. Swapping and OOM
measures may occur depending on the kernel.
-
CAN-2003-0776: saned doesn't check the validity of the RPC numbers
it gets before getting the parameters.
-
CAN-2003-0777: If debug messages are enabled and a connection is
dropped, non-null-terminated strings may be printed and segmentation
faults may occur.
-
CAN-2003-0778: It's possible to allocate an arbitrary amount of
memory on the server running saned even if the connection isn't dropped.
At the moment this can not easily be fixed according to the author.
Better limit the total amount of memory saned may use (ulimit).
|
| Alerts: |
|
Comments (none posted)
screen: privilege escalation
| Package(s): | screen |
CVE #(s): | CAN-2003-0972
|
| Created: | November 28, 2003 |
Updated: | March 3, 2004 |
| Description: |
According to
this advisory a buffer overflow in GNU screen allows privilege
escalation for local users. Usually screen is installed either setgid-utmp
or setuid-root.
It also has some potential for remote attacks or getting control of another
user's screen. The problem is that you have to transfer around 2-3 gigabytes
of data to user's screen to exploit this vulnerability. 4.0.1, 3.9.15 and
older versions are vulnerable. |
| Alerts: |
|
Comments (none posted)
File overwrite vulnerability in tar and unzip
| Package(s): | tar unzip |
CVE #(s): | CAN-2001-1267
CAN-2001-1268
CAN-2001-1269
CAN-2002-0399
|
| Created: | October 1, 2002 |
Updated: | April 9, 2006 |
| Description: |
The tar utility does not properly filter file names containing
"../", meaning that a hostile archive can, if unpacked by an
unsuspecting user, overwrite any file that is writable by that user. GNU
tar versions 1.13.19 and earlier are vulnerable; unzip through version 5.42
has the same vulnerability. |
| Alerts: |
|
Comments (1 posted)
Multiple vendor telnetd vulnerability
| Package(s): | telnet Telnet netkit-telnet-ssl kerberos telnetd netkit-telnet nkitb/nkitserv/telnetd krb5 |
CVE #(s): | |
| Created: | May 20, 2002 |
Updated: | October 5, 2004 |
| Description: |
This vulnerability,
originally thought to be confined to BSD-derived systems, was first covered
in the July 26th Security
Summary. It is now known that Linux telnet daemons are vulnerable as
well.
|
| Alerts: |
|
Comments (none posted)
vim - modeline vulnerability
| Package(s): | vim |
CVE #(s): | CAN-2002-1377
|
| Created: | January 16, 2003 |
Updated: | February 10, 2004 |
| Description: |
VIM allows a user to set the modeline differently for each edited text file
by placing special comments in the files. Georgi Guninski found that these
comments can be carefully crafted in order to call external programs. This
could allow an attacker to create a text file such that when it is opened
arbitrary commands are executed. |
| Alerts: |
|
Comments (4 posted)
zebra: denial of service vulnerability
| Package(s): | zebra |
CVE #(s): | CAN-2003-0795
CAN-2003-0858
|
| Created: | November 13, 2003 |
Updated: | January 7, 2004 |
| Description: |
Zebra an open source implementation of TCP/IP routing software.
Jonny Robertson reported that Zebra can be remotely crashed if a Zebra
password has been enabled and a remote attacker can connect to the Zebra
telnet management port. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2003-0795 to this issue.
Herbert Xu reported that Zebra can accept spoofed messages sent on the
kernel netlink interface by other users on the local machine. This could
lead to a local denial of service attack. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2003-0858 to
this issue. |
| Alerts: |
|
Comments (none posted)
Page editor: Jonathan Corbet
Kernel development
Release status
Kernel release status
The current 2.6 kernel is 2.6.0. Linus released the second 2.6.1
release candidate on January 6 without an announcement; the
(relatively small) list of changes can be seen in
the long-format changelog. Previously,
2.6.1-rc1 (
announcement,
changelog) had been released on
December 31. It included quite a few fixes, along with a couple of
internal API changes (see below), the restoration of the old