The Grumpy Editor's guide to mail clients: introduction
Your editor's desktop system is currently running Fedora Core 2,
mostly as a result of that distribution's combination of near-bleeding-edge
software and the x86_64 architecture. There is much that is good about
Fedora, but your editor was more than disconcerted to find out
that nmh, the current form of the MH mail client, was no longer included.
This is not an isolated point of view; a
threat
to write a Grumpy Editor column on this topic still yields an occasional
message of support. This is, indeed, an ideal topic for such a column; the
MH mailer, which was first put together in the late 1970's, still has
lessons to offer the current crop of mail clients.
Your editor will have to request some patience, however. A proper review
of mail clients will take more than one column, along with a significant
amount of time. Those wanting an instant review of bleeding-edge graphical
mailers will have to wait a while; this column, instead, will attempt to
provide an introduction to the topic by looking at the standards set by MH.
MH was, at the outset, different from any other mail client out there, and
it remains different. Mail clients tend to be classic examples of monolithic
design; everything (one hopes) that a user might want to do with electronic
mail is built in to one single, large application. The designers of MH
concluded that this design did not fit well with the Unix way of doing
things, which is to have a relatively large number of small programs, each
of which does one thing well. As a consequence, MH is not one program, but
many: the current nmh distribution contains 39 separate utilities.
When dealing with MH at this level, the user is never "in" the mail system;
instead, all commands are typed directly to the regular shell. The
inc command
brings in new mail; scan lists a folder; show,
next, and prev display individual messages; repl
generates a reply; rmm, refile, and others dispose of
messages; and so on. There is a command (pick) which can perform
complicated searches through folders. All of these commands (and many not
mentioned) manipulate a global state, giving the full set the feel of a
single, integrated application.
MH folders, incidentally, are also unique: they are simply directories
containing each message in a separate file. A number of modern mailers
support MH folders, though usually not as the preferred format.
The result of this organization is that it is possible to build software on
top of the MH primitives with great ease. Over the years, developers have
created numerous interfaces for MH, including xmh (an old graphical
interface still shipped with XFree86), exmh (a Tk-based graphical client),
and MH-E (an emacs-based
interface favored by your editor). The scriptability of the MH primitives
also makes it easy to integrate the mail client into any other
task-oriented software that the user may need to run.
The availability of multiple interfaces to the same mail system is nicer
than one might think. A fancy, graphical interface may be useful when one
is in the office and near to the mail system. When one is stuck behind a
slow network connection (a GPRS link from a nearby mountain, say), the
command line interface may be the only way to work through a batch of mail
quickly and with minimum pain. There is great value in not being locked
into a single mode of interaction with the mail system.
Unfortunately, MH is showing its age in a big way. The nmh effort appears to have stalled
for lack of developers; it shows no commits to its repository since 2003;
the 1.0.4 release - the latest available - came out in April, 2000. A 1.1
release candidate was posted in January, but nothing has happened since
then. There
is support for MIME in nmh, but that support is awkward at best. The exmh
front end does MIME, but there has not been an exmh release in over a
year; it, too, is getting harder to find in distributions. MH works with
POP, but there is no IMAP implementation in sight. In general, MH is old,
unmaintained, and fading from the scene.
This is a shame, because MH got some things right decades ago that modern
mail client developers still seem to miss. Your editor does not want to
funnel his email into a single-interface black box. He wants to be able to
manipulate mail from his desktop, over a modem link, or running through
mindterm on a Windows "email garden" system in a remote place.
It should be possible
to do anything with email - even things that the developer of the mail
client might not have thought of. It must be possible to make connections
between the mail client and the LWN site code. It should be possible to
manipulate messages and folders with shell scripts and programs without
great pain. The client should be a powerful tool for working with
electronic mail, but it should be just the beginning point, rather than the
final destination.
Your editor is now shopping for an email client which can replace MH. This
process could be a long one; understanding a mail client well enough to
write about it takes a significant amount of effort. The process may also
require delving into other parts of the larger email system, such as IMAP
servers. Watch for a series of upcoming articles over the (northern
hemisphere) summer as this journey unfolds.
As a down payment, here is a quick look at the MH-E interface. Your editor
has used MH-E for years; it does a nice job of combining the power of MH
with an efficient keyboard interface and the usual benefits of integration
with the editor itself. Your editor has long assumed that MH-E has
suffered the same fate as MH; the version shipped with the current
GNU emacs distribution dates from 2000. This version of MH-E has many
shortcomings; it does not even deal with simple things like mail in the
quoted-printable encoding correctly.
![[MH-E screenshot]](/images/ns/grumpy/hot-nude-geek-sm.png)
So it was interesting to find out that that MH-E hackers have, in fact,
been quite busy recently. Version 7.4.3, currently available from the MH-E site, includes a number of
new features. It performs threading, has proper MIME support (see
screenshot, right), indexed searching, and more. It uses the capabilities
of modern versions of emacs to display images and such within the editor
itself. There is also a general interface to spam filtering systems,
allowing the user to easily train the bayesian filter of his or her
choice.
It is, in general, a vastly superior implementation of MH-E, and the upgrade is
easy; if you are an MH-E user, you probably want to look at the current
version.
On the down side, enough commands have been changed to drive a long-time
MH-E user nuts for a while, and the documentation is, um, missing. The
default colors show a distinct lack of restraint or concern for human
factors. It also
has adopted the gnus habit of replacing smileys and such with its own
built-in icons - behavior which is amusing for about two messages before
you realize you'd rather just see what the other person wrote.
Fortunately, this behavior is easily turned off with a configuration
option.
The new MH-E is apparently slated for inclusion in emacs 21.4. It is good
to see that significant work is going into this mail interface; MH-E is too
good to allow to slip into obscurity and decay. The fact remains, however,
that MH-E is built on a foundation which has not seen any significant
maintenance in years.
(For more information on the history and philosophy behind MH, see the
classic (if quaintly titled) paper "MH: How to process 200 messages a day
and still get some real work done," available in PostScript format).
Comments (71 posted)
The 64-bit question
It was probably too much to hope that all Linux vendors would take the
same approach to their distributions for AMD's 64-bit x86 chips and
Intel's forthcoming 64-bit x86 chips, or x86_64. While the major
commercial vendors (SUSE, Red Hat and Mandrake, to name a few) are
shipping mixed distributions for x86_64, the recently-announced Debian
x86_64 port is a pure
64-bit distribution without 32-bit libraries.
A pure 64-bit distribution has the advantage of being simpler, and of not
having to worry about multiple versions on libraries and such.
Thus, while other distributions have relegated the 64-bit libraries to an
alternate location, such as /usr/lib64, the Debian project
ships with 64-bit libraries in /usr/lib and avoids the
problem of rewriting package creation rules to install libraries in
/usr/lib64 or a similar situation. However, this results in
a system that is unable to run 32-bit x86 binaries.
The original plan for Debian's x86_64 port was to be similar to sparc64,
where the default is 32-bit applications and libraries. However, the
tide turned in February, and multiarch support was put on the back
burner. As Goswin von Brederlow explains:
There was an attempt at doing a mixed port but the resistance by the
dpkg developers and the community in general was too big to get it under
way, esspecially with the sarge release looming over our heads. A full
mixed port means changing every single library package and affects
probably all packages. That's nothing one wants to do before sarge.
So instead of going full 32/64 bit mixed mode amd64 in one big step
pure64 was started to get 64 bit support fully available with minimum
impact to sarge. Merging is multiarch support for mixed 32/64 bit is now
step 2 planed for after sarge at the earliest.
This may not end up being a big problem, even for those users who need
to run 32-bit x86 applications.
As John Goerzen points
out, it is possible to run 32-bit binaries in a chrooted
environment:
The only reason I can see for even bothering to support 32-bit
applications at all is for binary-only proprietary software. And that
is not such a concern; it takes all of about 10 minutes to set up a
32-bit chroot with debootstrap to run those things in.
Some have voiced
concerns about Debian being incompatible with other x86_64
distributions. Since LSB-compatibility should be the main concern, we
wondered whether Debian, or any other Linux distributions, were
compatible with the LSB specification for x86_64 chips. Stuart Anderson,
lead developer of the LSB written specification, told LWN that none of
the distributions currently meet the LSB specification, but for obvious
reasons:
That's because there has not yet been an official release of the LSB for
that architecture. There is a draft, and it will get released in the
very near future, but because it hasn't been, distros have not yet had a
chance to certify.
Anderson did say that a distribution can be LSB-compliant, without
running 32-bit binaries, since the specification covers only x86_64. He also said that they are working on a "multi-arch" specification, "but it's not really far enough along to say anything specific."
In general, I think a 64 bit distro should be able to support a 32 bit
runtime in parallel. It just does so as supporting two specs, and not a
single one that mandated both 32 & 64.
No doubt, it will be some time before x86_64 support is uniform across
all the various Linux distributions. The hardware is not yet in wide
enough use to truly force distributions to standardize, and it's
entirely possible that the 32-bit problem will disappear as x86_64
hardware becomes commonplace.
Comments (13 posted)
Time for a SCO update
It has been a busy week in the SCO universe; time for an update.
The company released its second quarter results on June 10; those who are
interested can see the
press release or, for far more detail, the
10-Q filing. The results were as bad as expected; actually, they were
even worse. The company lost $15 million on $10 million in
revenue. The SCOsource program brought in all of $11,000 over the
quarter. SCO management says things will get better soon, of course.
About one year ago, SCO acquired a web services company called Vultus; this
acquisition, somehow, involved the transfer of some 300,000 shares of
SCO stock to the Canopy Group. Quite a few questions were raised at the
time; there did not seem to be any sort of legitimate business reason for
SCO to make this acquisition; it seemed, instead, to be a way of shifting
money over to Canopy. The questions have come back; this quarter's 10-Q
filing includes a $2.4 million writeoff acknowledging that Vultus is,
in fact, worthless.
Also found in the 10-Q is the fact that SCO has spent $2.4 million of
its scarce cash buying back its own stock. These purchases appear to have
done little to prop up the company's stock price, however.
The most significant news of the week was almost certainly the
rulings in
the Novell case. Three separate motions were decided:
- Novell had tried to get the case dismissed on the grounds that SCO did
not show that Novell's copyright claims are false. Judge Kimball
denied this motion for now, though he noted that the question of
falsity remains open.
- Novell also moved for dismissal on the grounds that SCO did not plead
any specific damages. This motion was granted; as of this writing,
SCO's suit against Novell is officially dismissed. SCO, however, got 30
days to refile the case with the required pleadings; SCO claims it
will do so.
- SCO had moved to get the trial shifted back to Utah state court; this
motion was denied.
The most important ruling by far was the one keeping the case in Federal court.
SCO was hoping for a quick contract case where it could talk about the
"intent" of the agreement that transferred the Novell license
administration business to (old) SCO. State courts cannot rule on the
validity of actual copyright transfers, which are a Federal issue. Judge
Kimball has decided, however, that the existence (or lack thereof) of a
copyright transfer is a crucial part of this case. If no copyrights were
transferred to old SCO, then the current SCO Group has no basis for a
"slander of title" claim. And the Judge has his doubts on whether that
transfer happened:
The Amendment also contains no transfer language in the form of
'seller hereby conveys to buyer.' Given the similarly ambiguous
language in the APA with respect to the transfer of assets --
seller 'will' sell, convey, assign, and buyer 'will' purchase and
acquire -- it is questionable on the face of the documents whether
there was any intention to transfer the copyrights as of the date
the amendment was executed. Moreover, the use of the term
'required' in Amendment No. 2 without any accompanying list or
definition of which copyrights would be required for SCO to
exercise its rights in the technology is troublesome given the
number of copyrighted works involved in the transaction. There is
enough ambiguity in the language of Amendment No. 2 that, at this
point in the litigation, it is questionable whether Amendment No. 2
was meant to convey the required copyrights or whether the parties
contemplated a separate writing to actually transfer the copyrights
after the 'required' copyrights were identified.
In state court, SCO would not have had to face this particular line in
inquiry. In Federal court, instead, the company will have to start by
proving that it does, indeed, own the copyrights it has been claiming;
furthermore, this proof will have to be made to a clearly skeptical judge.
One might well think that this whole issue is irrelevant. Beyond the small
bit of Unix code leaked into the kernel by SGI (and long since removed),
there has been no evidence that any proprietary Unix code has found its way
into Linux. Even if SCO wins its case against Novell, it loses against
Linux. But the fact that its copyright ownership claims are being
challenged in Federal court may yet be the factor that brings the whole
enterprise crashing down. Sales of "Linux licenses" will be even harder
than before, and, if the judge rules that SCO does not own the copyrights,
the rest of SCO's legal offensives will simply collapse.
Judge Kimball also issued some
rulings in the IBM case. SCO's motion to bifurcate the case (an
attempt to split IBM's patent counterclaims into a separate trial) was
denied by the judge. This motion was denied without prejudice, so it could
come back at some future time. SCO's motion to delay the case was partly
granted, however; the actual trial, should it ever happen, will be in
November, 2005. The judge has made it clear that he is not interested in
any further delays after this one.
In the AutoZone case, SCO has filed a
memorandum opposing AutoZone's motions to put the case on hold, or, at
least, to move it to Tennessee. Says SCO:
Granting a stay under the procedural posture of the cases that
AutoZone has relied upon would amount to giving AutoZone free
license to continue to infringe upon SCO's copyrights for the
foreseeable future, while preventing SCO from even obtaining
discovery concerning the breadth of such copyright infringements
and the damages such infringements may have caused.
In other words, poor SCO would not be able to go fishing through AutoZone's
files looking for actual evidence.
Finally, the SCO Group is, for the first time in a while, making a big show
of wanting to be a software company. One announcement
was for UnixWare 7.1.4, which includes a number of bleeding-edge features:
support for disks larger than 128GB, pluggable authentication modules,
MySQL, PostgreSQL, Apache 2.0.49, Tomcat, Perl, PHP, Samba 3.0, Sendmail,
and more. It seems that free software isn't such a bad thing after all.
SCO has also announced
an embedded offering, "SCOoffice server," and "Legend," an upcoming version
of OpenServer with support for "64-bit advanced computing." All told, it
looks like the company is truly putting some effort into its (still
proprietary and obsolete) Unix offerings.
One might well wonder why SCO is doing that. The company had been told by
BayStar that its litigation was its only worthwhile effort; why drain money
from the lawyers to prop up its software offerings? One clue was to be
found in the conference
call that accompanied the second-quarter earnings report. While SCO
claims to be staying the course (and doing great), the whole tone of the
conference was subdued. Those who sat through the "Chris&Darl shows"
of last year note that, now, the swagger is gone (and Chris Sontag,
SCOsource manager, has been just about invisible recently). SCO's
management may well have gotten past the denial and figured out that it has
lost. If so, they might just be thinking about trying to run a software
company once the litigation storm has run its course. That might even work
as a "plan B," but only if SCO can overcome a couple of small
obstacles: having any sort of company left after those it has attacked
are done with it, and offering software that people actually want to
buy.
Comments (7 posted)
Page editor: Jonathan Corbet
Security
The Metasploit Framework
Version v2.1 of the Metasploit Framework has been
released. Metasploit looks like a script
kiddie's dream tool; it is a convenient packaging of some two dozen tools
for exploiting known vulnerabilities. A would-be attacker need only choose
the weapon of choice from a menu, and turn it loose.
In fact, it's better than that. Combined with the exploit engine is the
"payload generator"; there is also an online version
available. Simply pick the sort of behaviour you would like, set the relevant
parameters (e.g. which port to listen to), and the corresponding code pops
out the other end. Fit the payload onto your chosen exploit, and your
weapon is armed and ready.
Metasploit does not bring any new capabilities to the cracker's toolbox,
but it does make life easy for those who are unable to craft their own
exploits. It can also serve as a useful instructional and testing tool for
those of us who are charged with keeping systems secure. Metasploit can
quickly tell you if a target system is vulnerable to a given exploit, and
it shows what a breakin looks like from the outside. The attackers have
it; defenders might as well get a copy and see how it works. See the Metasploit Project page for more
information.
Comments (1 posted)
New vulnerabilities
Apache mod_proxy: denial of service
| Package(s): | apache |
CVE #(s): | CAN-2004-0492
|
| Created: | June 11, 2004 |
Updated: | October 14, 2004 |
| Description: |
A buffer overflow vulnerability in the apache mod_proxy module
can be exploited to create a denial of service. |
| Alerts: |
|
Comments (none posted)
chora: remote command execution
| Package(s): | chora |
CVE #(s): | |
| Created: | June 15, 2004 |
Updated: | June 15, 2004 |
| Description: |
Chora, a CVS/SVN repository viewer written by the HORDE project, has a vulnerability which can allow a remote attacker to inject shell code. Uploading and running of malicious binaries is also possible. Upgrading to version 1.2.2 fixes the problem. |
| Alerts: |
|
Comments (none posted)
Horde-IMP: improper input validation
| Package(s): | Horde-IMP |
CVE #(s): | |
| Created: | June 16, 2004 |
Updated: | August 10, 2004 |
| Description: |
An input validation error exists in Horde-IMP through version 3.2.4; a specially crafted message could be used to run scripts in the context of the target's browser. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CAN-2004-0554
|
| Created: | June 15, 2004 |
Updated: | July 5, 2004 |
| Description: |
2.4 and 2.6 kernels running on the i386 and x86_64 kernels have a vulnerability which can allow a local attacker to lock up the system. See this LWN article for a description of the problem.
Many of the updates for this problem also fix various potential driver vulnerabilities found while instrumenting the code for automated auditing. |
| Alerts: |
|
Comments (none posted)
Subversion: Remote heap overflow
| Package(s): | subversion |
CVE #(s): | CAN-2004-0413
|
| Created: | June 11, 2004 |
Updated: | March 7, 2005 |
| Description: |
Subversion has a remote Denial of Service vulnerability
that may allow a server that runs svnserve to execute
arbitrary code. See this advisory for more information. |
| Alerts: |
|
Comments (none posted)
webmin: denial of service
| Package(s): | webmin |
CVE #(s): | CAN-2004-0582
CAN-2004-0583
|
| Created: | June 16, 2004 |
Updated: | July 28, 2004 |
| Description: |
Versions of webmin prior to 1.150 suffer from denial of service and information disclosure vulnerabilities. See advisories for the disclosure and lockout problems for more information. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
apache2: stack-based buffer overflow in ssl_util.c
| Package(s): | apache2 |
CVE #(s): | CAN-2004-0488
|
| Created: | June 1, 2004 |
Updated: | October 14, 2004 |
| Description: |
A stack-based buffer overflow exists in the ssl_util_uuencode_binary
function in ssl_util.c in Apache. When mod_ssl is configured to trust the
issuing CA, a remote attacker may be able to execute arbitrary code via a
client certificate with a long subject DN. |
| Alerts: |
|
Comments (none posted)
cvs: heap overflow
| Package(s): | cvs |
CVE #(s): | CAN-2004-0396
|
| Created: | May 19, 2004 |
Updated: | June 11, 2004 |
| Description: |
CVS (through version 1.11.15 or 1.12.7) contains a remotely exploitable heap overflow vulnerability; see this advisory from Stefan Esser for details. If you are running cvs with the "pserver" protocol, a quick upgrade is recommended (dropping pserver is also a very good idea for security-conscious sites). |
| Alerts: |
|
Comments (none posted)
cvs: new vulnerabilities
| Package(s): | cvs |
CVE #(s): | CAN-2004-0414
CAN-2004-0416
CAN-2004-0417
CAN-2004-0418
|
| Created: | June 9, 2004 |
Updated: | June 15, 2004 |
| Description: |
Several new vulnerabilities have been found in CVS; these include a null-termination error, a double-free vulnerability, a format-string vulnerability, and a few others; see this advisory for the details. Some of these vulnerabilities are remotely exploitable; updating soon would be a good idea. |
| Alerts: |
|
Comments (none posted)
ethereal: more protocol dissector issues
| Package(s): | ethereal |
CVE #(s): | |
| Created: | June 3, 2004 |
Updated: | June 11, 2004 |
| Description: |
The 0.10.3 version may crash when you select a SIP packet. See this
post to the ethereal-users mailing list for details. |
| Alerts: |
|
Comments (1 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)
flim: insecure file creation
| Package(s): | flim |
CVE #(s): | CAN-2004-0422
|
| Created: | May 5, 2004 |
Updated: | December 16, 2004 |
| Description: |
The emacs "flim" mode creates temporary files in an insecure fashion, possibly allowing a local attacker to overwrite files. |
| Alerts: |
|
Comments (none posted)
gallery: unauthenticated access
| Package(s): | gallery |
CVE #(s): | |
| Created: | June 2, 2004 |
Updated: | June 15, 2004 |
| Description: |
The "gallery" photo album has a vulnerability which can allow access to the administrative account without authentication. |
| Alerts: |
|
Comments (none 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)
racoon: failure to verify signatures
| Package(s): | ipsec-tools racoon |
CVE #(s): | CAN-2004-0155
|
| Created: | April 7, 2004 |
Updated: | August 19, 2004 |
| Description: |
Versions of ipsec-tools prior to 0.2.5 contain a vulnerability wherein the racoon utility fails to verify digital signatures on some packets. This hole can lead to unauthorized connections or man-in-the-middle attacks. See this advisory for details. |
| Alerts: |
|
Comments (none posted)
racoon: denial of service vulnerability
| Package(s): | ipsec-tools racoon iputils |
CVE #(s): | CAN-2004-0403
|
| Created: | April 26, 2004 |
Updated: | July 29, 2004 |
| Description: |
racoon does not check the length of ISAKMP headers. Attackers may be able
to craft an ISAKMP header of sufficient length to consume all available
system resources, causing a Denial of Service. This advisory contains additional
details. |
| Alerts: |
|
Comments (none posted)
kdelibs: cookie disclosure
| Package(s): | kdelibs |
CVE #(s): | CAN-2003-0592
|
| Created: | March 10, 2004 |
Updated: | August 24, 2004 |
| Description: |
kdelibs (and, thus, Konqueror) has a vulnerability where a hostile server can force the disclosure of cookies that should not be presented to it. KDE versions 3.1.3 and later contain a fix. |
| Alerts: |
|
Comments (none posted)
kde: URI Handler Vulnerabilities
| Package(s): | kde Opera |
CVE #(s): | CAN-2004-0411
|
| Created: | May 17, 2004 |
Updated: | June 15, 2004 |
| Description: |
iDEFENSE identified a vulnerability in the Opera Web Browser that could
allow remote attackers to create or truncate arbitrary files. The KDE team
has found that similar vulnerabilities exists in all version of KDE, up to
KDE 3.2.2 inclusive. See this advisory for
more information. |
| Alerts: |
|
Comments (none posted)
kernel: symlink overflow in the iso9660 filessytem
| Package(s): | kernel |
CVE #(s): | CAN-2004-0109
|
| Created: | April 14, 2004 |
Updated: | July 15, 2004 |
| Description: |
The 2.4 and 2.6 kernels contain a
vulnerability in the iso9660 (CDROM) filesystem which can be used by a
local attacker to obtain root privileges. The exploit requires creating a
specially-crafted filesystem and getting the kernel to mount it. Many
systems are configured to automatically mount CDs on insertion, however, so
the possibility of this vulnerability being exploited by users with
physical access to the system is real. The 2.4.26 kernel contains the fix,
which will also be merged into the upcoming 2.6.6 release. |
| Alerts: |
|
Comments (none posted)
kernel - root exploit in MCAST_MSFILTER
| Package(s): | kernel |
CVE #(s): | CAN-2004-0424
|
| Created: | April 22, 2004 |
Updated: | June 11, 2004 |
| Description: |
A locally exploitable integer overflow has been found the multicast code
of the Linux kernel versions 2.4.22 to 2.4.25 and 2.6.1 - 2.6.3. A
successful exploit could lead to full superuser privileges. |
| 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)
krb5: unauthorized root privileges
| Package(s): | krb5 |
CVE #(s): | CAN-2004-0523
|
| Created: | June 3, 2004 |
Updated: | June 29, 2004 |
| Description: |
Multiple buffer overflows exist in the krb5_aname_to_localname() library
function that if exploited could lead to unauthorized root privileges. In
order to exploit this flaw, an attacker must first successfully
authenticate to a vulnerable service, which must be configured to enable
the explicit mapping or rules-based mapping functionality of
krb5_aname_to_localname, which is not a default configuration. See the
this MIT krb5 Security Advisory for more information. |
| Alerts: |
|
Comments (none posted)
LHA: stack buffer overflows and directory traversal flaws
| Package(s): | LHA |
CVE #(s): | CAN-2004-0234
CAN-2004-0235
|
| Created: | April 30, 2004 |
Updated: | June 11, 2004 |
| Description: |
LHA is an archiving and compression utility for LHarc format archives. Ulf
Harnhammar discovered two stack buffer overflows and two directory
traversal flaws in LHA. See this advisory+patch for more details.
CAN-2004-0234: An attacker could exploit the buffer overflows by creating a
carefully crafted LHA archive in such a way that arbitrary code would be
executed when the archive is tested or extracted by a victim.
CAN-2004-0235: An attacker could exploit the directory traversal issues to
create files as the victim outside of the expected directory. |
| Alerts: |
|
Comments (2 posted)
libpng: denial of service vulnerability.
| Package(s): | libpng |
CVE #(s): | CAN-2004-0421
|
| Created: | April 29, 2004 |
Updated: | June 11, 2004 |
| Description: |
The PNG library can accesses memory that is out of bounds when
creating an error message, this can be exploited by a malformed
PNG image file. |
| 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)
libxml2 - arbitrary code execution
| Package(s): | libxml2 |
CVE #(s): | CAN-2004-0110
|
| Created: | February 26, 2004 |
Updated: | July 21, 2004 |
| Description: |
Yuuichi Teranishi discovered a flaw in libxml2 versions prior to 2.6.6.
When fetching a remote resource via FTP or HTTP, libxml2 uses special
parsing routines. These routines can overflow a buffer if passed a very
long URL. If an attacker is able to find an application using libxml2 that
parses remote resources and allows them to influence the URL, then this
flaw could be used to execute arbitrary code. |
| Alerts: |
|
Comments (none posted)
log2mail: format string vulnerability
| Package(s): | log2mail |
CVE #(s): | CAN-2004-0450
|
| Created: | June 3, 2004 |
Updated: | June 9, 2004 |
| Description: |
jaguar -at- felinemenace.org discovered a format string vulnerability in
log2mail, whereby a user able to log a specially crafted message to a
logfile monitored by log2mail (for example, via syslog) could cause
arbitrary code to be executed with the privileges of the log2mail process.
By default, this process runs as user 'log2mail', which is a member of
group 'adm' (which has access to read system logfiles). |
| Alerts: |
|
Comments (none posted)
logcheck: symlink vulnerability
| Package(s): | logcheck |
CVE #(s): | CAN-2004-0404
|
| Created: | April 21, 2004 |
Updated: | December 22, 2004 |
| Description: |
The logcheck utility handles temporary files in an unsafe way, possibly allowing local attackers to overwrite files. |
| Alerts: |
|
Comments (none posted)
mailman: password disclosure
| Package(s): | mailman |
CVE #(s): | CAN-2004-0412
|
| Created: | May 27, 2004 |
Updated: | July 20, 2004 |
| Description: |
In mailman versions above 2.1, third parties can retrieve
member passwords from the server. |
| 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)
mod_python: denial of service vulnerability
| Package(s): | mod_python |
CVE #(s): | CAN-2003-0973
|
| Created: | January 27, 2004 |
Updated: | October 4, 2004 |
| Description: |
Apache's mod_python module could crash the httpd process if a specific,
malformed query string was sent.
The Apache Foundation has reported that mod_python may be prone to
Denial of Service attacks when handling a malformed query. Mod_python
2.7.9 was released to fix the vulnerability, however, because the
vulnerability has not been fully fixed, version 2.7.10 has been released.
Users of mod_python 3.0.4 are not affected by this vulnerability. |
| Alerts: |
|
Comments (none posted)
mozilla: multiple vulnerabilties
| Package(s): | mozilla |
CVE #(s): | CAN-2003-0594
CAN-2003-0564
|
| Created: | March 10, 2004 |
Updated: | August 19, 2004 |
| Description: |
Mozilla 1.4 contains a few vulnerabilities, including disclosure of cookies to the wrong server, a scripting vulnerability which can allow an attacker to run arbitrary code, and an S/MIME vulnerability which can lead to remote denial of service or code execution attacks. |
| Alerts: |
|
Comments (none 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)
MySQL: temporary file vulnerabilities
| Package(s): | mysql |
CVE #(s): | CAN-2004-0381
CAN-2004-0388
|
| Created: | April 14, 2004 |
Updated: | August 18, 2004 |
| Description: |
The mysqlbug and mysqld_multi scripts contain temporary file vulnerabilities which could be used by a local attacker to overwrite files on the system. |
| Alerts: |
|
Comments (none posted)
neon: buffer overflow
| Package(s): | neon |
CVE #(s): | CAN-2004-0398
|
| Created: | May 19, 2004 |
Updated: | September 30, 2004 |
| Description: |
The neon library (through version 0.24.5) contains a buffer overflow in its date parsing code, allowing arbitrary code execution when connecting to a hostile server. See this advisory for details. This vulnerability also affects related applications (such as cadaver). |
| 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)
netpbm: insecure temporary files
| Package(s): | netpbm |
CVE #(s): | CAN-2003-0924
|
| Created: | January 19, 2004 |
Updated: | December 29, 2004 |
| Description: |
netpbm is graphics conversion toolkit made up of a large number of
single-purpose programs. Many of these programs were found to create
temporary files in an insecure manner, which could allow a local
attacker to overwrite files with the privileges of the user invoking a
vulnerable netpbm tool. |
| Alerts: |
|
Comments (1 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)
OpenSSL: denial of service vulnerabilities
Comments (1 posted)
postgresql buffer overflow in ODBC driver
| Package(s): | postgresql |
CVE #(s): | |
| Created: | June 7, 2004 |
Updated: | July 28, 2004 |
| Description: |
A buffer overflow has been discovered in the ODBC driver of PostgreSQL,
an object-relational SQL database, descended from POSTGRES. It possible
to exploit this problem and crash the surrounding application. Hence, a
PHP script using php4-odbc can be utilized to crash the surrounding
Apache webserver. Other parts of postgresql are not affected. |
| Alerts: |
|
Comments (none posted)
python: buffer overflow
| Package(s): | python |
CVE #(s): | CAN-2004-0150
|
| Created: | March 10, 2004 |
Updated: | October 11, 2004 |
| Description: |
Python (versions 2.2 and 2.2.1 only) has a buffer overflow in the getaddrinfo() function which can be exploited by a malformed IPv6 address. |
| Alerts: |
|
Comments (none posted)
rsync remote file write attack
| Package(s): | rsync |
CVE #(s): | CAN-2004-0426
|
| Created: | April 30, 2004 |
Updated: | July 12, 2004 |
| Description: |
See the rsync homepage for the
April 2004
advisory: "There is a security problem in all versions prior to
2.6.1 that affects only people running a read/write daemon WITHOUT using
chroot. If the user privs that such an rsync daemon is using is anything
above "nobody", you are at risk of someone crafting an attack that could
write a file outside of the module's "path" setting (where all its files
should be stored). Please either enable chroot or upgrade to 2.6.1. People
not running a daemon, running a read-only daemon, or running a chrooted
daemon are totally unaffected." |
| Alerts: |
|
Comments (none posted)
squid: buffer overflow
| Package(s): | squid |
CVE #(s): | CAN-2004-0541
|
| Created: | June 9, 2004 |
Updated: | September 30, 2004 |
| Description: |
The NTLM authentication helper used by the squid proxy contains a buffer overflow vulnerability; an overly-long password may be used to run arbitrary code. Sites not using NTLM authentication are not vulnerable. |
| Alerts: |
|
Comments (none posted)
SquirrelMail cross site scripting vulnerabilities
