Re: The Dangers of Allowing Users to Post Images
(replying to two messages at once here) On Thu, 14 Jun 2001, Ben Gollmer wrote: This is not a big deal if you use some validation on images (in PHP at least). Try the function getImageSize(); it will return an array containing the size of the image, as well as the format. If the file specified is not a GIF, JPEG, PNG, or SWF, getImageSize() returns null. Simply verifying it once before you accept the post is not sufficient. It is easy to point to something that is a valid image at the time of the post, but then later change that to be a redirect to a compromising URL. And verifying it every time or uploading the image to be stored on the server can be quite slow or resource intensive, respectively. On Thu, 14 Jun 2001, Richard M. Smith wrote: This is a *very* interesting finding. It seems kind of obvious too. I wonder why no one seems to have run across it before. People have. It just isn't something the world in general cares much about, like most other security vulnerabilities that aren't presented in the way of a particular, high profile, example. A lot of these issues are fairly closely related to cross site scripting related issues that are still rampant on many sites. This same weakness can be exploited from an HTML email message also. The bottom line is that a privileged operation should always require an HTTP POST and never allow a GET. Hmm, I wonder how many Web sites break this rule? At least in Outlook 2002, cookies are disabled in HTML email messages by default. With other email readers, cookies are likely turned on by default. Interesting how cookies continue to bite us in the butt! In this situation, it is third-party cookies that are doing the biting. It isn't cookies that are the problem in particular. The same issues come up regardless of what automatic long-lived login (or even session logins in the case of a message board where the viewing of HTML that results in the browser performing an action with unexpected results) authentication scheme is being used. This can be an issue with cookies. This can be an issue with HTTP basic auth, digest auth, NTLM auth, and even SSL client certificates. All provided they are setup to automatically send the authentication to the server without prompting the user, or that the user accepts any dialog box because that is what they normally do. Actually, using SSL client certificates for strong authentication, given weak UI implementations in today's clients, really scares me. Not because the authentication isn't cryptographically strong, but simply because it is too transparent to the user.
Re: The Dangers of Allowing Users to Post Images
The interesting part of this bug is the fact that its exploitable on some very large sites, and is open to a large number of users. Bulletin boards in particular allow inline image posting, and this is what creates the problem...inline images in a system with cookie based authentication. One system that has been entirely ignored in the conversation thus far is webmail services. Many webmail clients inline HTML parts leaving themselves susceptible to attack. More importantly, systems that provide single sign on to several services through cookie based systems (i.e. a portal) make themselves even more vulnerable. Imagine a portal with webmail. A user receives an inlined image which has it's source URL pointing to some service on that portal's network. That request is now authorized as far as the portal's concerned. Even if the mail application is secure from attack, there's no guarantee that all other services on the portal network are secure. This technique has more issues than just false authentication, though, and could possibly be used towards distributed DoS type attacks. Some forums have 50k+ users, and each user who viewed a certain thread could be accessing some resource intensive script on a remote server. If posted on several highly trafficed forums, the victimized server would go down in no time. The DoS attack is actually much worse than it sounds. Imagine posting an HTML message with an image tag to a newsgroup, instead of a web forum, with heavy traffic (some porn images group). If the image tag had it's source pointing to a common URL, it could quickly bring that site down due to the volume of people downloading the message from the newsgroup and referencing the image tag contained within. Ryan Kennedy
Re: Windows 2k SP2 breaks security fix should reapply
Hmmm.. I took a Win2K Gold (no SP) machine, installed all hotfixes for the OS and IIS5 (including the 01-026 patch). I then installed SP2 and tested for the double decode bug - the machine was not vulnerable. I then compared all the files that came with MS01-026 (IIS5) to the files that were on the system (after the SP2 install and a reboot). I compared fileversion and checksum of each file from the hotfix to the files on the system and found that all the MS01-026 files are still on the box - both before and after SP2 install. SP2 will delete the registry key that is installed by MS01-026 (HKLM\Software\Microsoft\Updates\Windows 2000\SP2\Q293826) - maybe causing hfcheck.exe to report that the hotfix has not been applied, however, all the relevant files are on the system. As far as I can tell, SP2 does not break the patch - and there is no need to re-install the patch if you installed it prior to SP2. --eric At 04:56 PM 6/13/2001 -0500, Colby Rice wrote: SP2 allows the decoding bug to work SP2 breaks the following patch and it should be reinstalled. http://www.microsoft.com/technet/security/bulletin/MS01-026.asp
RE: Windows 2k SP2 breaks security fix should reapply
-BEGIN PGP SIGNED MESSAGE- Since a reminder about MS01-026 and W2K SP2 was allowed through, I thought a more long-term explanation might help folks better. 1. Security hotfixes for W2K are named according to what Service Pack they are *expected* to be included in (there's a more sophisticated explanation, but for all intents and purposes...) Ergo, the MS01-026 fix is named q293826_w2k_sp3_x86_en.exe, indicating that its expected to be included in SP3 (and by extension, definitely not included in SP2). 2. http://www.microsoft.com/technet/security/current.asp?productID=17ser vicePackId=2 gives you a listing of all Security hotfixes that are required post-W2K-SP2. Note how MS01-026 *is* listed there. 3. The HFCheck.wsf, from http://www.microsoft.com/Downloads/Release.asp?ReleaseID=24168 also identifies what might need to be re-applied after a Service Pack installation. Finally, for anyone who wonders why, after installing the latest Service Pack, they'd then have to re-apply Security hotfixes that were released prior to the Service Pack...the answer's pretty simple and hopefully one that everyone appreciates. Both Service Packs and Security hotfixes go through regression testing prior to release. This is a fervent attempt, since NT 4.0 SP2 to avoid the problems associated with patches and compatibility. The testing for Service Packs is more extensive than that for Security fixes, largely due to the number of components that need to be tested in a Service Pack. As a result, the date that Service Pack distributions are frozen (meaning no new code can be added) comes some time (usually 4-6 weeks, sometimes longer) prior to its release. During that time Security fixes are created and made available to the public since they're important, but not put into the frozen Service Pack distribution because that would delay its (the SPs) release. So always double-check, using one of the three methods mentioned above, whether or not you need to re-apply a Security hotfix after a Service Pack installation. There are almost always going to be at least one or two. Cheers, Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.2 iQCVAwUBOypkkhBh2Kw/l7p5AQERngP+ImBJ8hSZ3kFXN0RrND+PMP9OrkA6Fdc4 TLTOA+SfmJtlVNfrN6pV8JEkjPeDMThJCUXSOksfBSpjRB2DpnJmrwHBfV8zLJeq Tg6Rxjt6urJVXTCklvTIgRXWrBvQIu8898t+fSGvmcIcQMD1SgysemmNJ+K1feQP 1dVMvt8oV4E= =HDh1 -END PGP SIGNATURE-
Re: Windows 2k SP2 breaks security fix should reapply
From: Colby Rice [EMAIL PROTECTED] SP2 allows the decoding bug to work SP2 breaks the following patch and it should be reinstalled. http://www.microsoft.com/technet/security/current.asp?productID=17servicePackId =2 lists 3 patches you should apply after SP2, one of which is http://www.microsoft.com/technet/security/bulletin/MS01-026.asp Rick Up
Re: Rxvt vulnerability
On Fri, 15 Jun 2001, Samuel Dralet wrote: Vulnerable system : rxvt 2.6.2 on Debian Linux 2.2 I cannot see that this vulnerability is Debian specific, while it might seem like that to someone just browsing bugtraq mails for something that affects his systems. Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: OpenBSD 2.9,2.8 local root compromise
On Fri, Jun 15, 2001 at 11:27:23AM -0400, Tony Lambiris wrote: AFAIK its been fixed in -current, and it _will_ be in errata shortly.. in the meantime, there is a hotfix for the code itself, read the mailing lists.. OR in /etc/fstab, make /tmp nosuid and noexec, then mount -u /tmp (you did make tmp a seperate partition.. didn tyou?) There are about a 1000 other places on a machine people can stick the file to be executed. The actual problem is not tmp-related, the provided exploit just happens to use /tmp. Making /tmp nosuid and noexec will only stop the kiddo's that are too stupid to change the exploit to work on such machines. Greetz, Peter -- Against Free Sex! http://www.dataloss.nl/Megahard_en.html
Re[2]: The Dangers of Allowing Users to Post Images
Following upon the letter of Friday, June 15, 2001: RMS This is a *very* interesting finding. It seems kind of obvious RMS too. I wonder why no one seems to have run across it before. It reminds me Client Side Trojans thread. Also similar problem with authorization have been described at tools-on.net (Web and your privacy section). The problem is that once authorised you don't have to enter password again if you are redirected to some form inside protected (via .htaccess, cookie, etc) area. Best regards, Alexander --- MCP+I, MCSE, BrainBench certificates http://leader.ru http://tools-on.net ---
Re: The Dangers of Allowing Users to Post Images
On Thu, Jun 14, 2001 at 09:12:05PM -0400, Chris Lambert wrote: would it be safe to check that if a referer is present, it contains the sites' domain name, Yes. but if it isn't, it most likely wouldn't have been referenced in an img tag or submitted via JavaScript? You mean it's safe/legitimate? No. Client-pull META tags generate requests without Referers, as I've said a couple times in this thread, and in previous Bugtraq discussions, too. :-) If you don't see the Referer, you can't trust the request. Your best bet is to lock out users who won't pass Referers. Or at least, when you initialize a user session, note if they seem to be passing Referer values. If they are, then you should certainly reject any later request that seems to be theirs, but lacks a Referer header. Note that in some cases, MSIE won't send a Referer if the TARGET of a link is a different window, or that used to be the case. This is messy. -Peter
Re: The Dangers of Allowing Users to Post Images
On Thu, Jun 14, 2001 at 08:34:33PM +0200, Sverre H. Huseby wrote: A possible solution (for web developers) seems to be to make sure the user has been given an offer to do something before letting him do it: Give each user a unique ticket, and for each action on a web page, bind this ticket to it. Examples on URL an form follow: http://vote.com/vote.cgi?answer=1ticket=9871398747 input type=hidden name=ticket value=9871398747 When the request comes in, check if the incoming ticket matches the one stored in this user's session. If it does, this particular user was given the offer by our server, and not by anyone else. To spoof this system, someone would have to guess or otherwise find out what ticket value the victim was given by the server. To make it harder to find the ticket value given to a user, you could give the user many tickets, one for each possible action. This solution would require a ticket pool in the user's session. I've implemented the latter solution in both PHP and Java. Let me know if you would like some code. (It's not at all hard to implement, of course.) Sverre. My company implemented this but went one more step. They created a file that had (IP, ticket) pairs. The ticket was passed around in URLs, but wasn't valid unless it came from the specific IP. To pretend to be someone else, one would have to spoof their IP and guess the value of their (10 hour life-cycle) ticket. We did this, originally, because we wanted to support web browsers that didn't use cookies. The file was, actually, more like (IP, ticket, cookie-type-options-and-settings). It worked well for us. Sincerely, Tim Nowaczyk Truth
Re: Rxvt vulnerability
Previously Samuel Dralet wrote: RXVT Vulnerability Date : 2001/06/05 Vulnerable system : rxvt 2.6.2 on Debian Linux 2.2 [.. snip snip ..] Status vendor : contacted two weeks ago but no response. I'm curious who you contacted; from what I can see you did not contact Debian but yet you explicitly mention that Debian is vulnerable and claim you contacted the vendor two weeks ago. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
patch for exec+ptrace security hole available (fwd)
-- Forwarded message -- Date: Sat, 16 Jun 2001 11:08:53 -0400 (EDT) From: Aaron Campbell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: patch for exec+ptrace security hole available A race condition exists in the kernel execve(2) implementation that opens a small window of vulnerability for a non-privileged user to ptrace(2) attach to a suid/sgid process. 2.8 patch: ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.8/common/030_kernexec.patch 2.9 patch: ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.9/common/007_kernexec.patch The fix has also been committed to the 2.8 and 2.9 stable branches. The bug was found by Georgi Guninski; Art Grabowski came up with a fix. Vagner sacramento
[SECURITY] [DSA-060-1] fetchmail buffer overflow
-BEGIN PGP SIGNED MESSAGE- - Debian Security Advisory DSA-060-1 [EMAIL PROTECTED] http://www.debian.org/security/ Wichert Akkerman June 16, 2001 - Package: fetchmail Problem type : buffer overflow Debian-specific: no Wolfram Kleff found a problem in fetchmail: it would crash when processing emails with extremely long headers. The problem was a buffer overflow in the header parser which could be exploited. This has been fixed in version 5.3.3-1.3, and we recommend that you upgrade your fetchmail package immediately. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. Debian GNU/Linux 2.2 alias potato - - Potato was released for alpha, arm, i386, m68k, powerpc and sparc. Source archives: http://security.debian.org/dists/stable/updates/main/source/fetchmail_5.3.3-1.2.diff.gz MD5 checksum: fbf35f3be1f9d8bee5d08a4a9e4d1a23 http://security.debian.org/dists/stable/updates/main/source/fetchmail_5.3.3-1.2.dsc MD5 checksum: b2d5b8e11f7943a167dddbb4b1a0ad1b http://security.debian.org/dists/stable/updates/main/source/fetchmail_5.3.3.orig.tar.gz MD5 checksum: d2cffc4594ec2d36db6681b800f25e2a Architecture independent archives: http://security.debian.org/dists/stable/updates/main/binary-all/fetchmailconf_5.3.3-1.2_all.deb MD5 checksum: 7501327bf217b36540a0b6288362d40a Alpha architecture: http://security.debian.org/dists/stable/updates/main/binary-alpha/fetchmail_5.3.3-1.2_alpha.deb MD5 checksum: 9176d223e830d64f648c8374aec45e73 ARM architecture: http://security.debian.org/dists/stable/updates/main/binary-arm/fetchmail_5.3.3-1.2_arm.deb MD5 checksum: ca4c1e5e8aba63badb08e26459608f1a Intel IA-32 architecture: http://security.debian.org/dists/stable/updates/main/binary-i386/fetchmail_5.3.3-1.2_i386.deb MD5 checksum: d985cf57911ad2b891ed6c92c50de317 Motorola 680x0 architecture: http://security.debian.org/dists/stable/updates/main/binary-m68k/fetchmail_5.3.3-1.2_m68k.deb MD5 checksum: 3921efe505b3eb72a1cff41a11da2d5c PowerPC architecture: http://security.debian.org/dists/stable/updates/main/binary-powerpc/fetchmail_5.3.3-1.2_powerpc.deb MD5 checksum: d7828e3c6ce890e86fb65316e4b78768 Sun Sparc architecture: http://security.debian.org/dists/stable/updates/main/binary-sparc/fetchmail_5.3.3-1.2_sparc.deb MD5 checksum: baf11fea7d050cbb5d9f00f95a16e0f7 These packages will be moved into the stable distribution on its next revision. For not yet released architectures please refer to the appropriate directory ftp://ftp.debian.org/debian/dists/sid/binary-$arch/ . - -- - apt-get: deb http://security.debian.org/ stable/updates main dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQB1AwUBOyuGIqjZR/ntlUftAQHW7AMAgngWe6rTqRKX1w4tBVFi7XrVQs5TOcHb akEBX1ZVQ4GYYXJ3fom3TnS+hbOqn3q/1DhGhnf++hMqj98CoysyUR2EzXQRHIE7 oRSdeZwsIpMN1raVAVvqhdE6UOStxE3e =NmIw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Dangers of Allowing Users to Post Images (fwd)
At 10:29 AM 6/15/01 -0400, Shafik Yaghmour wrote: Yeah this is kind'a old if you have been developing sites for a while, you also need to consider that someone can also do this off the site as well. So if they have the ability to link to a site from your site they can get people to go to that site and then do the post from that site and this defeats this protection. Therefore, although, everyone disparages HTTP_REFERER checking, in this case it will protect the innocent user. I agree, it's an old problem (well as long as the web has been around :) ) and there are various ways to try to solve it depending on the circumstances. I did post to vuln-dev regarding this last year - asking for other people's ideas on how they solve it (Subject: How to prevent malicious linking/posting to webapps?). For critical areas you could also force the user to enter their password or something similar which will also prevent this attack from working. This does work reasonably well, but I'd reserve this for very critical areas only (Are you sure you want to buy 10 million shares of Company X). This is used in at least one local bank. If you use this too often the users get annoyed, but so far they like it when it's used judiciously. For less critical but still important things, I've been using confirmation pages and checksums. Basically, the cgi parameters are passed to the app. If there's no confirmation value, a confirmation value is generated using a cryptographic hash of the active session's random string, the relevant cgi parameters, and a secret, then a confirmation form is displayed with hidden fields containing those parameters. If the user clicks yes, the values are resubmitted along with the new valid confirmation value. If the user clicks no, the user is returned to the calling page using the decoded stack cgi parameter (if present) . If an invalid confirmation value is provided, the app logs the attempt and the HTTP-Referer, and displays the confirmation form with a warning as well. Only if the confirmation value is correct will the action take place. One problem of linking confirmation values to the session is that if the user times out the forms have to be reloaded, regenerated and some info might be lost. For example, if user is typing out a message in a form containing the confirmation value but times out, if the user clicks submit, the user has to log in again. If it weren't for the confirmation value being tied to the session, the user's data could be submitted automatically after a successful login. I still prefer it being tied to the session tho, because that reduces further the chance of replay attacks - once the session is invalid, you can't use that confirmation value anymore, even if it's for the same action and same objects. Regards, Link.
[SECURITY] [DSA-061-1] multiple gnupg problems
-BEGIN PGP SIGNED MESSAGE- - Debian Security Advisory DSA-061-1 [EMAIL PROTECTED] http://www.debian.org/security/ Wichert Akkerman June 16, 2001 - Package: gnupg Problem type : printf format attack web of trust pollution Debian-specific: no The version of GnuPG (GNU Privacy Guard, an OpenPGP implementation) as distributed in Debian GNU/Linux 2.2 suffers from two problems: fish stiqz reported on bugtraq that there was a printf format problem in the do_get() function: it printed a prompt which included the filename that was being decrypted without checking for possible printf format attacks. This could be exploited by tricking someone into decrypting a file with a specially crafted filename. The second bug is related to importing secret keys: when gnupg imported a secret key it would immediately make the associated public key fully trusted which changes your web of trust without asking for a confirmation. To fix this you now need a special option to import a secret key. Both problems have been fixed in version 1.0.6-0potato1. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. Debian GNU/Linux 2.2 alias potato - - Potato was released for alpha, arm, i386, m68k, powerpc and sparc. Source archives: http://security.debian.org/dists/stable/updates/main/source/gnupg_1.0.6-0potato1.diff.gz MD5 checksum: 4928a4a589c11cadea852347d23edf5a http://security.debian.org/dists/stable/updates/main/source/gnupg_1.0.6-0potato1.dsc MD5 checksum: e6057febed9106dfc9f77fb61fbd0ca4 http://security.debian.org/dists/stable/updates/main/source/gnupg_1.0.6.orig.tar.gz MD5 checksum: 7c319a9e5e70ad9bc3bf0d7b5008a508 Alpha architecture: http://security.debian.org/dists/stable/updates/main/binary-alpha/gnupg_1.0.6-0potato1_alpha.deb MD5 checksum: 76c3f586b91bba1c69a6fb6ea93a2fbd ARM architecture: http://security.debian.org/dists/stable/updates/main/binary-arm/gnupg_1.0.6-0potato1_arm.deb MD5 checksum: 84a47897a38f44b07180e9a9ec16ab49 Intel IA-32 architecture: http://security.debian.org/dists/stable/updates/main/binary-i386/gnupg_1.0.6-0potato1_i386.deb MD5 checksum: d3a91ccc9d1c951b80afe17e59190db3 Motorola 680x0 architecture: http://security.debian.org/dists/stable/updates/main/binary-m68k/gnupg_1.0.6-0potato1_m68k.deb MD5 checksum: 6b12f23b3c3840574af826db147ed9cd PowerPC architecture: http://security.debian.org/dists/stable/updates/main/binary-powerpc/gnupg_1.0.6-0potato1_powerpc.deb MD5 checksum: a5a9bffdce2abf112c2058097f48f784 Sun Sparc architecture: http://security.debian.org/dists/stable/updates/main/binary-sparc/gnupg_1.0.6-0potato1_sparc.deb MD5 checksum: 487c0d605ff5b3fdce2212d4e9c07bf0 These packages will be moved into the stable distribution on its next revision. For not yet released architectures please refer to the appropriate directory ftp://ftp.debian.org/debian/dists/sid/binary-$arch/ . - -- - apt-get: deb http://security.debian.org/ stable/updates main dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQB1AwUBOyud7KjZR/ntlUftAQGn2AL9EYSvg7znskCLx5eY/mOjz3QQnDSEFXlj V8GSUZaSVpm5kNcb19pZIgfJEZe60CQIDesdnb8M7YaKyT65sFha+8yJvaVWsy+H 5Mp/lBEW8B3qvNYtScF6/XoXKpymOD2E =918n -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
