Brief items
The Center for Democracy and Technology has released
the results
from a six-month survey on how spammers obtain email addresses. The
researchers created a few hundred special-purpose email addresses, then
carefully exposed each one in exactly one place. After that, it was mostly
a matter of sitting back and waiting for the spam to roll in. The
destination of each spam indicated where the address had been found.
The report is well worth a read. For those of you in a hurry, here are the
highlights of the group's conclusions:
- By far the most spam was sent to addresses harvested from web pages.
Postings to Usenet newsgroups came in a distant second. On Usenet,
posters to groups like alt.sex.erotica will receive vastly more spam
than those posting to misc.industry.insurance.
- Even the most simple sort of address obfuscation
("lwn at lwn.net") appears to be highly effective.
- Dictionary attacks (simply trying login names from a list) result in a
significant amount of delivered spam. Short account names are more
likely to receive this sort of spam than longer ones.
- Contrary to expectations, the WHOIS domain name database is not a big
source of spam.
- Most web sites honor their promises regarding unsolicited email - but
you do have to be careful about making your wishes clear.
Regardless of source, spam is an increasing problem; the volume of spam
sent to lwn@lwn.net (hmm...make that
lwn at lwn.net) is now running about 500 messages per
day. If it weren't for SpamAssassin, we would have a hard time
dealing with our email at all.
Comments (7 posted)
Bruce Schneier's CRYPTO-GRAM newsletter for April is out. Topics this
month include "catalog attacks" (signing up a victim for large amounts of
junk mail), the National Crime Information Center database, and several
other topics. "
Security decisions are always about more than security. When trying to
evaluate a particular decision, always pay attention to the
non-security agendas of the people involved.
"
Full Story (comments: none)
New vulnerabilities
epic: buffer overflows
| Package(s): | epic |
CVE #(s): | |
| Created: | April 15, 2003 |
Updated: | April 16, 2003 |
| Description: |
Timo Sirainen discovered several problems in EPIC, a popular client for
Internet Relay Chat (IRC). A malicious server could craft special reply
strings, triggering the client to write beyond buffer boundaries. This
could lead to a denial of service if the client only crashes, but may also
lead to executing of arbitrary code under the user id of the chatting user. |
| Alerts: |
|
Comments (none posted)
gs-common: insecure temporary file
| Package(s): | gs-common |
CVE #(s): | |
| Created: | April 14, 2003 |
Updated: | April 16, 2003 |
| Description: |
Paul Szabo discovered insecure creation of a temporary file in
ps2epsi, a script that is distributed as part of gs-common which
contains common files for different Ghostscript releases. ps2epsiuses
a temporary file in the process of invoking ghostscript. This file
was created in an insecure fashion, which could allow a local attacker
to overwrite files owned by a user who invokes ps2epsi. |
| 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)
kde: arbitrary code execution
| Package(s): | kde |
CVE #(s): | CAN-2003-0204
|
| Created: | April 10, 2003 |
Updated: | June 30, 2003 |
| Description: |
The KDE Security team has issued an advisory
on a vulnerability present in all versions of KDE that allow a remote
attacker to execute arbitrary commands under your account. KDE 3.0.5b and
KDE 3.1.1a have been released to address this problem. For KDE 2.2.2
patches to the KDE 2.2.2 sources have been made available.
KDE uses Ghostscript software for processing of PostScript (PS) and PDF
files in a way that allows for the execution of arbitrary commands that can
be contained in such files.
An attacker can prepare a malicious PostScript or PDF file which will
provide the attacker with access to the victim's account and privileges
when the victim opens this malicious file for viewing or when the victim
browses a directory containing such malicious file and has file previews
enabled.
An attacker can provide malicious files remotely to a victim in an e-mail,
as part of a webpage, via an ftp server and possible other means. |
| Alerts: |
|
Comments (none posted)
LPRng: insecure temporary file
| Package(s): | LPRng |
CVE #(s): | CAN-2003-0136
|
| Created: | April 14, 2003 |
Updated: | June 16, 2003 |
| Description: |
Karol Lewandowski discovered that psbanner, a printer filter that
creates a PostScript format banner and is part of LPRng, insecurely
creates a temporary file for debugging purpose when it is configured
as filter. The program does not check whether this file already
exists or is linked to another place writes its current environment
and called arguments to the file unconditionally with the user id
daemon. |
| Alerts: |
|
Comments (none posted)
xfsdump: insecure file creation
| Package(s): | xfsdump |
CVE #(s): | CAN-2003-0173
|
| Created: | April 11, 2003 |
Updated: | April 16, 2003 |
| Description: |
Ethan Benson discovered a problem in xfsdump, that contains administrative
utilities for the XFS filesystem. When filesystem quotas are enabled
xfsdump runs xfsdq to save the quota information into a file at the root of
the filesystem being dumped. The manner in which this file is created is
unsafe.
While fixing this, a new option ``-f path'' has been added to xfsdq(8) to
specify an output file instead of using the standard output stream. This
file is created by xfsdq and xfsdq will fail to run if it exists already.
The file is also created with a more appropriate mode than whatever the
umask happened to be when xfsdump(8) was run. |
| Alerts: |
|
Comments (none posted)
Page editor: Jonathan Corbet
Next page:
Kernel development>>
