One of the major problems with Simple Mail Transport Protocol (SMTP) is that
it allows email senders to forge information about who they are. The lack
of sender authentication allows unscrupulous users to send email that
appears to come from a domain other than where it truly originates. Spammers
use this 'feature' to disguise their email and to cause any bounces or
responses to be handled by someone else.
There are several proposals for combating this problem that are currently
being worked on; we will describe some of them below. Before we do,
however,
a bit of a review on how SMTP currently works is in order.
When a host wants to send mail, it looks at the DNS Mail Exchanger (MX)
record for the destination domain and makes a connection to the host that
is indicated. The sending host identifies itself, the email address of
the sender of the message,
and the address of the recipient of the message to the destination host
via SMTP messages.
This is known as the envelope of the message and, if it is accepted by the
destination host, the sender proceeds to send the body of the message. The
message body contains
RFC822
headers (From:, To:, Subject:, etc.) that are used by Mail User Agents (MUAs)
to identify the message to users. SMTP servers traditionally do not do
any kind of checking on the envelope data they receive, believing that other
hosts will not deceive them. Any part of the envelope and RFC822 headers
can be forged (except, of course, the recipient in the envelope).
Obviously, SMTP has its roots in a much
friendlier Internet where trusting other hosts was the norm.
Recently, Yahoo announced an initiative that is meant to combat spam called
Domain Keys.
Technical details are somewhat sketchy, but the basic idea is that the DNS
records for a domain would include a public key. Email that originates from
that domain would use the corresponding private key to encrypt some data
(it is not clear exactly what, but a cryptographic hash of the message
contents would seem an obvious choice) that would be placed in an email header.
Mail Transfer Agents (MTAs) that received the message could decrypt it using
the public key in the DNS record and if the decrypted value was correct, the
MTA would know that the message originated from the domain that was claimed.
Sender Permitted From (SPF) is a proposal
to add information to the DNS records for a domain specifying what
machines legitimately send email
for that domain. This information is the reverse of the MX record, rather
than specifying hosts that receive email for the domain, they specify hosts
that send it. This would
allow MTAs to check the IP address of the sender and the host name provided
in the SMTP envelope along with the SPF information in DNS to determine
whether that IP address is a legitimate sender for that domain.
(LWN covered SPF in more detail last
October).
The
Trusted Email Open Standard
(TEOS) is a wide-ranging proposal that has three implementation steps
and would eventually allow for third-party certification of email messages
as coming from a trusted source. This scheme would operate in some ways
like the
SSL Certificate Signing Authorities; an MTA could verify that a message
came from a source trusted by the third party. The first step that TEOS
proposes is similar to the Domain Keys proposal; it would provide a way to
authenticate email senders. The second stage adds the ability for senders
to make assertions about the contents of the email, saying, for example,
that it contains advertising or an opt-in mailing, or that the sender and
recipient have a business or family relationship.
Users would be able
to filter the mail based on the assertions (or lack thereof). If the sender
incorrectly categorizes a message, the authentication will not allow the
blame to be shifted elsewhere, providing a large incentive to be
truthful when making the assertions.
The Tripoli proposal
envisions an entirely new email infrastructure, at first running in
parallel with the current SMTP-based system, but eventually supplanting
it. The underlying principle is that the
receiver of email should have greater control than any of the other parties
involved, including the sender, ISPs that
transmit the email, or governments. The system proposed would eventually
have end-to-end encryption for all email traffic. Associated with each
email would be a cryptographic token that is certified by a third-party to
a particular level of authentication; email recipients could then choose the
level of authentication that they wish to require and can reject any
messages that fall below this standard.
These proposals are a testament to just how problematic and widespread the
spam problem has become. The scope of some of these proposals, particularly
TEOS and Tripoli, show how far some people are willing to go to try and
combat it. Adding third-parties to email sending could have a
number of security and privacy concerns and would almost certainly add
a cost to sending email. If that cost breaks the current economic
model of spamming, however, it may be effective, but it would also impact lots
of other bulk email
uses today (legitimate mailing list traffic, opt-in newsletters and the
like).
On the other hand, Domain Keys and SPF could be
circumvented by spammers willing to create throwaway domains that conform
to the requirements. Once the domains are identified as spam domains,
they can be added to blacklists, of course, but there have been any number
of problems with that particular solution as well. Authenticating senders
might help track down spammers, but until the risk of detection and the cost
of conviction are greatly increased, it is likely to only slow things down
and perhaps not by much.
It should be interesting to watch the battle over our email inboxes play
out over the next few years. It may well be that one or more of these
proposals is adopted (or some combination of them) by a significant portion
of email users and providers. Unfortunately, in the meantime, less technical
email users are suffering at the hands of the spammers to the point where
email is no longer a useful communications medium for many.
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.
xchat: remotely exploitable denial of service vulnerability
Package(s):
xchat
CVE #(s):
Created:
December 15, 2003
Updated:
December 17, 2003
Description:
There is a remotely exploitable bug in xchat 2.0.6 that could lead to a
denial of service attack. This is caused by sending a malformed DCC packet
to xchat 2.0.6, causing it to crash. Versions prior to 2.0.6 do not appear
to be affected by this bug. For more information, please see this
advisory.
Several security issues have been discovered affecting the Linux kernel:
CAN-2003-0461: /proc/tty/driver/serial reveals the exact character
counts for serial links. This could be used by a local attacker to infer
password lengths and inter-keystroke timings during password entry.
CAN-2003-0462: Paul Starzetz discovered a file read race condition
existing in the execve() system call, which could cause a local crash.
CAN-2003-0464: A recent change in the RPC code set the reuse flag on
newly-created sockets. Olaf Kirch noticed that his could allow normal
users to bind to UDP ports used for services such as nfsd.
CAN-2003-0476: The execve system call in Linux 2.4.x records the file
descriptor of the executable process in the file table of the calling
process, allowing local users to gain read access to restricted file
descriptors.
CAN-2003-0501: The /proc filesystem in Linux allows local users to
obtain sensitive information by opening various entries in /proc/self
before executing a setuid program. This causes the program to fail to
change the ownership and permissions of already opened entries.
CAN-2003-0550: The STP protocol is known to have no security, which
could allow attackers to alter the bridge topology. STP is now turned
off by default.
CAN-2003-0551: STP input processing was lax in its length checking,
which could lead to a denial of service.
CAN-2003-0552: Jerry Kreuscher discovered that the Forwarding table
could be spoofed by sending forged packets with bogus source addresses
the same as the local host.
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.
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.
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).
Stable CVS 1.11.10 has
been released, fixing a security issue with no known exploits (as of
this writing) that could cause previous versions of CVS to attempt to
create files and directories in the filesystem root. This release also
fixes several issues relevant to case insensitive filesystems and some
other bugs.
Multiple vulnerabilities have been found in
ethereal versions below 0.9.16. Remote attackers can craft
packets, and local users can build corrupt trace files,
resulting denial of service and remote code execution.
"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.
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.
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).
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."
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.
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.
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:
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.
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.
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.
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.
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.
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.
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."
Pan is a Gnome/GTK+ newsreader. A bug in Pan versions prior to 0.13.4 can
cause Pan to crash when parsing an article header containing a very long
author email address. This bug causes a crash (denial of service) but is
not further exploitable.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
Bruce Schneier's CRYPTO-GRAM newsletter for December is out. It looks at
whether the Blaster worm caused the August 14 blackout (he thinks it
may have), electronic voting, and products using quantum cryptography. "I don't have any hope for this sort of product. I don't have any hope
for the commercialization of quantum cryptography in general; I don't
believe it solves any security problem that needs solving. I don't
believe that it's worth paying for, and I can't imagine anyone but a
few technophiles buying and deploying it."
