Re: Bug in Bind 9.1.0? [Summary]
More repro reports etc: From: Stephen Oberther <[EMAIL PROTECTED]> Hmmm..it doesn't have the same affect on our machine. i386 with Debian 2.2 running a home compiled BIND-9.1.0 Must be something in the configuration of the NetBSD package. -- From: Raptor <[EMAIL PROTECTED]> I tried on this box: narcissism:raptor {3} uname -a OpenBSD narcissism 2.8 NARCISSISM#0 i386 ;; ANSWER SECTION: version.bind. 0S CHAOS TXT"9.1.0" Named continued working perfectly. We installed it from source distribution tarballs (non from ports) and it's running in a chrooted environment. -- From: "Bryan Paxton" <[EMAIL PROTECTED]> Tested on Linux-2.4.2-pre1 (x86 SMP)| ISC BIND 9.1.0 | nmap version 2.12 Results: Didn't crash : ) --- From: Max Parke <[EMAIL PROTECTED]> > From [EMAIL PROTECTED] Tue Feb 6 21:40:07 2001 > Feb 5 22:30:35 tel named[50956]: netaddr.c:231: INSIST(0) failed > Feb 5 22:30:35 tel named[50956]: exiting (due to assertion failure) > Feb 5 22:30:35 tel /kernel: pid 50956 (named), uid : exited on > signal 6 hrm.. no, mine is much different. ugh. I hate BIND. -lucas Feb 6 21:05:55 x /usr/bind/named[56945]: client 123.123.123.150#1279: error sending response: operation canceled Feb 6 21:05:55 x /usr/bind/named[56945]: client 123.123.123.150#1280: error sending response: operation canceled Feb 6 21:05:55 x /usr/bind/named[56945]: client 123.123.123.151#1166: error sending response: operation canceled Feb 6 21:06:15 x last message repeated 211 times Feb 6 21:06:16 x /usr/bind/named[56945]: client 10.1.1.2#137: error sending response: operation canceled Feb 6 21:06:45 x /usr/bind/named[56945]: mem.c:1404: REQUIRE(mpctx->allocated == 0) failed Feb 6 21:06:45 x /usr/bind/named[56945]: exiting (due to assertion failure) Feb 6 16:06:45 x /kernel: pid 56945 (named), uid 53: exited on signal 6 Ben Greenbaum Director of Site Content SecurityFocus http://www.securityfocus.com
Re: Security hole in ChiliSoft ASP on Linux.
On Tue, Feb 06, 2001 at 05:00:07PM -0500, Mark Krenz <[EMAIL PROTECTED]> rambled: > Affected systems: > > I tested and confirmed this problem on a RedHat Linux 6.2 machine > running RedHat SecureWebServer 3.2.1, which is basically Apache 1.3.9 > with mod_ssl. I am unable to test this on Solaris or any other Un*x > platform so I'm unsure if the problem exists on other OSes. Chili!Soft > didn't specify whether the problem existed on other platforms. All cobalt boxes that come with Chili!Soft have it on by default. But they are not affected by this bug as the inherit_user is off by default: /home/chiliasp/admin/bin/casp.cnfg:inherit_user=0 (For those using the great line of Cobalt products.) gonzo -- Gonzo Granzeau | [EMAIL PROTECTED] | feed me the stray cat. 'You're no one til someone hates you' -Snake River Conspiracy
Response to ProFTPD issues
=== Summary === Three issues with the ProFTPD FTP server have been reported to BUGTRAQ in the past month. These issues have been addressed by the ProFTPD core team. The following vulnerabilities are addressed in this advisory: 1. "SIZE memory leak" http://www.securityfocus.com/archive/1/151991 Reported by Wojciech Purczynski <[EMAIL PROTECTED]> 2. "USER memory leak" http://www.securityfocus.com/archive/1/155349 Reported by Wojciech Purczynski <[EMAIL PROTECTED]> 3. "Minor format string vulnerabilities" http://www.securityfocus.com/archive/1/155428 Reported by Przemyslaw Frasunek <[EMAIL PROTECTED]> All three are thought to exist in all previous 1.2.0 test releases, (1.2.0pre[1-10], 1.2.0rc[1-2]). All three now have been fixed, and patches have been committed to the ProFTPD CVS repository. A new release, 1.2.0rc3, containing these fixes has been made available as of 5 February and is available from: http://www.proftpd.org/download.html ftp://ftp.proftpd.org/distrib/proftpd-1.2.0rc3.tar.gz Instructions for accessing the CVS repository via Anonymous CVS are available at: http://www.proftpd.org/docs/cvs.html = 1. "SIZE memory leak" = ProFTPD may leak memory when commands are executed. However, this leak will take place *only* if ProFTPD's scoreboard file is not writable. If ProFTPD is installed properly and is allowed to write to the scoreboard file, no leak will take place. The scoreboard file is created in /usr/local/var/proftpd/ in a standard installation from source. If you did not install ProFTPD from sources, please contact your vendor for the intended location of your scoreboard file. More information, including patches, can be found at http://bugs.proftpd.net/show_bug.cgi?id=408 = 2. "USER memory leak" = A memory leak in the USER command was found. Issuing additional USER commands causes the ProFTPD server to consume additional memory. More information, including patches, can be found at http://bugs.proftpd.net/show_bug.cgi?id=408 3. "Minor format string vulnerabilities" Two minor format string vulnerabilities were found in ProFTPD. Due to the nature of the data processed by the affected sections of code, these vulnerabilities are very difficult, if not impossible, to exploit. A full audit was done on the callers of any functions that accept printf-like format arguments. One minor, unexploitable issue was found in a third-party module (mod_ratio) and has been fixed. No other format string vulnerabilites were found. More information, including patches, can be found at http://bugs.proftpd.net/show_bug.cgi?id=430 -- John Morrissey _o/\ __o [EMAIL PROTECTED]_-< \_ / \ < \, www.horde.net/__(_)/_(_)/\___(_) /_(_)__
Re: Pinoy math enthusiast finds fast way to decode RSA encryption
#!/usr/local/bin/perl -w # getcycle.pl # (Copyright) Robert A. Lacroix, Feb. 6, 2001; Winnipeg, Canada # This algorithm efficiently solves problems of the form 2^x = aN + 1, # using O(log N) storage and O(log N)(log N) time. # I am reinventing the wheel, or is it "Goodbye, RSA?" # Input restrictions: argument N must be a positive odd integer. # This implementation is subject to machine word size overflow. # # Happy Birthday, Vonne. use integer; local ($i, $n, $a, $b, $c, $k, $p, $x); $n = $ARGV[0]; if (($n & 1) == 0) { die "$n is even\n"; } $a = 0; # multiple of N $b = 0; # partial 2^x; actually uses 2(log N) bits at a time. $p = 0; # bit shift offset $i = 0; # iteration count while (1 == 1) { $k = (($b + 1) & ~$b); # mask for least significant 0 bit last if ($k > 1 && $k == $b+1); # loop exit condition $a |= $k << $p; # merge into result $c = -1;# determine bit position (base offset 0) while ($k != 0) { $k >>= 1; $c++; } $p += $c; # cumulative offset $b = ($b >> $c) + $n; $i++; } # complete the solution. $b = $a * $n + 1; $x = -1; while ($b != 0) { $b >>= 1; $x++; } print "2^$x = $a * $n + 1 in $i iterations\n"; sample run: getcycle.pl 231 2^30 = 4648233 * 231 + 1 in 12 iterations
Re: Bug in Bind 9.1.0?
Forwarded from a reader who wishes to remain anonymous: -- I just tried nmap O -sT -p 53 on a Cobalt RAQ running Linux 2.0.34 for MIPS, stock out of the box RAQ rented from a colo vendor, with 9.1.0 compiled on that machine, and nameservice stopped responding. I've only tested this on one RAQ, so it may be something about its config and not a general issue. No flags - it was just ./configure, make, make install. nmap consistently halts named there. The same command run against 9.1.0 on BSDi 4.0.1 and Linux 2.2.16 (both x86) had no effect. -- Ben Greenbaum Director of Site Content SecurityFocus http://www.securityfocus.com
NMAP trivially crashes NET-SNMP-4.1.2's snmpd when smux support is enabled
At the same time I was testing NMAP against BIND-9.1.0 it seems I wacked my snmpd too (that was with 'nmap -O -sT proven'). The last thing it uttered was: Feb 6 13:28:18 proven ucd-snmp[285]: [smux_accept] accepted fd 11 - errno 0 That's from NET-SNMP 4.1.2 built from NetBSD's pkgsrc/net/ucd-snmp module on NetBSD-1.5F (approx.) i386. The .build_info contains: USE_INET6= YES SSLBASE= /usr PKGPATH= net/ucd-snmp OPSYS= NetBSD OS_VERSION= 1.5F MACHINE_ARCH= i386 MACHINE_GNU_ARCH= i386 CPPFLAGS= -I/usr/pkg/include CFLAGS= -g -Dnetbsd1 -pipe -O2 LDFLAGS= -Wl,-R/usr/pkg/lib -L/usr/pkg/lib CONFIGURE_ENV= CPPFLAGS=" -I/usr/pkg/include" CFLAGS="-g -Dnetbsd1 -pipe -O2 -I/usr/pkg/include" LIBTOOL="/usr/pkg/bin/libtool " LDFLAGS=" -Wl,-R/usr/pkg/lib -L/usr/pkg/lib" M4="/usr/bin/m4" YACC="yacc" PATH=/usr/sbin:/sbin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/usr/libexec/uucp:/usr/lib:/usr/pkg/sbin:/usr/pkg/bin:/usr/local/sbin:/usr/local/bin:/usr/pkg/bin:/usr/X11R6/bin CONFIGURE_ARGS= --with-defaults --with-libwrap --with-logfile="/var/log/snmpd" --with-mib-modules="smux host" --with-dummy-values --with-sys-contact="[EMAIL PROTECTED]" --with-sys-location="defaultlocation" --enable-shared --enable-ipv6 --with-mibdirs="/usr/pkg/share/snmp/mibs:/usr/pkg/lib/tcl/tnm2.1.10/mibs:/usr/pkg/lib/tnm2.1.8/mibs:/usr/local/share/snmp/mibs" --host=i386--netbsd --prefix=/usr/pkg --x-libraries=/usr/X11R6/lib --x-includes=/usr/X11R6/include OBJECT_FMT= ELF LICENSE= RESTRICTED= NO_SRC_ON_FTP= NO_SRC_ON_CDROM= NO_BIN_ON_FTP= NO_BIN_ON_CDROM= CC= cc-egcs-1.1.2 _PKGTOOLS_VER=2829 -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
yes, it seems NMAP can trivially crash BIND-9.1.0, at least on i386....
Hmmm... I tried that little 'nmap -O -sT proven' trick, i.e. against my development machine on which I run BIND-9.1.0, and what do you know but named drops out almost immediately with a SIGBUS: Feb 6 13:28:19 proven /netbsd: named: pid 14653 [eid 32771:40, rid 32771:40] sent signal 6: was set-id, core dump not permitted [in /etc/namedb] This is a NetBSD-1.5F (approx.) i386 machine and BIND-9.1.0 was compiled and installed via the NetBSD pkgsrc/net/bind9 module. Now if I get time tonight I'll try again with the debugger attached and see exactly where it's going down, but I suspect others are doing / have done that. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
Security hole in ChiliSoft ASP on Linux.
Security hole in ChiliSoft ASP for Linux. Overview: ASP (Active Server Pages) are a technology initially developed by Microsoft to tackle the "dynamic content on the web" problem. Chili!Soft is a company that has released a piece of software called Chili!Soft ASP that makes ASP functionality available on other operating systems and webservers, such as Linux, Solaris and AIX, HP-UX, Apache, iPlanet, Lotus Domino and O'Reilly Website Pro. Synopsis: Under Un*x systems you can set the ChiliSoft ASP (CASP) daemon to run in one of two different security modes. The first one is defined mode, where you specify that the daemon be started as root and then run as the user you specify in the casp.cnfg configuration file. As an example, this mode would be useful on a company who runs their own webserver and uses one single user to own all their web content. The second mode that CASP can be run in is inherited mode. In this mode, the server is started by root and inherits the user and group information from each virtual host in the Apache webserver. So if a virtual domain called www.xyz.org was setup under Apache with the directives "User john" and "Group vhttp", any script run in that domain's webspace would run as the user john and the group vhttp. And thus the scripts would be restricted to accessing files based on the access allowed to that user and group. This is useful for ISPs that have webservers that are shared by many different virtual domain customers. Problem: While running CASP in the inherited security mode, none of the ASP scripts running under a user's virtual webspace inherit the group that is specified with the Group directive in the domain's virtual host container. So while the scripts end up running as the user specified with the User directive, they end up running as group root. This kinda defeats the whole purpose of inherited mode and is a major security problem. Affected systems: I tested and confirmed this problem on a RedHat Linux 6.2 machine running RedHat SecureWebServer 3.2.1, which is basically Apache 1.3.9 with mod_ssl. I am unable to test this on Solaris or any other Un*x platform so I'm unsure if the problem exists on other OSes. Chili!Soft didn't specify whether the problem existed on other platforms. Solutions: Chili!Soft informed me that this problem is fixed in their upcoming 3.6 release of Chili!Soft ASP which they claim is due out in the first quarter of 2001. A temporary solution might be to change your security mode to defined user mode by setting inherit_user=0 and specifying a user and group to run as in the casp.cnfg file. History: For a few days after I setup ChiliSoft ASP I was trying to figure out why inherited user mode wasn't working. I was testing it's ability to run in inherited mode by creating an ASP script that read a file mode 644 in root's home directory (the directory is mode 750 owned root.root). I figured that this was a good real situation to test whether the inheritance was working or not. I later tried to read another file in the same directory with permissions that restricted the root group (mode 600) from reading the file. That's when I realized that it was inheriting the root group, which was enabling it to get through to the root directory. I then went to Chili!Soft's support forum(http://www.chilisoft.com/forum/) to look for other instances where this problem might have been mentioned. I found none so I posted my own message to their forum explaining the problem. After waiting a half a day and receiving no response to my message on their forum I wrote to their tech support address with a duplicate copy of the message that I posted to their support forum. I received this response the same day from [EMAIL PROTECTED]: > This is a known issue with the software, and has been addressed in the > upcoming 3.6 round of releases. This is due on both Solaris and Linux > this quarter. We're in QA at this point, and this particular issue has > been resolved. Thank you for your interest in our product. I wrote them back and explained that this is a big security issue and should be resolved quickly and that if they knew about the problem they should have notified customers of the problem. They have only written me back since stating that the current release must go through many tests in Quality Assurance before they can release it to the public. It has now been a week since I initially notified Chili!Soft of the problem. There has been no real solution, so I'm posting to BugTraq. -- mark.krenz [EMAIL PROTECTED] Hey, did ya know something's beeping in the machine room?
Re: IBM NetCommerce Security
>Those look really funny, anyone know the what algorythm is used, i >suppose >it's the standard db2 function, but haven't tried that yet. .. because of the column type this is just a hexadecimal representation .. you can easily convert it to char ... > > 3) "Password-Reminders" >Actually these are the answers of the authentification questions, >asked >for >confirming the user's identity (which hints that the passwords may be > >decryptable) ... once you got the right answer you are able to change or at least reset the password .. and .. thats the trick :) >I just confirmed that on Net.Commerce 3.1.2 and it's a really nasty >bug. >One may query virtually any data from the db from almost any >macro (default & custom). I don't believe it's an error in >net.data. ... it is def. a "classic" "no-input-validation" :-) hole ... rc _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: Vulnerability in AOLserver
On Tue, 6 Feb 2001 [EMAIL PROTECTED] wrote: > Vulnerability in AOLserver > > Overview > > AOLserver v3.2 is a web server available from http://www.aolserver.com. > A vulnerability exists which allows a remote user user to break out of the > web root using relative paths (ie: '...'). > > Details > > AOLServer checks the requested virtual path for any double dots ('..'), > and returns a 'Not Found' error page if any are present. However, it > does not check for triple dots ('...'). Here is an example URL: > > http://localhost:8000/.../[file outside web root] > > Note that this vulnerability has only been tested on the latest stable > release (v3.2) for the Win32 platform. > > Solution > > No quick fix is possible. > > Vendor Status > > America Online, Inc. was contacted via http://www.aolserver.com/feedback/ > on Tuesday, January 30, 2001. No reply was received. Here's a possible "quick fix". It took me five minutes, but that was just because I had to download AOLserver for Windoze and install it. Simply copy the following Tcl code into a .tcl file in either the servers private or public Tcl library (c:\program files\aolserver\modules\tcl in the default Windows installation) and restart AOLserver. cut here ns_register_filter preauth GET /* windows_triple_dot_check ns_register_filter preauth POST /* windows_triple_dot_check ns_register_filter preauth HEAD /* windows_triple_dot_check proc windows_triple_dot_check {args} { if {[string match */...* [ns_conn url]]} { ns_returnforbidden return filter_return } else { return filter_ok } } cut here Regards, Michael A. Cleverly [EMAIL PROTECTED]
[RHSA-2001:011-03] Updated XEmacs packages available for Red Hat Powertools 6.2
- Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated XEmacs packages available for Red Hat Powertools 6.2 Advisory ID: RHSA-2001:011-03 Issue date:2001-02-02 Updated on:2001-02-06 Product: Red Hat Powertools Keywords: xemacs gnuserv gnuclient Cross references: Obsoletes: - 1. Topic: 2. Relevant releases/architectures: Red Hat Powertools 6.2 - alpha, i386, sparc 3. Problem description: The XEmacs package as shipped with Red Hat PowerTools 6.2 has a security problem with gnuserv and gnuclient, due to a buffer overflow and weak security. Note that this package obsoletes xemacs-mule (this is now compiled into the main binary), xemacs-static, xemacs-extras and xemacs-noX, as this is a backport of a newer xemacs package. 4. Solution: To update all RPMs for your particular architecture, run: rpm -Fvh where is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via Red Hat Network. Many people find this an easier way to apply updates. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 6. RPMs required: Red Hat Powertools 6.2: alpha: ftp://updates.redhat.com/powertools/6.2/alpha/xemacs-21.1.14-2.62.alpha.rpm ftp://updates.redhat.com/powertools/6.2/alpha/xemacs-el-21.1.14-2.62.alpha.rpm ftp://updates.redhat.com/powertools/6.2/alpha/xemacs-info-21.1.14-2.62.alpha.rpm i386: ftp://updates.redhat.com/powertools/6.2/i386/xemacs-21.1.14-2.62.i386.rpm ftp://updates.redhat.com/powertools/6.2/i386/xemacs-el-21.1.14-2.62.i386.rpm ftp://updates.redhat.com/powertools/6.2/i386/xemacs-info-21.1.14-2.62.i386.rpm sparc: ftp://updates.redhat.com/powertools/6.2/sparc/xemacs-21.1.14-2.62.sparc.rpm ftp://updates.redhat.com/powertools/6.2/sparc/xemacs-el-21.1.14-2.62.sparc.rpm ftp://updates.redhat.com/powertools/6.2/sparc/xemacs-info-21.1.14-2.62.sparc.rpm 7. Verification: MD5 sum Package Name -- 963901255ab8377baf92bcc8f3ec30b3 6.2/alpha/xemacs-21.1.14-2.62.alpha.rpm c1fa617399ff85af31c5d31e314249a8 6.2/alpha/xemacs-el-21.1.14-2.62.alpha.rpm e190d32da1a92132d53ee734a93b43cb 6.2/alpha/xemacs-info-21.1.14-2.62.alpha.rpm 661aae1be3097c403df3d38eb5f6ae80 6.2/i386/xemacs-21.1.14-2.62.i386.rpm 03fab61adb2f874f95dfc895e1ede878 6.2/i386/xemacs-el-21.1.14-2.62.i386.rpm bae82e4622a0b4b810eaa690446442b5 6.2/i386/xemacs-info-21.1.14-2.62.i386.rpm 5c4a36734b54ebd3be33e9404bbcb8e6 6.2/sparc/xemacs-21.1.14-2.62.sparc.rpm ef99cb1d6d1d2a0f90f034d4a3a0697f 6.2/sparc/xemacs-el-21.1.14-2.62.sparc.rpm e4a34278881cc1ec29f817bbcfc8f52b 6.2/sparc/xemacs-info-21.1.14-2.62.sparc.rpm These packages are GPG signed by Red Hat, Inc. for security. Our key is available at: http://www.redhat.com/corp/contact.html You can verify each package with the following command: rpm --checksig If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: rpm --checksig --nogpg 8. References: Copyright(c) 2000, 2001 Red Hat, Inc. ___ Redhat-watch-list mailing list To unsubscribe, visit: https://listman.redhat.com/mailman/listinfo/redhat-watch-list
Re: IBM NetCommerce Security
On Tue, 6 Feb 2001, Emil Popov wrote: Any thoughts, fixes, ideas?? The best way is to add 0 to the order_rn before using it. if the operation passes, the input was an int. If it failed, then it wasnt and something funky was attempted. This is obviously only going to prevent munging of integer fields but thats the vast majprity. Its been a while since I coded n.c sites so I do not recall the exact Add() function, but memory seems to tell me that there was even a SecurityCheck function in the engine (and undocumented i believe) that did this exact functionality for you. If i had an install in front of me, i would search the default macros for 'SecurityCheck' or some variant. -- gedanken
Vulnerability in AOLserver
Vulnerability in AOLserver Overview AOLserver v3.2 is a web server available from http://www.aolserver.com. A vulnerability exists which allows a remote user user to break out of the web root using relative paths (ie: '...'). Details AOLServer checks the requested virtual path for any double dots ('..'), and returns a 'Not Found' error page if any are present. However, it does not check for triple dots ('...'). Here is an example URL: http://localhost:8000/.../[file outside web root] Note that this vulnerability has only been tested on the latest stable release (v3.2) for the Win32 platform. Solution No quick fix is possible. Vendor Status America Online, Inc. was contacted via http://www.aolserver.com/feedback/ on Tuesday, January 30, 2001. No reply was received. - Joe Testa ( e-mail: [EMAIL PROTECTED] / AIM: LordSpankatron )
man issue
hi, the format issue of man seems harmless. the bug lies inhere /* XXX */ if (!display (NULL, argv[optind], NULL, basename(argv[optind]))) { error (0, errno, argv[optind]); exit_status = NOT_FOUND; } where error() is format-capable. However root privs are dropped before. So, you could gain a user-shell if you want. Please dont run man setgid, as man doesnt drop effective group ID. l8, Sebastian
Re: Bug in Bind 9.1.0? [Summary]
This appears to not be as big a problem as it might have seemed, based on the original report. --- From: Jonas Thambert <[EMAIL PROTECTED]> I wasnt able to replicate this error on a fully patched RH 7.0 with BIND 9.1.0. -- From: Stephen Clouse <[EMAIL PROTECTED]> No effect on bind-9.1.0 built from source on linux (slackware-7.0, kernel 2.4.0). --- From: Ian Gulliver <[EMAIL PROTECTED]> I can't reproduce this using bind 9.1.0 on Linux 2.2.16/glibc 2.1.3 against nmap 2.54BETA1. The source line listed would trigger if a socket family other than AF_INET or AF_INET6 was being used. A quick grep through the nmap source, however, shows nothing other than AF_INET passed to socket(). From: "Smith, John" <[EMAIL PROTECTED]> I cannot duplicate this with Bind 9.1.0 running on a Solaris 7 box. The Bind install is plain vanilla (configure, make, make install). From: Phil Brutsche <[EMAIL PROTECTED]> I haven't been able to reproduce this so far. I'm using BIND 9.1.0 on Debian "potato", with Linux kernel 2.4.0, and nmap 2.53 to scan the server. Hrm... looking at the source, I think there may be other issues with your crash. From lib/isc/netaddr.c (offending INSIST(0) is underlined): void isc_netaddr_fromsockaddr(isc_netaddr_t *t, const isc_sockaddr_t *s) { int family = s->type.sa.sa_family; t->family = family; switch (family) { case AF_INET: t->type.in = s->type.sin.sin_addr; break; case AF_INET6: memcpy(&t->type.in6, &s->type.sin6.sin6_addr, 16); break; default: INSIST(0); ^ } } -- From: Lucian Hudin <[EMAIL PROTECTED]> the "problem" lies in file netaddr.c in bind 9.1.0 , line 231 with "INSIST(0);" this is not a bug, imho. You can compile named without asserts. (#define ISC_CHECK_NONE in include/isc/assertions.h). void isc_netaddr_fromsockaddr(isc_netaddr_t *t, const isc_sockaddr_t *s) { int family = s->type.sa.sa_family; t->family = family; switch (family) { case AF_INET: t->type.in = s->type.sin.sin_addr; break; case AF_INET6: memcpy(&t->type.in6, &s->type.sin6.sin6_addr, 16); break; default: INSIST(0); } } searching for INSIST in source code tree also reveals this : in "bin/tests/system/resolver/tests.sh" "# If the server has the "INSIST(!external)" bug, this query will kill it. $DIG +tcp www.example.com. a @10.53.0.1 -p 5300 >/dev/null || status=1" Ben Greenbaum Director of Site Content SecurityFocus http://www.securityfocus.com
Windows client UDP exhaustion denial of service
Georgi Guninski security advisory #37, 2001 Windows client UDP exhaustion denial of service Systems affected: Windows 2000 Prof, Windows 98 probably other Windowses Risk: Low Date: 6 February 2001 Legal Notice: This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute it unmodified. You may not modify it and distribute it or distribute parts of it without the author's written permission. Disclaimer: The opinions expressed in this advisory and program are my own and not of any company. The usual standard disclaimer applies, especially the fact that Georgi Guninski is not liable for any damages caused by direct or indirect use of the information or functionality provided by this advisory or program. Georgi Guninski bears no responsibility for content or misuse of this advisory or program or any derivatives thereof. Description: It is possible a web page or email message to consume all the usable client UDP sockets on the computer running Windows. This leads to stopping client DNS resolution on Windows 2000 professional and stopping all new TCP connections on Windows 98. After closing the malicous application normal function of the system is restored though several machines spontaneously rebooted. It is interesting to note that Linux is not affected to this vulnerability as far as I tested. Details: This exploit uses java. The idea is quite simple - create as much UDP sockets (java.net.DatagramSocket) as possible. Other processes are prevented from creating new UDP sockets. The java code is: --- for(i=0;ihttp://www.guninski.com/winudpdos.html Vendor status: Microsoft was informed on 2 February 2001. Regards, Georgi Guninski http://www.guninski.com
Re: IBM NetCommerce Security
> exploit: > > > a few examples: > > 1) "HowTo find Administrator Accounts" > +http://shophost.com/cgi-bin/ncommerce3/ExecMacro/orderdspc.d2w/report?order_rn=9+union+select+s +hlogid+as+mestname,0+from+shopper+where+shshtyp+%3d+'A'; > > 2) "Passwords(crypted)" > +http://shophost.com/cgi-bin/ncommerce3/ExecMacro/orderdspc.d2w/report?order_rn=9+union+select+s +hlpswd+as+mestname,0+from+shopper+where+shlogid+%3d+'ncadmin'; > Those look really funny, anyone know the what algorythm is used, i suppose it's the standard db2 function, but haven't tried that yet. > 3) "Password-Reminders" > +http://shophost.com/cgi-bin/ncommerce3/ExecMacro/orderdspc.d2w/report?order_rn=9+union+select+s +hchaans+as+mestname,0+from+shopper+where+shlogid+%3d+'ncadmin'; Actually these are the answers of the authentification questions, asked for confirming the user's identity (which hints that the passwords may be decryptable) > > of course "orderdspc.d2w" is not the only vulnerable macro .. it s just an > example. casting between different data-types is possible (read the db2-man > pages). > > also it should(not proofed) be possible to query other databases. I just confirmed that on Net.Commerce 3.1.2 and it's a really nasty bug. One may query virtually any data from the db from almost any macro (default & custom). I don't believe it's an error in net.data. The whole concept is buggy and since most of the info returned by queries is thrown in the HTML in on form or another, and the macros usually trust the parameters passed to them and (like the order_rn) put them directly into the 'where' clause of the selects, thus allowing the attacker's 'union' to be sent to the db as a normal sql request from the macro :( It's quite difficult to think of a quick-fix for such a major issue, but it seems that IBM is not releasing a patch for a product they consider obsolete and superceeded by Web Sphere, or atleast i couldn't find one. Any thoughts, fixes, ideas?? ~~~ Regards Emil Popov [EMAIL PROTECTED]
Re: SuSe / Debian man package format string vulnerability
Megyer Ur wrote: > /usr/bin/man is a simple binary, without any suid bit, BUT > /usr/lib/man-db/man is suid man, and it's vulnerable to man -l > attack. So anyone can get man uid by exploiting it. > > So we can overwrite the /usr/lib/man-db/man binary with any stuff we > want, and when some user launches man, our code will be run instead of > the original /usr/lib/man-db/man binary. This is the real security > problem. Do "chattr +i /usr/lib/man-db/man*" to prevent this style attacks. Cheers, Foldi Ur ;) . . _ __ __ __ _ . . Foldi Tamas - We Are The Hashmark In The Rootshell - Security Consultant [EMAIL PROTECTED] - PGP: finger:[EMAIL PROTECTED] - (+3630) 221-7477
Re: SuSe / Debian man package format string vulnerability
Martin Schulze <[EMAIL PROTECTED]> writes: > Please tell me what you gain from this. man does not run setuid root/man > but only setgid man. Debian man-db is setuid (not setgid) man[1] in the latest stable and unstable incarnations. Getting uid man is not immediate death, but bad enough. Bug 84128 has been reported (with the trivial patch) a week ago. Please fix it. Footnotes: [1] Unless you've set NOSETGID in /etc/manpath.config ... obvious, isn't it? -- Robbe signature.ng