[Full-disclosure] Compromising pictures of Microsoft Internet Explorer!
Synopsis:
-
Well, not really. Instead, at the risk of boring you to death, I'd like
to report on a casual 30-minute experiment I've conducted of recent.
This experiment resulted in identifying a potential remote code
execution path in Microsoft Internet Explorer, plus some other bugs, and
should be a good starting point for further testing of other browsers or
similar programs.
Discussion:
---
You might remember the 'mangleme' affair, where various browsers were
subjected by yours truly to a trivially constructed malformed HTML
crash-course - all that in order to find exploitable input handling flaws.
Back then, MSIE performed admirably compared to other browsers (although
did not escape some embarassment when [EMAIL PROTECTED] found the
infamous IFRAME bug that way):
http://lcamtuf.coredump.cx/mangleme/gallery/
Of recent, I decided to try something completely different and radically
new, without having to do any actual work. I used the same META REFRESH
auto-test framework to check for image decompression and parsing flaws
(JPEG, GIF, PNG), as opposed to making fun of HTML renderers.
I used a simple index.cgi script (attached, though hardly noteworthy) to
dynamically generate a page that references ten just as dynamically
created images. These images were prepared by running a test set of
pictures (some regular ones, and several pathological cases created with
ImageMagick) through a slightly modified version of my old afx utility.
Surprisingly, it is MSIE and its proprietary JPEG decoder (apparently
not shared with other Windows components?) that performed embarassingly
poor this time. Results below.
Vulnerability examples:
---
NOTE #1: As with mangleme, this list of problems is most certainly NOT
exhaustive, and performing longer tests or improving the technique
would most likely result in additional findings.
Several MSIE crash sample files from that 30-minute run are available
at:
http://lcamtuf.coredump.cx/crash/
Note that these may produce different results depending on program
versions, plugins and configuration. Tested with WinXP Pro PL
2600.xpsp2.050301-1526 SP1, MSIE PL 6.0.2800.1106, up-to-date.
mov_fencepost.jpg - on most platforms, causes a crash due to mov
destination fencepost error after going past allocated memory, or
after accessing a bogus address such as 0x27272727. The destination
address appears to be controllable (i.e. changing the file or
displaying other data before or along with this image alters it).
My bets are that this is exploitable for remote execution.
cmp_fencepost.jpg - here, causes a crash due to a very similar cmp
fencepost (no write). Not necessarily exploitable for remote code
execution, unless code execution path can be affected later on.
oom_dos.jpg - usually causes a OOM crash. Less interesting, unless
you like to punish people who borrow your pictures for their blogs.
random.jpg - causes mov fencepost of CPU consumption + crash. Didn't
investigate in much detail.
NOTE #2: MSIE comes with no sources, and reverse engineering is naughty.
I didn't examine the renderer to see what went wrong; I see unbounded,
user-dependent memory accesses, and that spells trouble.
Vendor notification:
It is my experience that reporting and discussing security problems with
Microsoft is a needlessly lengthy process that puts too much burden and
effort on the researcher's end, especially if you just have a crash
case, not a working exploit; hence, they did not get an advance notice.
Bonus (OT)
--
Since piggyback request smuggling and fooling proxies and filters is a
popular new pastime, some of you might find it entertaining to have a
look at how various applications differ in handling duplicate instances
of HTTP/SMTP message/NNTP headers that are, in common perception,
supposed to occur only once.
--
- bash$ :(){ :|:};: --
Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
--- 2005-07-14 00:29 --
http://lcamtuf.coredump.cx/silence/#!/bin/bash
echo Content-Type: text/html
echo
ID=timg-$$-$RANDOM-$RANDOM
rm -f timg-* AFX.log
cat _EOF_
HTML
HEAD
META HTTP-EQUIV=Refresh content=0;URL=/
/HEAD
BODY
_EOF_
CNT=0
for i in img/*; do
CNT=$[CNT+1]
FNAM=$ID-$CNT
EXT=`echo $i | cut -d. -f2`
./afx-loc -p 1 -i 100 -m RANDOM -s 6 $i 2$FNAM.$EXT AFX.log
echo Test $CNT - IMG SRC=\$FNAM.$EXT\BR
done
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Compromising pictures of Microsoft Internet Explorer!
On Sat, 16 Jul 2005, [EMAIL PROTECTED] wrote: I do not mean to flame you, but you are an irresponsible disgrace to the hacking community. You do mean to flame me, apparently, and constructing sentences this way makes them unintentionally funny. Pretty much like saying Sir, with all due respect, you are a filthy low-life scum. Do you not care about the customer? I do security research for fun. Because I mean no harm, I usually take efforts to notify vendors in advance, or release advisories that are of more value to those who want to fix problems, than to those exploiting them. The latter is the case here. The former isn't, because I had a poor experience with the vendor. That about sums up my philosophy. No, I do not particularly care about Microsoft customers - Microsoft should. I firmly believe that you are decieving us when you say you had a hard time with [EMAIL PROTECTED]; in fact, I don't even think that you have ever once in your life reported a vulnerability to them responsibly. I did, a couple of times. In fact, if you had gone through the effort of actually using a search engine, you would find out that I did coordinate some stuff with them. It is my experience, however, that they require you to: 1) Prove them beyond any doubt that a particular issue is exploitable; they seem to be doing this not to fully comprehend the threat, but to see if you are not absolutely certain on all the phases of the attack, and then exploit the benefit of doubt. You need to either: a) Debug their code in great detail and explain the execution path that leads to this, along with an explanation why overwriting an arbitrary byte in memory might cause problems, b) Provide an exploit that works for them (and be sure it also works on SP2, or they will come up with ridiculous recommendations - look up the Bofra IFRAME stuff), c) Find a bug that is so patently obvious it hurts (stack buffer overflow, for example). If you fail to do that, they - in my opinion - use this to downplay the issue. Look up how many times Microsoft considered something to be less critical than the researcher would believe it to be - and were proved wrong by having exploits developed later on. How often does the opposite happen? 2) Wait forever for them to release a patch. Frankly, I see no reason why a multi-billion dollar company with so many customers at risk would need to take more than a week or two to develop, test and release trivial fixes. 3) Most insidious - if you happen to work for a company that depends on Microsoft in one way or another (for example, to recommend, bundle, or just not break your products), when you disagree with them, I seem to recall they would take an opportunity to give you a friendly reminder it would be unwise not to agree in your advisory. All this, combined with the general disregard for the customer who does not immediately vote with his money (lacking viable options makes this hard; if you're looking for real-world examples, how long it took Microsoft to release goddamn patches after Bofra went loose?!), makes me somewhat less interested in investing several weeks into this type of cooperation. /mz http://lcamtuf.coredump.cx/silence/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Remote overflow in MSIE script action handlers (mshtml.dll)
Good morning, This might not come as a surprise, but there appears to be a *very* interesting and apparently very much exploitable overflow in Microsoft Internet Explorer (mshtml.dll). This vulnerability can be triggered by specifying more than a couple thousand script action handlers (such as onLoad, onMouseMove, etc) for any single HTML tag. Due to a programming error, MSIE will then attempt to write memory array out of bounds, at an offset corresponding to the ID of the script action handler multiplied by 4 (due to 32-bit address clipping, the result is a small positive integer). The list of IDs can be found on the Web, and is as follows (values in parentheses = resulting offsets): onhelp = 0x8001177d (+0x45df4) onclick = 0x80011778 (+0x45de0) ondblclick = 0x80011779 (+0x45de4) onkeyup = 0x80011776 (+0x45dd8) onkeydown = 0x80011775 (+0x45dd4) onkeypress = 0x80011777 (+0x45ddc) onmouseup = 0x80011773 (+0x45dcc) onmousedown = 0x80011772 (+0x45dc8) onmousemove = 0x80011774 (+0x45dd0) onmouseout = 0x80011771 (+0x45dc4) onmouseover = 0x80011770 (+0x45dc0) onreadystatechange = 0x80011789 (+0x45e24) onafterupdate = 0x80011786 (+0x45e18) onrowexit = 0x80011782 (+0x45e08) onrowenter = 0x80011783 (+0x45e0c) ondragstart = 0x80011793 (+0x45e4c) onselectstart = 0x80011795 (+0x45e54) What happens next depends on the structure of the page in which the malicious tag is embedded, as well as previously visited page and previously initialized extensions (all these factors can be controlled by the attacker). When the offending page contains no additional elements, and the user is not redirected from elsewhere, the browser will typically crash immediately, because there is no allocated memory at the resulting offset. In all other cases, crashes will typically occur later, due to attempted use of unrelated but corrupted in-memory buffers -for example, when the user attempts to leave or reload the page. Another good example is coming from a page that contains Macromedia Flash - this usually causes the Flash plugin itself to choke on corrupted memory on cleanup. For non-believers, there's a short but fiery demonstration page available at http://lcamtuf.coredump.cx/iedie.html (yes, it will probably crash your browser). Tested on MSIE 6.0.2900.2180.xpsp2.040806-1825 on Windows XP SP2. As far as I can tell, other browser makes (Firefox, Opera) are not susceptible to this attack. I eagerly await due reprimend from Microsoft for not disclosing this vulnerability in a manner that benefits them most, not passing start, not collecting $200 (from iDefense?). Regards, /mz http://lcamtuf.coredump.cx/silence/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: Remote overflow in MSIE script action handlers (mshtml.dll)
On Thu, 16 Mar 2006, Daniel Bonekeeper wrote: BTW, tested the POC on MSIE (File Version = 6.00.2900.2180 (xpsp_sp2_rtm.040803-2158)) with mshtml.dll (6.00.2900.2802 (xpsp_sp2_gdr.051123-1230)) and it didn't worked. Daniel followed up with me in private and confirmed that the PoC *did* work for him when he followed certain additional instructions: because the attack depends on memory layout and usage, to get consistent results, be sure to close *all* MSIE windows, then go to Start - Run... and type: iexplore http://lcamtuf.coredump.cx/iedie.html That should crash the browser immediately, because there are no other buffers nearby to absorb the initial fencepost. Still, if no dice, try hitting 'Reload' a couple of times. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] FrSIRT Puts Exploits up for Sale
On Fri, 17 Mar 2006 [EMAIL PROTECTED] wrote: If you puplish something without a license it is OPEN DOMAIN That means people can use it, modify it, sell it... That's nonsense. If I publish a book or a photo or a newspaper article without a lengthy license attached, you can copy it at will, too? The requirement of a license or a copyright notice is a long-running myth - it is good to have these, but they are not a legal requirement. All your private writing, recording, coding, photography, etc is protected by copyright, period. Unless you explicitly allow others to use your work, it is not legal to do so, with certain specific common-sense exceptions (fair use clauses vary from place to place, but usually involve applications that are either entirely non-commercial, or benefit the society). In some places, it can be successfully argued that by deciding to release information during a press conference, on a mailing list, etc, grants some entities an implicit permission to do certain things with that information, but it's generally rather tricky (and subject to individual interpretation by the court). In any case, this just means that because you posted to a mailing list, the server can reasonably process and store your message, and distribute it to the intended audience. It does not necessarily mean that others can grab it for unrelated purposes and sell it to third parties. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: Remote overflow in MSIE script action handlers (mshtml.dll)
On Fri, 17 Mar 2006, Hariharan wrote: This does not repro on IE7 though It generally does, according to tests by a couple of folks. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: Remote overflow in MSIE script action handlers (mshtml.dll)
On Thu, 16 Mar 2006, Michal Zalewski wrote: This might not come as a surprise, but there appears to be a *very* interesting and apparently very much exploitable overflow in Microsoft Internet Explorer (mshtml.dll). I'd like to make a self-serving statement in response to dozens of people who pointed out that this month, iDefense pays $10,000 per any vulnerability that would result in a Microsoft security advisory rated critical... YES, I HAVE THIS KNOWLEDGE. I simply do not subscribe to that way of making money. It might be that I'm insane or dumb, but it feels good. Regards, /mz http://lcamtuf.coredump.cx/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [HV-PAPER] Anti-Phishing Tips You Should Not Follow
On Fri, 31 Mar 2006 [EMAIL PROTECTED] wrote: If the website then presents you with the Logon failed page, you are possibly on a legitimate website, so you may proceed with logging in using your correct credentials. If it gets you right through - it is definitely a phishing attempt. Note to self: design my next phishing website to always display logon failed. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [HV-PAPER] Anti-Phishing Tips You Should Not Follow
On Fri, 31 Mar 2006, [ISO-8859-1] Marcos Agüero wrote: Note to self: design my next phishing website to always display logon failed. Just as most of the phishing sites already do. Forgive me my ignorance; to my defense, I usually don't enter valid credentials on phishing sites. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [HV-PAPER] Anti-Phishing Tips You Should Not Follow
On Fri, 31 Mar 2006, Jasper Bryant-Greene wrote: Just as most of the phishing sites already do. Really? I thought they somehow magically knew enough about you to sign you in properly and display all the correct details ;) No, but the reasonable practice would be not to alert the customer (and have him possibly, say, panic and call the bank in question) - but rather, display something along the lines of Thank you for successfully verifying your Frob Mutual account data. Bye. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] MSIE (mshtml.dll) OBJECT tag vulnerability
On Sun, 23 Apr 2006, Paul Nickerson wrote: I don't approve of your disclosure practices, Mr. Zalewski Then follow your own, Paul. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] MSIE (mshtml.dll) OBJECT tag vulnerability
On Wed, 26 Apr 2006, Tim Bilbro wrote: You do a disservice to all IT shops by announcing these vulnerabilities before contacting the vendor. How were you impacted? What were your damages? The only loss that could possibly occur to you or your company was the time you wasted to write this rant, and the subsequent damage to your reputation if you turn this into a fully-fledged and entirely counterproductive flamewar. In case you didn't notice, I *do* work with vendors; not because I believe that a particular disclosure policy is morally superior, but because I chose to. Microsoft is a rare exception to this rule, for a couple of reasons. Why, you ask? It is my unsubstantiated opinion that they consistently, unreasonably delay disclosure of problems; that they don't participate in the vulnerability research community in any way, while trying to impose artbitrary standards and punish certain researchers (often employing borderline extortion practices); and that they routinely communicate false pretenses when dealing with the media regarding known security issues. I can't make a difference, but I'm one of the few folks who can still afford this small degree of civil disobedience. I am sure it would not generate as much web traffic to your site Oh, tragic. Generating traffic to my ad-free webpage is precisely why I spend hours researching problems. Now you see why I couldn't handle it any other way. Would you go around town checking which stores are unlocked at night and then publish the list in the news before letting the shop owners know? I see that you took the bad analogy 101 course in the logical fallacy class? /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] MSIE (mshtml.dll) OBJECT tag vulnerability
On Wed, 26 Apr 2006, Larry Seltzer wrote: It wasn't my analogy. I was criticizing it. Larry, Sorry if I criticized you undeservedly, then. That exchange of mails was unclear at best, however. In this particular branch of this (silly) thread: 1) Tim Bilbro blasted me for disclosing a problem and compared this to checking at night for open store doors. 2) Bob replied and criticized Tim saying that the analogy is flawed, and that it can be compared, at best, to informing the public about car manufacturing faults and recalls. 3) You replied to Bob's (not Tim's!) mail and said that it's a lousy analogy and mentioned exploiting flaws to drive it off in a way that can be, at best, read in a couple of ways. It was only fair to assume that you meant to blast a (generally favorable) analogy brought up by Bob. If that wasn't your intention, OK, but it wasn't nearly as obvious as you'd probably want it to be. I'll assume you're as proficient in english as in morals Uh-oh. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] MSIE (mshtml.dll) OBJECT tag vulnerability
On Thu, 27 Apr 2006, Larry Seltzer wrote: More on this in my column later this morning at http://security.eweek.com/ Just who does he think he is? [...] Zalewski may think he's some sort of hero disclosing this information, but his is the act of a vandal. If it turns out that the bug is exploitable and abused before it's patched, then perhaps he'll be proud to be remembered for that. Ho boy. Yup. Now that you foiled that plan, at least I can be proud of being featured in your op-ed as an egomaniac bent on hurting people by providing them with information. That's almost as good. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] MSIE (mshtml.dll) OBJECT tag vulnerability
On Thu, 27 Apr 2006, Tim Bilbro wrote: There is no question that vendors, particulary Microsoft, have a history of neglect in this area, and folks have a right to be angry with them. I'm not angry with Microsoft. It's just a company, and not a particularly evil one. I simply believe that there is no longer a reason to be nice to MSRC and go to the extremes to protect Microsoft's customers. Although I'm willing to cooperate with friendly vendors in order to minimize eventual damage (you both should do some background research, really), it is ultimately that vendor's duty to care for their customers, and take responsibility for own mistakes. If customers are repeatedly burned by vendor's negligent coding practices, the vendor ought to be pressured into making security a priority, and collaborating with the infosec community to ENCOURAGE responsible disclosure, not DEMAND it and issue reprimands to those who disobey them. It is not my job to withold information on product flaws at all costs, or to repeatedly bug the vendor for 3-6 months or more to fix a problem. A bonus fact: I'm not planting bugs in their software, either. Why didn't I even try, you say? Past experiences of numerous researchers aside, consider this: Microsoft takes 3-6 months to fix critical but non-public vulnerabilities in their flagship software (some of these flaws must've been independently discovered by the rogues, hence putting customers at great risk, or at best taking chances). This is not a reasonable timeframe, compared to industry averages. Yet, they only take 2-4 weeks to fix publicly disclosed bugs - thus making software safer, sooner. Unfortunately, full disclosure doesn't hurt them as much as it hurts the information security community as a whole. You're making an argument for no disclosure and no accountability... ...by saying that it sucks for infosec workers to have to do some actual work, rush workarounds, write IDS signatures - based not on guesses, but on useful information... ...and you're making this argument On a full disclosure mailing list. Bravo. Now if you excuse me... I feel as if I'm being trolled. Have you guys considered pursuing a Usenet career? /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] MSIE (mshtml.dll) OBJECT tag vulnerability
On Thu, 27 Apr 2006, Brian Eaton wrote: Please note that I ask this out of curiousity, and not in an attempt to be critical. Why not give MSRC a head start of one week? Because, among other things I've already mentioned, it will in no way affect when they're going to release a patch. Their official policy is to stick to a weird schedule. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Five Ways to Screw Up SSL
On Sun, 21 May 2006, Ginsu Rabbit wrote: You claim that this is a practical checklist for five very common problems with SSL deployments... but to me, they seem to be arbitrarily chosen, partly inaccurate (see #3), and otherwise very much random. SSL Mistake #1 - Trusting too many Certificate Authorities Most SSL servers do not have this problem [...] So why is it #1? SSL Mistake #2 - Assuming a signed certificate is the right certificate I don't understand what you're trying to say here: it seems to me that you're suggesting that allowing all users with a valid certificate the same privileges is a bad idea. Probably, but this has little to do with certificates or SSL - the same may be true for passwords or any other scheme. SSL Mistake #3 - Falling back to TCP A surprising number of SSL client applications use the following logic: - Try to make an SSL connection. - If the SSL connection succeeds, great! - Otherwise, the administrator probably made a mistake. Go ahead and use a TCP connection instead. [...] For some examples of why falling back to TCP is not a good idea, please search the web for promiscuous mode, DNS cache poisoning, ARP cache poisoning, or IP spoofing. The internet is not a friendly place. SSL was invented for a reason. You are very, very seriously confused about the relation between SSL, TCP, and just about everything else. SSL Mistake #4 - Allowing insecure SSL ciphers This is not a paper about cryptography, and I am not going to tell you which SSL ciphers are safe. Kind of defeats the purpose of a checklist, then? /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Security speakers are often very good book writers
On Thu, 25 May 2006, [EMAIL PROTECTED] wrote: Security speakers are often very good book writers. Another little known fact is that many excellent books were written by people who own a dog and do not regularly consume excessive amounts of lettuce. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] SSL VPNs and security
Web VPN or SSL VPN is a term used to denote methods for accessing company's internal applications with a bare WWW browser, with the use of browser-based SSO authentication and SSL tunneling. As opposed to IPSec, no additional software or configuration is required, and hence, corporate users can use pretty much any computer they can put their hands on. [ Yes, this is a very bad idea, but often also a perceived business necessity. To counter the risk, some SSL VPN solutions may perform client-side security checks with the aid of an applet or control not marked as safe. This is, of course, a silly and bypassable design, and has a side effect of teaching the user to click yes on scripting safety prompts. But I digress... ] [ These solutions are sold, among others, by Juniper, Nortel, Nokia, Cisco. The following observations are based on Cisco Web VPN (and your mileage with this and other vendors may vary). In their most basic operating mode, SSL VPN systems simply act as a HTTPS authentication and authorization proxy that relies on session cookies, and a URI-based request rewriting and forwarding engine. Such a configuration enables the user to access any HTTP or HTTPS based Intranet applications; web-based clients for some other protocols are also sometimes included. [ With the help of various controls and applets again not marked as safe, SSL VPNs can also forward local TCP ports through that tunnel, if unsupported network protocols need to be used. ] A good example: let's say there's an user who wishes to access his corporate Outlook Web Access interface from a remote location. The usual URL for the intranet service is: http://owa/exchange/lcamtuf/inbox To access it over the Internet, that fellow needs to navigate to https://webvpn.foocorp.com/, enter his credentials, collect a session cookie, and then go to (or be redirected to) something along the lines of: https://webvpn.foocorp.com/http/0/owa/exchange/lcamtuf/inbox ...which, if the cookie validates, would be translated to the original URL and allowed to go through, with SSL VPN acting as a proxy. Commercial SSL VPNs are a fairly recent technology that has a considerable appeal to various corporations. Because of its novelty, however, in a typical setup it may be subject to several serious security flaws, unless very carefully designed. Possibly the most important problem is that web VPNs break the customary browser security model that relies on domain name separation for the purpose of restricting access to cookies and other objects. Browsers generally allow foo.com to interact with own cookies or windows, but prevent the site from accessing resources related to bar.com. Yet through SSL VPN, they all may look the same: https://webvpn.foocorp.com/http/0/foo.com/serious_work https://webvpn.foocorp.com/http/0/bar.com/fun_and_games Because of this design, all pages displayed through a Web VPN interface are lumped together. Whenever a page (or just a HTML fragment) that can be controlled by the attacker is displayed by *any* of the applications behind Web VPN, Javascript can access: - Web VPN session cookie, which can be then passed to the attacker. This is equivalent to the attacker obtaining access to all protected systems and compromising Web VPN altogether. The threat could be mitigated by associating the cookie with client's IP, but such an approach is not always implemented, and is impractical with AOL and the likes. - Application cookies set by other applications. If passed to the browser (as some SSL VPNs do), these cookies are separated by the use of path parameter alone, which does not necessarily establish a browser security domain boundary. This is equivalent to the attacker obtaining user credentials to these applications. Some commonly used corporate applications may indeed serve attacker-supplied contents, making these attacks virtually inherent to most SSL VPN deployments: - Various web mail systems, such as Outlook Web Access (OWA), may serve HTML attachments and other documents received from the Internet without providing an adequate browser warning. Although this is a security challenge by itself for all web mail interfaces (where there is a risk of stealing web mail session coookie), the access to all SSL VPN cookies make the impact far more serious. - Trivial cross-site scripting flaws in *any* available intranet application may compromise the entire SSL VPN. Because these applications are usually complex, aplenty, and all under-audited, existence of such bugs is pretty much a certainty. - Trivial cross-site scripting bug in SSL VPNs themselves may endanger the entire system. Impossible? Cisco SSL VPN has this: https://vpnhost/webvpn/dnserror.html?domain=ufoo/u (and yes, they seem to be aware of this, but have no specific timeline for fixing it - so I suppose it's OK to report
[Full-disclosure] Re: SSL VPNs and security
On Fri, 9 Jun 2006, E Mintz wrote: How about some real-world, application specific exploits? There's an example of a XSS that can be used to compromise Cisco Web VPN session in the text. So, please show me an example of an actual compromise and I'll listen. Otherwise, put up, or shut up! You're not strictly required to listen, you know ;) /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [tool] ratproxy - passive web application security assessment tool
Hi all, I am happy to announce that we've just open sourced ratproxy - a free, passive web security assessment tool. This utility is designed to transparently analyze legitimate, browser-driven interactions with tested web applications - and automatically pinpoint, annotate, and prioritize potential flaws or areas of concern on the fly. The proxy analyzes problems such as cross-site script inclusion threats, insufficient cross-site request forgery defenses, caching issues, potentially unsafe cross-domain code inclusion schemes and information leakage scenarios, and much more. For a detailed discussion of the utility, please visit: http://code.google.com/p/ratproxy/wiki/RatproxyDoc Source code is available at: http://code.google.com/p/ratproxy/downloads/list And finally, screenshot of a sample report can be found here: http://lcamtuf.coredump.cx/ratproxy-screen.png The tool should run on Linux, *BSD, MacOS X, and Windows (Cygwin). Since it is in beta, there might be some kinks to be ironed out, and not all web technologies might be properly accounted for. Feedback is appreciated. Please keep in mind that the proxy is meant to highlight interesting patterns in web applications; a further analysis by a security professional is required to interpret the significance of results for a particular platform. Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] Defeating Citi-Bank Virtual Keyboard Protection
On Sat, 6 Aug 2005, Debasis Mohanty wrote: Read the description section again, perhaps you have missed out the following - . The Virtual Keyboard is dynamic . The sequence in which the numbers appears will change every time, the page is refreshed Hence, desiging something the way that you have proposed is not going to workout here. Again, I might be wrong (I am not a Citibank customer), but I understand that, when you visit the logon page, you're presented with an on-screen keypad with keys in randomized and possibly constantly changing (dynamic) order, and must enter your PIN or other authentication data by clicking appropriate on-screen keys using your mouse. What I proposed (and I'm sure I'm not innovative here) went along the lines of hooking up and intercepting the mouse click button, and then, at the exact moment of mouse click, capturing the position of the mouse pointer, and a bitmap of its nearest surroundings - ideally, before the event is delivered to the browser window. That should work regardless of the method used to shuffle displayed keys, is very much workable on Windows and under X11, and shouldn't be particularly resource or bandwidth consuming. This is a generalised way of snooping virtual keyboards and similar on-screen mouse-driven input interfaces. Cheers, /mz http://lcamtuf.coredump.cx/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: Compromising pictures of Microsoft Internet Explorer!
This experiment resulted in identifying a potential remote code execution path in Microsoft Internet Explorer, plus some other bugs, and should be a good starting point for further testing of other browsers or similar programs. Just for the reference, this is confirmed to be fixed by the most recent (and long overdue) cummulative update for MSIE (a part of MS05-038): JPEG Image Rendering Memory Corruption Vulnerability - CAN-2005-1988 A remote code execution vulnerability exists in Internet Explorer because of the way that it handles JPEG images. An attacker could exploit the vulnerability by constructing a malicious JPEG image that could potentially allow remote code execution if a user visited a malicious Web site or viewed a malicious e-mail message. An attacker who successfully exploited this vulnerability could take complete control of an affected system. Thought I'd clarify, because CVE seems to carry original references with one candidate entry (CAN-2005-2308), and Microsoft's patch with no prior references in another (CAN-2005-1988) - so there might be some confusion as to what was fixed and why. CERT and Securityfocus both include proper data, though. Cheers, /mz http://lcamtuf.coredump.cx/silence/ #!/bin/bash echo Content-Type: text/html echo ID=timg-$$-$RANDOM-$RANDOM rm -f timg-* AFX.log cat _EOF_ HTML HEAD META HTTP-EQUIV=Refresh content=0;URL=/ /HEAD BODY _EOF_ CNT=0 for i in img/*; do CNT=$[CNT+1] FNAM=$ID-$CNT EXT=`echo $i | cut -d. -f2` ./afx-loc -p 1 -i 100 -m RANDOM -s 6 $i 2$FNAM.$EXT AFX.log echo Test $CNT - IMG SRC=\$FNAM.$EXT\BR done ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Browser Security Handbook
Hi all, I am happy to announce the availability of our Browser Security Handbook - a comprehensive, 60-page document meant to provide web application developers and information security researchers with a one-stop reference to several hundred key security properties and sometimes counterintuitive quirks in contemporary web browsers: http://code.google.com/p/browsersec/wiki/Main Having a clear picture of these characteristics appears to be of significance to building secure web applications, and to auditing existing designs for potential weaknesses. For this reason, I am hoping that the document is a valuable contribution to the information security community. BSH currently covers recent releases of Microsoft Internet Explorer (versions 6 and 7), Mozilla Firefox (versions 2 and 3), Apple Safari, Opera, Google Chrome, Android embedded browser, and a handful of browser plugins. Please note that due to the sheer number of characteristics covered, I fully expect some kinks to show up here and there; feedback from vendors and security researchers is greatly appreciated. Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Stereotyping DoS and Don'ts
On Wed, 4 Apr 2007 [EMAIL PROTECTED] wrote: * Chinese value punctuality and uniformity. A DoS should be similar to Western Europe, but should not vary in attack methods. Great idea -- but you're four days late to the party! /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Named and the mysterious .so resolves
On Tue, 10 Apr 2007, James Lay wrote: Soo...I see these in my logs from time to time: Apr 10 14:46:37 mail named[739]: unexpected RCODE (REFUSED) resolving 'pam_mysql.so/NS/IN': 209.68.0.85#53 Can anyone shed any light on this? Thanks all! Below is a complete list of .so's attempted: Some dude mistakenly tried: for i in *; do host -t ns $i;done ...in /lib instead of /0wn3d-domains? /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Cross Domain XMLHttpRequest
On Sun, 15 Apr 2007, Michal Majchrowicz wrote: I wanted to show that it is posssible to perform some kind of Cross Domain Requests. As much as I loathe the origin-based security model of modern web browsers, there are semi-valid reasons why XMLHttpRequest is restricted the way it is. A remote attacker can interact with much of the Internet on its own. Your browser is an asset for him for three primary reasons: 1) It might have access to a network that is not directly reachable from the Internet, for example a corporate LAN, 2) It might be in possession of authentication tokens that enable it to access resources the attacker has no access to (web cookies, basic/NTLM credentials). 3) It might serve as a bounce host to hide the actual source of an attack against a third-party site (or, say, even simply adding spam to web forums). For these reasons, you do not want your browser to roam the Internet on its own, and all mechanisms that allow this should be restricted. This is already broken, of course - blind XSRF attacks are possible with plain HTML - but unrestricted XMLHttpRequest would be a powerful, non-blind, and fully interactive method that would be nearly impossible to stop. Your script does not invalidate the need for XMLHttpRequest restrictions - note that there is nothing for you to be gained from running it on your server: you won't see more network than you can see already, you will not receive cookies or other credentials that were not meant for you, and you won't be able to hide your identity while attacking others. Some web developers may benefit from such a bouncer, of course - but this is really not a security-related topic; and still, they should be cautious, because they might end up turning their system in a nifty zombie host. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Assorted browser vulnerabilities
Hello, Will keep it brief. A couple of browser bugs, fresh from the oven, hand crafted with love: 1) Title: MSIE page update race condition (CRITICAL) Impact : cookie stealing / setting, page hijacking, memory corruption Demo : http://lcamtuf.coredump.cx/ierace/ ...aka the bait switch vulnerability. When Javascript code instructs MSIE6/7 to navigate away from a page that meets same-domain origin policy (and hence can be scriptually accessed and modified by the attacker) to an unrelated third-party site, there is a window of opportunity for concurrently executed Javascript to perform actions with the permissions for the old page, but actual content for the newly loaded page, for example: - Read or set victim.document.cookie, - Arbitrarily alter document DOM, including changing form submission URLs, injecting code, - Read or write DOM structures that were not fully initialized, prompting memory corruption and browser crash. This is tested on MSIE6 and MSIE7, fully patched. 2) Title: Firefox Cross-site IFRAME hijacking (MAJOR) Impact : keyboard snooping, content spoofing, etc Demo : http://lcamtuf.coredump.cx/ifsnatch/ Bugzilla : https://bugzilla.mozilla.org/show_bug.cgi?id=382686 [May 30] Javascript can be used to inject malicious code, including key-snooping event handlers, on pages that rely on IFRAMEs to display contents or store state data / communicate with the server. This is related to a less severe variant independently reported by Ronen Zilberman two weeks earlier (bug 381300). 3) Title: Firefox file prompt delay bypass (MEDIUM) Impact : non-consentual download or execution of files Demo : http://lcamtuf.coredump.cx/ffclick2/ Bugzilla : https://bugzilla.mozilla.org/show_bug.cgi?id=376473 [Apr 04] A sequence of blur/focus operations can be used to bypass delay timers implemented on certain Firefox confirmation dialogs, possibly enabling the attacker to download or run files without user's knowledge or consent. 3) Title: MSIE6 URL bar spoofing (MEDIUM) Impact : mimicking an arbitrary site, possibly including SSL data Demo : http://lcamtuf.coredump.cx/ietrap2/ MSIE6 vulnerability, similar but unrelated to my earlier onUnload entrapment flaw, allows sites to spoof URL bar data. MSIE7 is not affected because of certain high-level changes in the browser. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Assorted browser vulnerabilities
On Mon, 4 Jun 2007, Michal Zalewski wrote: 1) Title: MSIE page update race condition Impact : cookie stealing / setting, page hijacking, memory corruption Demo : http://lcamtuf.coredump.cx/ierace/ Just FYI - my logs indicate that there is a fairly high percentage of patterns consistent with successful exploitation among Safari users (about 20%). For the non-vulnerable Firefox, this value is at 1% (for spoofed User-Agent strings, random pranks, etc). As such, the value for Safari seems significant, particularly since this PoC is timing-dependent and fine-tuned for MSIE. I have no immediate way to test it, but feel encouraged to explore this further. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] You shady bastards.
On Wed, 6 Jun 2007, blah wrote: It seems there's a presumption that an employee, when he leaves, still owns that email address that the former employeer provided. Yeah. And if the e-mail in question is [EMAIL PROTECTED], a generic business contact point, he is perfectly OK to hand it over to a different group of employees. For personal, named accounts, it's not necessarily so ethically clear. Legalities aside, no matter what adhesion contracts / policies state, most employees *do* use corporate e-mail for personal correspondence, and most companies tolerate it within the limits of reason. You can terminate an employee for policy violations, but that does not mean you can then proclaim their mailbox to be free of personal correspondence and make it happen. To make things worse, note that in this particular case, the recipient had no reason to assume that the e-mail relates to business matters, and had all reasons to believe that this was a personal message intended only for the clearly named recipient - yet choose to familiarize himself with links provided therein. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apple Safari: cookie stealing
On Wed, 13 Jun 2007, Robert Swiecki wrote: The flaw exists in the javascript's window.setTimeout() implementation. Forgive me the rant, but... all other recently reported problems aside, seeing this, I can only ask - which rock did Safari developers hide under for the past 8 years or so? I mean... this is the type of a flaw you probably no longer even to test for because it seems too obvious - 'ping -l 65510' of the browser world... /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Windows Oday release
On Tue, 12 Jun 2007 [EMAIL PROTECTED] wrote: Dear all, this is not a 0day The author never claimed so; in fact, the subject line clearly states it's a O-day, not a 0-day. This presumably denotes Saint Onuphrius, commemorated on the day this advisory got published. You can now admit to a defeat. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SECNICHE : Dwelling Security is On the Run
On Tue, 12 Jun 2007 [EMAIL PROTECTED] wrote: In an admittedly brief review of this page, I saw nothing useful or informative to my career in information assurance. Aditya has a history of using security mailing lists to advertise his various security consulting projects (metaeye.org, etc) under the guise of fairly bogus whitepapers and vulnerability reports: http://portal.spidynamics.com/blogs/jeff/archive/2007/04/16/ASP.NET-encoding-shortcomings-_2800_review-of-MetaEye-analysis_2900_.aspx http://www.webappsec.org/lists/websecurity/archive/2007-03/msg00079.html http://www.webappsec.org/lists/websecurity/archive/2007-03/msg00115.html As a rule, these claim to discuss cutting-edge attack techniques whilist in fact describing something remarkably mundane (register_globals as Global Space Exploitation, form-based XSS as Double Trap Attacks). I would advise WEBSECURITY moderators to exercise... well, moderation in approving his non-advisory posts: http://www.webappsec.org/lists/websecurity/archive/2007-06/msg00010.html http://www.webappsec.org/lists/websecurity/archive/2007-06/msg00019.html /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apple Safari: idn urlbar spoofing
On Mon, 25 Jun 2007, Larry Seltzer wrote: It looks different on my system: http://www.larryseltzer.com/safe2.png Safari 3.0.2 on XPSP2 Looks simply like a difference in system fonts used on your machines. The attack relies on padding the hostname with Unicode characters that, for the typeface used, are rendered as white spaces. Whether Safari devs are to blame here exclusively, I'm not sure - IDN concept is by itself pretty evil, and this can be viewed simply a clever take on homograph attacks. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] New flaw found in Firefox 2.0.0.4: Firefox file input focus vulnerabilities
On Sat, 30 Jun 2007, carl hardwick wrote: The vulnerability allows the attacker to silently redirect focus of selected key press events to an otherwise protected file upload form field. This is possible because of how onKeyDown event is handled, allowing the focus to be moved between the two. This enables the attacker to read arbitrary files on victim's system. Hey, that's a copypaste from my post! ;-) /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] New flaw found in Firefox 2.0.0.4: Firefox file input focus vulnerabilities
On Sat, 30 Jun 2007, Joseph Hick wrote: This doesn't seem like a security flaw to me. This is somewhat similar to my focus stealing bugs described here: http://lcamtuf.coredump.cx/focusbug/ ...though seems to work on patched Firefox because of a clever use of label-based aliasing. Now, the vulnerability For security reasons, value of file input field cannot be specified in HTML or set scriptually (otherwise, you could then just do submit() and have a file uploaded without user's consent) - and we want it to stay that way. Still, file input field can be hidden off-screen and the victim might be not aware of its presence or contents. Now, if a malicious web page can selectively redirect certain keystrokes to a hidden field of this type, while giving the user an impression he's actually typing a web forum post, playing a game, performing a search, or whatnot, with a visible feedback elsewhere on the webpage - we're in trouble: once a desired file name is collected, the script can have the form submitted, complete with victim's file of attacker's liking. Non-trivial user interaction is required, of course, but it's not terribly difficult to solicit some. Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] New flaw found in Firefox 2.0.0.4: Firefox file input focus vulnerabilities
On Mon, 2 Jul 2007, Joseph Hick wrote: I succeeded in writing the same PoC without label with minor modifications. Would that allow you to selectively redirect keystrokes (that is, check event's keycode)? More importantly, does Carl's original example allow that?:-) An example of event check logic is implemented in my original POC; if you can't redirect selectively (that is, prevent certain events from being delivered to INPUT TYPE=FILE field), the flaw is much less severe. (Would check that, but am at work). /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] EXPLOITS FOR SALE (AUCTION SITE)
On Fri, 6 Jul 2007, Kevin Finisterre (lists) wrote: Do you agree that you are often spoon fed free information by individuals that are not paid for providing you a service? Is it so bad that some of these nice people would ask for a little compensation here and there? Errr, there is a subtle line between publicly disclosing vulnerabilities for the common good, and auctioning double-use 0-days to an unspecified highest bidder. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] EXPLOITS FOR SALE (AUCTION SITE)
On Sun, 8 Jul 2007, wac wrote: Is more noble to reward hard to do work that also requires a lot of knowledge which sometimes people does even takes time to even say thank you. Vulnerability research is good. Getting paid for research is good. Holding vendors accountable is good. Yet, secretly trading intellectual property, keeping it under wraps for months or years to maximize buyer's ROI, and not giving a second thought as to why would a shady foreigner pay $50,000 for an _exploit_ they have no legitimate use for, pretty much stands against *all* the core values of the hacker culture - a culture to which this field of research owes quite a bit. Yeah, it can be done. It might be legal by itself, too - though I'm sure the moment your code is used for malicious purposes (or simply against your government), if it can be shown you willfully ignored the clearly dubious nature of the transaction, a charge of being accessory to crime won't be far off. Still, legal or not, it's not exactly something to be too proud of on this list. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Firefox wyciwyg:// cache zone bypass
There is an interesting vulnerability in how Mozilla Firefox handles internal wyciwyg:// pseudo-URIs. These cache-related resource identifiers are meant to be inaccessible by the user - but there are at least three routes to bypass these restrictionss, one of which - HTTP 302 redirect - also improperly employs same-domain policy checks. This combo flaw enables attackers to intercept sensitive data, perform cache poisoning, or carry out URL spoofing (including SSL certs), against sites that scriptually render documents on client side, and hence produce wyciwyg:// resources to begin with. Although not all sites are susceptible to attacks, a good chunk of Web 2.0, a selection of popular webmails, and several major banks, very much are. A quick demo and a more detailed discussion can be found here: http://lcamtuf.coredump.cx/ffcache/ PS. The two remaining routes to bypass wyciwyg:// restrictions (XMLHttpRequest() and view-source: URIs) appear to properly implement same-domain checks (although view-source seems to be nevertheless not functioning as intended). document.write() + XMLHttpRequest to wyciwyg:// URIs can be used by rogue websites to conveniently store and retrieve persistent markers on visitor's machine regardless of cookie settings; that's not a disaster, but still not very nice. PS2. Bugzilla entry here - source patch available: https://bugzilla.mozilla.org/show_bug.cgi?id=387333 Cheers! /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] MSIE7 entrapment again (+ FF tidbit)
Hello again, Microsoft Internet Explorer seems to have a soft spot for browser entrapment vulnerabilities. Just to recap, in these attacks, the user is made believe he had left a webpage (and the URL bar or SSL state data reinforce him in this belief) - but in reality, is prevented from doing so, and his browser continues to display assorted content originating from the attacker. This is a close, but somewhat more sinister relative of vanilla URL bar spoofing. I reported a few of each kind in the recent months. Well, here's another one, this time based on document.open() calls. In essence, repeatedly calling this function after a new URL is entered by the user, before onBeforeUnload is invoked, inhibits page transition - but target URL bar state is retained. This is remarkably silly. A live demo is available here: http://lcamtuf.coredump.cx/ietrap3/ That is all. ... PS. The promised tidbit - since I'm leaving for a while and won't have time to research this - in Firefox, javascript: windows can set 'domainless' cookies by specifying 'domain=.' - for example: open(javascript:document.cookie='foo=bar;domain=.',_blank); Fortunately/unfortunately, these cookies do not get sent to all sites - no session fixation - though can be retrieved by other null-domain javascript: / data: pages. Specifying other domains won't work. Multiple periods will be trimmed. Path can be set arbitrarily, with certain exceptions. Null-domain cookies load properly when stored in cookies.txt. Q: can this be used in a manner more sinister than merely facilitating exchange of markers between various user-tracking sites? /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] fl0p - passive L7 flow fingerprinting
I'd like to announce the availability of a tool called fl0p, which I hope might be of some interest to various network security dudes and dudettes on the list (and will hopefully serve as a convenient framework for cool research). The tool is a simple flow-analyzing passive L7 fingerprinter. It examines the sequence of client-server exchanges, their relative layer 7 payload sizes, and transmission intervals (as opposed to inspecting the contents, which is what most passive fingerprinters and smart sniffers would do to analyze transmissions). This is then matched against a database of traffic pattern signatures to infer some interesting facts about the traffic. This is along the lines of research done by Solar Designer and Dug Song on timing SSH sessions (though I do not focus on protocol design flaws); this type of analysis got very little air time to date, but unjustly so - there are several interesting benefits of even such a superficial flow analysis: - General insight into legitimate encrypted sessions can be gained: for example, it is trivial to remotely and automatically spot SSH login failures, and react accordingly: the timing and sequence of packets depending on the version of SSH, negotiated protocols, and authentication outcome, will differ quite drastically. - Human actions can be easily told apart from automated efforts based on the latency inherent to wetware I/O bus. As such, you can spot manual poking with your SMTP service despite the noise generated by Internet worms and spam zombies; or, you can tell even a subtle automated SSH login attempt from a typo done by a human being. This extends to most other text-based services. Even such subtle features as user security settings and displayed prompts can be determined: first-time cryptographic key trust question leaves its trace in session timings. - Rogue cryptography can be examined: general flow behavior remains relatively constant regardless of the technology used to hide the actual transferred data. As such, backdoors or firewall evasion techniques that use HTTPS on 443/tcp should be easy to diagnose, either by directly matching relaxed signatures for the tunneled traffic itself, or by spotting unusual client-server traffic / timing imbalances. Now, of course, all this could be achieved before in a slow and painful way - but with fl0p, you have a (primitive but working) tool to simply say: tcp * = s27/15 c27/15 s300/100 : SSH1 - client chose to refuse server key tcp * = s12 [EMAIL PROTECTED] s28 + c52 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] : SSH1 - invalid password attempt tcp * = s12 [EMAIL PROTECTED] s28 c52 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] : SSH1 - automated password guessing tcp * = c30/30 + c1 c1 c1 : Possible manual Windows telnet input (2) ...then launch the program and go to the movies. An example of fl0p output is as follows: (tcp) 213.195.140.12:4667 - 213.134.128.25:25 Observed for: 188B, 6 packets, spans 17 seconds Matches: Possible manual line-by-line interaction (hit: 1) (tcp) 83.31.193.40:3403 - 213.134.128.25:22 Observed for: 584B, 9 packets, spans 5 seconds Matches: SSH1 - client manually accepted key (hit: 1) (tcp) 83.31.193.40:3406 - 213.134.128.25:22 Observed for: 820B, 18 packets, spans 9 seconds Matches: SSH1 - invalid password attempt (hit: 2) (tcp) 83.31.193.40:3436 - 213.134.128.25:22 Observed for: 2.9kB, 19 packets, spans 2 seconds Matches: SSH2 - correct password (hit: 2) The tool is available at: http://lcamtuf.coredump.cx/fl0p-devel.tgz ...and is of course LGPLed (free as in communism). It is fully functional, albeit still marked as beta because of a small signature database (that I'm hoping to extend as a result of this announcement) and (naturally) some spartan documentation. Because of this, at this point, consider it more of a PoC / framework than a standalone fire-and-forget server tool. Your feedback, help, and above all, signature submissions, are as always greatly appreciated. Regards, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Concurrency strikes MSIE (potentially exploitable msxml3 flaws)
A while ago, apparently angry with Larry Seltzer, I penned a quick write-up on the possible issues with race conditions triggered by asynchronous browser events (such as JavaScript timers) colliding with synchronous content rendering: http://seclists.org/vulnwatch/2006/q3/0023.html This is in principle similar to signal handling bugs. I gave an example of a seemingly exploitable flaw in Firefox (see MFSA2006-59 report for more details), but did mention that other browsers are unlikely to be immune. Today, inspired by Brian Krebs' report on MSIE's stellar track of security response that we all owe to responsible disclosure, I thought it would be a brilliant idea to test MSIE for the same class of problems (they had half a year to take notice of my original rant). Hey, and - no peeking! - guess what happened? A quick demonstration of how MSIE succumbs to such problems would be to prepare an XML file that contains a bunch of nested tags (10-1000 is fine), then display it in IFRAME, repeatedly disrupting the rendering process with a Javascript timer that forces the frame to be reloaded every 50-100 miliseconds or so. After just a couple reloads, MSIE will freeze, then crash in a random manner in the vicinity of msxml3 module. I observed seemingly harmless NULL pointer dereferences, writes to bogus addresses, reads from unallocated memory, and various other signs of memory corruption typical of such race conditions. The exact mode of crash depends on precise timing and the contents of browser memory (previously / concurrently displayed pages, contents of the rest of the document), but this is obviously well within the control of a determined attacker. As such, it is my guess that although (as with all race conditions) this would be fairly hard to exploit remotely in a reliable way, it is within the realm of possibility. A quick vanilla but reasonably reliable demo that will probably freeze then crash your browser on a NULL pointer dereference (or sometimes a mangled target pointer on REP MOVSW or something along these lines, if you came there from some other website) can be found at: http://lcamtuf.coredump.cx/iediex/iediex.html ...try using the 'genie.sh' utility provided in the same directory to generate more elaborate test cases that, combined with additional contents of the pages will likely trigger more interesting memory corruption scenarios. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Concurrency strikes MSIE (potentially exploitablemsxml3 flaws)
On Thu, 4 Jan 2007, Larry Seltzer wrote: I hope you're still not angry! It took months of therapy, but I recovered ;) I just tried your demo on IE7. It took a while longer but does seem to have locked up. Were you looking at IE6 or IE7, and is the behavior any different? I tested several installations of IE6, but I wouldn't expect there to be differences (the flaw directly affects a XML rendering library that is probably identical for both versions). /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] 0trace - traceroute on established connections
I'd like to announce the availability of a free security reconnaissance / firewall bypassing tool called 0trace. This tool enables the user to perform hop enumeration (traceroute) within an established TCP connection, such as a HTTP or SMTP session. This is opposed to sending stray packets, as traceroute-type tools usually do. The important benefit of using an established connection and matching TCP packets to send a TTL-based probe is that such traffic is happily allowed through by many stateful firewalls and other defenses without further inspection (since it is related to an entry in the connection table). I'm not aware of any public implementations of this technique, even though the concept itself is making rounds since 2000 or so; because of this, I thought it might be a good idea to give it a try. [ Of course, I might be wrong, but Google seems to agree with my assessment. A related use of this idea is 'firewalk' by Schiffman and Goldsmith, a tool to probe firewall ACLs; another utility called 'tcptraceroute' by Michael C. Toren implements TCP SYN probes, but since the tool does not ride an existing connection, it is less likely to succeed (sometimes a handshake must be completed with the NAT device before any traffic is forwarded). ] A good example of the difference is www.ebay.com (66.135.192.124) - a regular UDP/ICMP traceroute and tcptraceroute both end like this: 14 as-0-0.bbr1.SanJose1.Level3.net (64.159.1.133) ... 15 ae-12-53.car2.SanJose1.Level3.net (4.68.123.80) ... 16 * * * 17 * * * 18 * * * Let's do the same using 0trace: we first manually telnet to 66.135.192.124 to port 80, then execute: './0trace.sh eth0 66.135.192.124', and finally enter 'GET / HTTP/1.0' (followed by a single, not two newlines) to solicit some client-server traffic but keep the session alive for the couple of seconds 0trace needs to complete the probe. The output is as follows: 10 80.91.249.14 11 213.248.65.210 12 213.248.83.66 13 4.68.110.81 14 4.68.97.33 15 64.159.1.130 16 4.68.123.48 17 166.90.140.134 --- 18 10.6.1.166 --- new data 19 10.6.1.70 --- Target reached. The last three lines reveal firewalled infrastructure, including private addresses used on the inside of the company. This is obviously an important piece of information as far as penetration testing is concerned. Of course, 0trace won't work everywhere and all the time. The tool will not produce interesting results in the following situations: - Target's firewall drops all outgoing ICMP messages, - Target's firewall does TTL or full-packet rewriting, - There's an application layer proxy / load balancer in the way (Akamai, in-house LBs, etc), - There's no notable layer 3 infrastructure behind the firewall. The tool also has a fairly distinctive TCP signature, and as such, it can be detected by IDS/IPS systems. Enough chatter - the tool is available here (Linux version): http://lcamtuf.coredump.cx/soft/0trace.tgz Note: this is a 30-minute hack that involves C code coupled with a cheesy shellscript. It may not work on non-Linux systems, and may fail on some Linuxes, too. It could be improved in a number of ways - so if you like it, rewrite it. Many thanks for Robert Swiecki (www.swiecki.net) for forcing me to finally give this idea some thought and develop this piece. Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] 0trace - traceroute on established connections
On Sun, 7 Jan 2007, Michal Zalewski wrote: [ Of course, I might be wrong, but Google seems to agree with my assessment. A related use of this idea is 'firewalk' by Schiffman and Goldsmith, a tool to probe firewall ACLs; another utility called 'tcptraceroute' by Michael C. Toren implements TCP SYN probes, but since the tool does not ride an existing connection, it is less likely to succeed (sometimes a handshake must be completed with the NAT device before any traffic is forwarded). ] Erik Kamerling pointed off-the-list that everybody's favourite Dan Kaminsky (www.doxpara.com) did some research on that subject, too; his 'paratrace' followed a similar principle, but relied on the party correcting out-of-sync retransmissions. I found this approach to give poor results in today's networks with overzealous commercial packet filters, and hence, my tool implements an invasive approach where the current session is trashed with in-sync data to solicit a high response rate. Still, a credit is due! Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] 0trace - traceroute on established connections
On Tue, 9 Jan 2007, Alessandro Dellavedova wrote: am I wrong or the mechanism that you implement is similar to the one implemented in lft (Layer Four Traceroute http://pwhois.org/lft/ ) ? No, what you describe is similar to tcptraceroute, from what I understand (they use stray SYNs or RSTs or other TCP packets to do a regular traceroute). /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] stompy the session stomper - tool availability
Hi all, I'd like to announce the availability of 'stompy', a free tool to perform a fairly detailed black-box assessment of WWW session identifier generation algorithms. Session IDs are commonly used to track authenticated users, and as such, whenever they're predictable or simply vulnerable to brute-force attacks, we do have a problem. [ The reason I'm cc:ing BUGTRAQ is that this tool already revealed several new, potential weaknesses in application platforms, and can be readily used to find more - for example, it is my impression that BEA WebLogic and Sun Java System Web Server both have problems with their JSESSIONIDs [1]; proprietary solutions by some of the larger portals / e-commerce sites didn't always earn a passing grade, either. ] Why bother? === Some session ID cookie generation mechanisms are well-studied and well-documented, and believed to be cryptographically secure (example: Apache Tomcat, PHP, ASP.NET builtins). This is not necessarily so for certain less researched enterprise web platforms - and almost never so for custom solutions that are frequently implemented inside the web application itself. Yet, while there are several nice GUI-based tools designed to analyze HTTP cookies for common problems (Daves' WebScarab, SPI Cookie Cruncher, Foundstone CookieDigger, etc), they all seem to rely on very trivial, if any, tests when it comes to unpredictability (alphabet distribution or average bits changed are top shelf); this functionality is often not better than a quick pen-and-paper analysis, and can't be routinely used to tell a highly vulnerable linear congruent PRNG (rand()) from a well-implemented MD5 hash system (/dev/urandom). As far as I can tell, today's super-bored pen-testers can at best collect data by hand, determine its encoding, write conversion scripts, and then feed it to NIST Statistical Test Suide or alike - but few will. What's cool? In order to have a fully automated, hands-off tool to reliably detect anomalies that are not readily apparent at a first glance, I devised an utility that: - Automatically finds session IDs encoded as URLs, cookies, and in form inputs, then collects a statistically significant sample of data, - Determines alphabet structure to transparently handle base64, uuencode, base32, hex, and any other sane encoding scheme without user intervention, - Translates the data to isolated time-domain bitstreams to examine how SID bits at each position change in time, - Runs a suite of FIPS-140-2 PRNG evaluation tests on the sample, - Runs an array of n-dimensional phase space tests to find deterministic correlations, PRNG hyperplanes, etc, etc. Of course, the tool cannot prove the correctness of an implementation, and it is possible to devise predictable, cryptographically unsafe PRNGs that would pass these tests; still, the tool can find plenty of problems and oddities. Well, that's it. For more, see the included README file. The application, in a fairly decent shape (not a wobbly PoC) and tested under Linux, FreeBSD, and CYGWIN, can be downloaded here: http://lcamtuf.coredump.cx/stompy.tgz Cheers, /mz [1] BEA Weblogic test output: http://lcamtuf.coredump.cx/BEA.log; in response to WebScarab analysis, BEA stated some time ago that the beginning of the identifier might be deterministic at MSB positions: http://dev2dev.bea.com/blog/neilsmithline/archive/2006/03/jsessionid_valu_1.html ...but 'stompy' output seems to clearly indicate that all the data exhibits strong biases, irregularities, and correlation patterns, and as such, the randomness of their very large random number is questionable at best. . ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] stompy the session stomper - tool availability
On Sun, 28 Jan 2007, Rogan Dawes wrote: Just wanted to point out that Dave has had nothing to do with WebScarab (and that I recognise that WebScarab's analysis is pretty trivial). Geee, sorry, I suck for misspelling your name (but feel retroactively avenged: this happens to me quite often ;-). Would you have any objection to me including/porting Stompy's analysis portion into WebScarab, to make it more accessible to folk? No, why, it'd be in all likelihood helpful to others; the code is LGPLed, and I can relicense it to you under some other terms if you prefer. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] stompy the session stomper - tool availability
On Sat, 27 Jan 2007, Michal Zalewski wrote: I'd like to announce the availability of 'stompy', a free tool to perform a fairly detailed black-box assessment of WWW session identifier generation algorithms. I'm genuinely surprised by the amount of (mostly positive ;-) feedback I got! Just an one-time, quick heads up: in response to numerous suggestions, I added a couple of fairly significant features to the tool that should make it capable of discovering far more - so if you downloaded it several days ago, you might want to update your copy: - It now supports SSL connections, custom-crafted requests including POSTs, and input from external sources (for evaluation of non-WWW tokens of any type), - It now uses GNU MP library to losslessly handle alphabets that do not directly map to binary (this is big), - Can run spatial correlation checks as well as temporal analysis of bitstreams in acquired samples, - The output is much more readable, some minor bugs were fixed. A much better documentation is available, as well. The tarball for version 0.04 is available here: http://lcamtuf.coredump.cx/stompy.tgz Regards (and shutting up!), /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Web 2.0 backdoors made easy with MSIE XMLHttpRequest
On Sun, 4 Feb 2007, Tyop? wrote: This is getting depressing. May 2006. but not really surprising, yes? No, though this bug is truly remarkable in that a quick fix, I'm quite certain, amounts to changing != ' ' to ' ' in the code. That's two characters, and no chance for a negative impact on any legitimate application, simply no way. Oh, and actually,did I say May? It gets even better! If you look at that paper, Amit initially noticed that \n and \t are not filtered in September 2005 (17 months ago), and described it as a referrer spoofing bug (granted, not an earth-shattering discovery). He then followed up in May 2006 demonstrating how this can be used to do local cache poisoning, which is kinda more problematic. It's February 2007, the attack can be obviously used to do a really nasty interactive firewall bypass attack in corporate environments - so... ugh. At least they managed to fix it in IE7's new native XMLHttpRequest code, which I bet happened by accident. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Firefox + popup blocker + XMLHttpRequest + srand() = oops
There is an interesting vulnerability in the default behavior of Firefox
builtin popup blocker. This vulnerability, coupled with an additional
trick, allows the attacker to read arbitrary user-accessible files on the
system, and thus steal some fairly sensitive information.
This was tested on 1.5.0.9.
For security reasons, Firefox does not allow Internet-originating websites
to access the file:// namespace. When the user chooses to manually allow a
blocked popup however, normal URL permission checks are bypassed. The
attacker may fool the browser to parse a chosen HTML document stored on
the local filesystem, and because Firefox security manager treats all
file:/// URLs as having same origin, such a document could read other
local files at its discretion with the use of XMLHttpRequest, and relay
that information to a remote server.
Now, to make the attack effective, the attacker would need to plant a
predictably named file with exploit code on the target system. This
sounds hard, but isn't: Firefox sometimes creates outright deterministic
temporary filenames in system-wide temporary directory when opening files
with external applications; even if we ignore this possibility (since it
requires the user to take an additional step that may be difficult to
justify), random temporary files are created using a flawed algorithm in
nsExternalAppHandler::SetUpTempFile and other locations.
The problem here is that stdlib linear congruential PRNG (srand/rand) is
seeded immediately prior to file creation with current time in seconds
(actually, microseconds, but divided by 1e6); rand() is then used in
direct succession to produce an unpredictable file name. Normally, were
the PRNG seeded once on program start and then subsequently invoked,
results would be deterministic, but difficult to blindly predict in the
real world; but here, the job is much easier: we know when the download
start, we know what the seed would be, and how many subsequent calls to it
are made - we know the output.
In a different setting, there would be a level of uncertainty caused by
the fact that system clocks tend to drift or have imprecise settings
(although today, most Windows systems either synchronize with Windows
Time, or domain time services, so this is less of a factor). Still,
there's a yet another nail to the coffin: on first call, Javascript
Math.random() is seeded using the same call in the same manner, PR_Now()
* 1e-6. The seed, and hence a time very close to the moment of file
creation, can be trivially computed by analyzing Math.random() output. But
wait, why bother at all - Javascript can be used to directly read system
clock with a 1-second resolution.
One of several attack scenarios I could think of might look as follows:
1) Have user click on a link on a malicious page. The link would point
to evil.cgi, and have onClick handler set to function foo().
This function would acquire current system time, and use setTimeout to
invoke window.open(p2.html? + curtime,new,); in 100 ms. The
aforementioned cgi script would return:
Content-type: text/html
Content-disposition: attachment; filename=foo.html
htmlbodyscript
x = new XMLHttpRequest;
x.open(GET, file:///c:/BOOT.ini, false);
x.send(null);
alert(The script attempted to read your C:/BOOT.ini:\n\n
+ x.responseText);
/script
2) After user clicks the link, a download prompt will appear, and a copy
of evil.cgi output would be saved in - for example -
C:\WINDOWS\TEMP\c3o89nr7.htm. The download prompt will be immediately
hidden under the newly created p2.html window (this, by default,
bypasses popup blocker. because the window is created in response to
user action).
3) The page currently displayed on top, p2.html, instructs the user to
accept the popup to open a movie player or whatnot; since unsolicited
popups are an annoyance, not a security risk, even an educated user
is likely to comply.
To create a popup warning, a script embedded on the page calls:
window.open('file:///c:/windows/temp/xxx.htm','new2',''),
with a name calculated by repeating a procedure implemented in
SetUpTempFile() with a seed calculated by the server based on
reported system time (p2.html?time).
4) When the user opens that particular popup, attacker-supplied HTML
file is loaded and executed with local file read privileges (in the
aforementioned example, the contents of BOOT.ini file would be
reported back to the victim).
(Ta-dah!)
/mz
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox + popup blocker + XMLHttpRequest + srand() = oops
On Mon, 5 Feb 2007, pdp (architect) wrote: You may as well use a QuickTime .mov/.qtl or a PDF document to open a file:// link . I think it is easier. Sure. You can probably have a file:// link in Open Office / MS Office documents as well; but these all rely on external components, and as such, attacks could be shrugged off as a weakness in these apps (and there's some truth to this). Browser authors know better, and they disallow file:// URLs from the Internet ever since Javascript became so powerful; this case managed to slip through, so I thought it's a neat example, in conjunction with deterministic temporary files. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Bluepill's Rutkowska was or is a Man ?!
On Tue, 6 Feb 2007 [EMAIL PROTECTED] wrote: What is going on ? Is that true ? Any one knows ? That dude is clearly quite determined to debate this like a matter of (inter?)national security, on Wikipedia and elsewhere, but it is getting oddly inappropriate. Get a life and let go. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
There is an interesting logic flaw in Mozilla Firefox web browser. The vulnerability allows the attacker to silently redirect focus of selected key press events to an otherwise protected file upload form field. This is possible because of how onKeyDown / onKeyPress events are handled, allowing the focus to be moved between the two. If exploited, this enables the attacker to read arbitrary files on victim's system. This was tested with 2.0.0.1. Opera is most likely not vulnerable; Microsoft Internet Explorer is not vulnerable as-is, but might be vulnerable to a variant of the attack. All INPUT TYPE=FILE form fields enjoy the benefits of added protection to prvent scripts from arbitrarily choosing local files to be uploaded to the server, and automatically submitting the form. For example, .value parameter cannot be set or changed, and any changes to .type reset the contents of the field. Unfortunately, Firefox allows a malicious script to redirect carefully selected, individual user keystrokes to a hidden file upload field, in order to compose a particular filename, then submit the form. User interaction is required, limiting the impact somewhat - but any website where the user can be reasonably expected to enter some text (a keyboard-controlled web game, a blog posting or commenting interface) can attempt to exploit the vulnerability, and eventually succeed with one user or another. A quick and naive demonstration of the problem (Firefox on Windows is required; depends on scancode values, so not all keyboards may be supported): http://lcamtuf.coredump.cx/focusbug/ (Ta-dah again) /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
On Sun, 11 Feb 2007, pdp (architect) wrote: IE is vulnerable too, since I used to play around with this bug long time ago. Possibly MS00-093, but that's long fixed. But yes, MSIE variant is possible, though more contrived. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
On Sun, 11 Feb 2007, pdp (architect) wrote: here is an idea... we can combine both techniques into a single attack... the hardest part of your hack is to force the user to type :// plus several other / Actually, MSIE doesn't require drive specification in the filename, and will probably accept relative paths as well (so you might not need \ either when picking files from the desktop or 'my documents' or whatnot). Firefox won't settle for a path without drive specification (but it will accept SMB requests ;-). On *nix systems, of course, aiming /etc/passwd is easier than C:\whatever. The problem with intercepting address bar input is that you can't echo the entered text back there without unloading the current document and its scripts; in my examples, I tried to make sure that it's hard for the user to notice that his input is not going where it should (in MSIE example, this includes simulation of a blinking cursor). /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
On Sun, 11 Feb 2007, Michal Zalewski wrote: http://lcamtuf.coredump.cx/focusbug/index.html (FF) http://lcamtuf.coredump.cx/focusbug/ieversion.html (MSIE) Paul Szabo pointed out that this is related to exploits posted by Charles McAuley and Bart van Arnhem in June 2006 (CVE-2006-2894). These guys did not demonstrate a complete attack, and their examples do not seem to work well with MSIE 7 (which might be because of a half-assed attempt to fix the problem, or perhaps not) - but a credit quite certainly is due. Original postings: http://lists.grok.org.uk/pipermail/full-disclosure/2006-June/046610.html http://lists.grok.org.uk/pipermail/full-disclosure/2006-June/046699.html Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
On Sun, 11 Feb 2007, Michal Zalewski wrote: http://lists.grok.org.uk/pipermail/full-disclosure/2006-June/046610.html Oh, and Secunia doesn't credit the Firefox variant to Charles, either: NOTE: A variant of this vulnerability was reported in a Mozilla Bugzilla bug entry back in year 2000. Holy crud! /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
On Sun, 11 Feb 2007, pdp (architect) wrote: this is a design problem that is not easy to fix. That argument would work for a patch deferred by a month or two - not for seven years. And it's not really that much of an issue: disallow script-assisted focusing on file input fields, or a) prevent event target from being changed in onKeyDown (this is what MSIE does) + b) prevent scripts from reading file input field value (really no reason for them to). /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
On Mon, 12 Feb 2007, Paul Szabo wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=304480 https://bugzilla.mozilla.org/show_bug.cgi?id=56236 https://bugzilla.mozilla.org/show_bug.cgi?id=258875 This probably explains why the core of the problem wasn't fixed for Firefox: reports were repeatedly reduced to an issue with hiding file input fields by manipulating opacity or visibility (in my example, I placed the box off-screen to the left, at negative absolute coords, instead). A proper solution would be to restrict the ability for scripts to manipulate focus and read contents of file input fields, instead. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Firefox/MSIE focus stealing vulnerability - clarification
After some research, I can offer this clarification: 1) The MSIE 7 attack vector I described is a distinctive, new vulnerability that differs from the attack reported by Charles McAuley and Bart van Arnhem. Attacks described by them were fixed in MSIE7 (although MSIE6 is still exposed to the original flaw). My vulnerability attacks the same form control, but in a different manner. Again, the demo for this vulnerability is here: http://lcamtuf.coredump.cx/focusbug/ieversion.html 2) The Firefox attack vector is related to the Charles' CVE-2006-2894, which in turn was a rediscovery of a problem known to Mozilla since 2000 (!); attempts to fix it in official releases failed because the problem was repeatedly marked as a duplicate of a too narrowly defined issue with control hiding. A broader redesign probably eliminated the issue in development branches, but it still affects Firefox 1.5 and 2.0. This can be considered an independent rediscovery and a more practical demonstration of a previously reported vulnerability. The exploit is here: http://lcamtuf.coredump.cx/focusbug/index.html Regards, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)
On Mon, 12 Feb 2007, [ISO-8859-1] Claus Färber wrote: A proper solution would be to keep a list of files explicitly selected by the user and only allow uploads of files in this list. Then even if a script can manipulate the field, the browser won't upload files that have not been selected by the user. Not necessarily that easy: notice that it is the user who enters the name of a target file. Unless you want to prevent the browser from accepting any files that were not chosen using a visual file selector widget - but in such a case, there's not much point in having a manual file path entry box in the first place. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Solaris telnet vulnberability - how many on your network?
On Tue, 13 Feb 2007, Gadi Evron wrote: I have to agree with a previous poster and suspect (only suspect) it could somehow be a backdoor rather than a bug. You're attributing malice to what could be equally well (or better!) explained by incompetence or gross negligence. The latter two haunt large companies far more often, compared to sinister conspiracies. Yeah, a backdoor is a remote possibility. But it's also an arbitrary and needlessly complex one. Maybe it's a nefarious plot by our UFO-appointed shadow government, but chances are, it's not (they have better things to do today). Keep that in mind: when risking so much, of all the places to put a covert backdoor to use for years to come, pulling out a known flaw that will be spotted by many existing vulnerability scanners, and putting it in a service that is often disabled as obsolete and generally unreachable from the outside world, doesn't really make that much sense. Unless, of course, it's a sabotage attempt orchestrated by a joint team of IBM and SCO developers... now, that begins to make sense.. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability
There is a serious vulnerability in Mozilla Firefox, tested with 2.0.0.1, but quite certainly affecting all recent versions. The problem lies in how Firefox handles writes to the 'location.hostname' DOM property. It is possible for a script to set it to values that would not otherwise be accepted as a hostname when parsing a regular URL - including a string containing \x00. Doing this prompts a peculiar behavior: internally, DOM string variables are not NUL-terminated, and as such, most of checks will consider 'evil.com\x00foo.example.com' to be a part of *.example.com domain. The DNS resolver, however, and much of the remaining browser code, operates on ASCIZ strings native to C/C++ instead, treating the aforementioned example as 'evil.com'. This makes it possible for evil.com to modify location.hostname as described above, and have the resulting HTTP request still sent to evil.com. Once the new page is loaded, the attacker will be able to set cookies for *.example.com; he'll be also able to alter document.domain accordingly, in order to bypass the same-origin policy for XMLHttpRequest and cross-frame / cross-window data access. A quick demonstration is available here: http://lcamtuf.dione.cc/ffhostname.html If you want to confirm a successful exploitation, check Tools - Options - Privacy - Show Cookies... for coredump.cx after the test; for the demo to succeed, the browser needs to have Javascript enabled, and must accept session cookies. The impact is quite severe: malicious sites can manipulate authentication cookies for third-party webpages, and, by the virtue of bypassing same-origin policy, can possibly tamper with the way these sites are displayed or how they work. Regards, /mz http://lcamtuf.coredump.cx/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability
On Thu, 15 Feb 2007, 3APA3A wrote:
Mitigating factor: it doesn't work through proxy, because for proxy URI
is sent instead of URL and request will be incomplete.
Yup. Depends on the proxy, actually ('GET http://evil.com' might get
parsed as HTTP/0.9) - but Squid, both in direct and in reverse mode (say,
on Wikipedia), will reject such a request.
Cheers,
/mz
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability
On Thu, 15 Feb 2007, pdp (architect) wrote: I wander whether we can execute code on about:config or about:cache. Actually, there are several odd problems related to location updates and location.hostname specifically, including one scenario that apparently makes the script run with document.location in about: namespace. I did not research them any further, so I can't say if they're exploitable - but you can see a demo here, feel free to poke around: http://lcamtuf.coredump.cx/fftests.html Cheers, /mz http://lcamtuf.coredump.cx/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability
On 2/15/07, Michal Zalewski [EMAIL PROTECTED] wrote: [...on other potential Firefox flaws...] I did not research them any further, so I can't say if they're exploitable - but you can see a demo here, feel free to poke around: http://lcamtuf.coredump.cx/fftests.html On Thu, 15 Feb 2007, pdp (architect) wrote: the first one runs in about:blank which is restricted. the second one is very interesting but still not very useful because it acts like about:blank. hmmm it seams that the hostname field has been seriously overlooked. Just a heads up: the first one turned out to be quite useful as a method to bypass anti-UI-spoofing measures in Firefox (see my last non-reply post to BUGTRAQ). The second one is interesting in that it allows to cripple browser's native XUL / JS while still retaining some of its privileges, and to interfere with how other sites' scripts are executed. I have a feeling this can be turned into an exploitation vector, but I haven't had a chance to familiarize myself with that part of FF codebase. I posted a more detailed analysis to Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=370445#c41 ...a quick demo of how wrong things can go is here (bogus .exe is being served): http://lcamtuf.coredump.cx/tx/ The third testcase I posted is not a significant security problem, and the fourth - probably merely a performance issue (though there is some disagreement between developers). /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] new worm traveling the net? (GNU/Linux)
On Mon, 19 Feb 2007, Timo Schoeler wrote: [EMAIL PROTECTED] [...] is this a new worm spreading or something already known? More like a spambot probe of some sorts. http://groups.google.com/groups?hl=enq=catchthismail ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Microsoft Internet Explorer Local File Accesses Vulnerability
On Tue, 20 Feb 2007, Rajesh Sethumadhavan wrote: Microsoft Internet Explorer is a default browser bundled with all versions of Microsoft Windows operating system. Any luck with sending the data back to the attacker? SCRIPT and STYLE ones can be used to steal data from very specifically formatted files, but that's not a whole lot. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Microsoft Internet Explorer Local File Accesses Vulnerability
On Mon, 19 Feb 2007, Peter Dawson wrote: just asking... Is this std practice by vendor to state ??? [..] we ask you respect responsible disclosure guidelines and not report this publicly It's a common and pretty shameless practice for Microsoft. They also openly criticize such researchers in media statements (while mentioning some overly comforting mitigating factors), and then penalize you for not disclosing to them 3-12 months in advance by not crediting you in vendor bulletins. These ungrateful researchers, eh? /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Firefox bookmark cross-domain surfing vulnerability
There is an interesting vulnerability in how Firefox handles bookmarks. The flaw allows the attacker to steal credentials from commonly used browser start sites (for Firefox, Google is the seldom changed default; that means exposure of GMail authentication cookies, etc). The problem: it is relatively easy to trick a casual user into bookmarking a window that does not point to any physical location, but rather, is an inline data: URL scheme. When such a link is later retrieved, Javascript code placed therein will execute in the context of a currently visited webpage. The destination page can then continue to load without the user noticing. The impact of such a vulnerability isn't devastating, but as mentioned earlier, any attention-grabbing webpage can exploit this to silently launch attacks against Google, MSN, AOL credentials, etc. In an unlikely case the victim is browsing local files or special URLs before following a poisoned bookmark, system compromise is possible. Thanks to Piotr Szeptynski for bringing up the subject of bookmarks and inspiring me to dig into this. Self-explanatory demo page: http://lcamtuf.coredump.cx/ffbook/ This is being tracked as: https://bugzilla.mozilla.org/show_bug.cgi?id=371179 /mz http://lcamtuf.coredump.cx ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox bookmark cross-domain surfing vulnerability
On Thu, 22 Feb 2007, pdp (architect) wrote: michal, is that a feature or a bug? maybe it is not obivous to me what you are doing but it i feel that it is almost like asking the user to bookmark a bookmarklet. Bookmarklets should be bookmarkable only manually, with user knowledge and consent (that is, you need to copy-and-paste the URL, etc). This seems to be the case for javascript: URLs. Here, the situation is different: the user can, and quite likely will, unknowingly bookmark a script while attempting to bookmark a regular page via Ctrl-D + return. He doesn't expect or want this code to later run in the context of his start page or any other resource (principle of least astonishment, etc, etc). Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability
There seems to be some confusion regarding the exact impact of the location.hostname vulnerability, and the ways to protect against it. I wanted to offer a quick clarification. 1) Cookie setting (session fixation) attacks can be executed universally and with no restrictions. This is demonstrated by the originally provided PoC, and is a serious security threat. A common implication of such a flaw is that the user can be forced to authenticate within attacker's session, implanted as a persistent cookie. WARNING: The attack does not require the browser to interact with the attacked site in any way. The cookie is set somewhere else and ahead of the visit. In other words, the fact your site runs IIS does not make you any more secure. The fact your servers are behind Squid in a reverse proxy mode has no significance. Vulnerable *clients* can be protected by a proxy that rejects requests containing a NUL character; Squid is a good example. A safer option is to implement the prefs.js workaround recommended on the test page and in Bugzilla, however... and an updated version of Firefox should be available tomorrow, anyway. 2) Frame / window manipulation and cookie stealing attacks can be executed against sites that explicitly set 'document.domain' to an arbitrary value, even if this occurs only on a single sub-page. Some high-profile sites do that, others don't. Still, the attack is very much possible; I prepared a new testcase for non-believers: http://lcamtuf.dione.cc/ffhostname_cnn.html 3) In my initial advisory, I mistakenly stated that XMLHttpRequest() can be one of attack vectors. It can't - contrary to some sources, in Firefox, this mechanism ignores document.domain altogether. You have to rely on the two methods described above - but that's quite a lot, anyway. Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Overtaking Google Desktop
On Thu, 22 Feb 2007, Steve Ragan wrote: Yea he uses it later in the video, you see him pull it up in the attack, and read it. One would assume it is fake. [lights dim, sinister accords play] ...OR IS IT? /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox bookmark cross-domain surfing vulnerability
On Thu, 22 Feb 2007, pdp (architect) wrote: This vulnerability is cute but not very useful mainly because a lot of social engineering is required. Well, very little trickery is required - having a person bookmark an interesting page and then reopen it later on, while the browser is still on its start page (or just about any other high-profile site), isn't that unusual, and does not rely on an improbable set of circumstances, or the user being particularly timid. This problem is not that significant for a different reason - to affect a small percentage of population, you'd need to invest some serious effort into providing content and PR for the attack site. Spending several days to steal GMail cookies from 1000 users is a waste of time when you can get 1 rooted boxes in hours with a trojan horse e-mail. So, yeah. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox: about:blank is phisher's best friend
On Thu, 22 Feb 2007, Florian Weimer wrote: This is the first time I read about the forced window title change. I hadn't noticed it earlier. Do you think this is a good enough security indicator (or indicator of origin, to be more precise)? This is quite inadequate as far as protecting inexperienced users is considered - but at least offers a chance for more alert ones to notice the problem. Bypassing it through about:blank elliminates even this opportunity, so we're back in square one... /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] MSIE7 browser entrapment vulnerability (probably Firefox, too)
There is a cool combination-type vulnerability in MSIE7 that allows the attacker to: a) Trap the visitor in a Matrix-esque tarpit webpage that cannot be left by normal means (this is a known brain-damaged design of onUnload Javascript handlers), b) Spoof transitions between pages so that the user thinks he actually managed to leave the affected site, and so that the URL bar displays other addresses we didn't actually go to. This opens a plethora of spoofing / phishing scenarios, and is generally quite nasty. More information and a pretty demo is available here: http://lcamtuf.coredump.cx/ietrap/ Firefox isn't outright vulnerable to this problem, but judging from its behavior, it is likely to be susceptible to a variant of this bug (it exhibits the same behavior, but we end up with a corrupted page instead); I will research it once I get some sleep. Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Firefox onUnload + document.write() memory corruption vulnerability (MSIE7 null ptr)
While researching my previous report on MSIE7 browser entrapment, I noticed that Firefox is susceptible to a pretty nasty, and apparently easily exploitable memory corruption vulnerability. When a location transition occurs and the structure of a document is modified from within onUnload event handler, freed memory structures are left in inconsistent state, possibly leading to a remote compromise. A quick test case that crashes while trying to follow partly user-dependent corrupted pointers near valid memory regions (can be forced to write, too): http://lcamtuf.coredump.cx/ietrap/testme.html This also crashes MSIE7 with a seemingly harmless NULL pointer bug (didn't research it - do your homework). Firefox problem is being tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=371321 /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] MSIE7 browser entrapment vulnerability (probably Firefox, too)
On Fri, 23 Feb 2007, Michal Zalewski wrote: http://lcamtuf.coredump.cx/ietrap/ I accidentally left a portion of code used to test for the Firefox memory corruption / MSIE7 NULL ptr condition inside 'attack.js' for this page. This crashed the testcase for some users, instead of demonstrating the entrapment issue. If you had this problem, please re-test now. Cheers, /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Firefox: onUnload tailgating (MSIE7 entrapment bug variant)
On Fri, 23 Feb 2007, Michal Zalewski wrote: Firefox isn't outright vulnerable to this problem, but judging from its behavior, it is likely to be susceptible to a variant of this bug And indeed, susceptible it is. On the surface, the problem is even more serious: the unloaded page can run Javascript in the context of a newly loaded one. Fortunately, at the time this is possible, 'document' and 'window' DOM hierarchies are not accessible - but then, 'location' is. With a bit of clever trickery, we can mount the following attack: http://lcamtuf.coredump.cx/ietrap/ff/ As shown there, the problem is less serious than MSIE7 full-scale Matrix-esque entrapment, but nevertheless - the bug is a cool one. And I have a gut feeling this Javascript page jumping can be turned into something nasty. Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=371360 /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Advisory 03/2007: Multiple Browsers Cross Domain Charset Inheritance Vulnerability
On Fri, 23 Feb 2007, Stefan Esser wrote: Proof of Concept: The Hardened-PHP Project is not going to release a proof of concept exploit for this vulnerability. ...because pretty much no exploit is needed. Scary. Good catch. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox onUnload + document.write() memory corruption vulnerability (MSIE7 null ptr)
On Sun, 25 Feb 2007, Stan Bubrouski wrote: http://lcamtuf.coredump.cx/ietrap/testme.html This bug was fixed in 2.0.0.2, released Friday Feb 23. No it most certainly wasn't, do your homework next time. Actually, the story is kinda funny, but yeah, it seems that it's fixed now. The story: I reported the problem a day before 2.0.0.2 was to be released. Mozilla dev team looked into this, but - if I understand correctly - decided to go on with 2.0.0.2 as planned, without a fix for this vuln, then follow up with a quick release of 2.0.0.3 to address the problem. This seemed like a sane decision - 2.0.0.2 had been postponed previously, so there seemed to be no point in holding back. When 2.0.0.2 went live, some devs noticed that it doesn't crash with my testcase, though it still crashes trunk builds. After a brief moment of confusion, they determined that a fix for an unrelated, obscure non-security bug 364692 had altered the behavior this vulnerability depended on, accidentally rendering 2.0.0.2 not vulnerable to the attack. This was then fixed on trunk, and voila. I can't really comment on whether this fixes the problem once and for all, because I haven't really examined the changes implemented for 364692, but yeah, my example no longer crashes the browser for me. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] MSIE7 browser entrapment vulnerability (probably Firefox, too)
On Fri, 23 Feb 2007, Jeffrey Katz wrote: Just checked on IE 7.0.5730.11 -- doesn't exhibit problem. Most certainly does; you might have scripting disabled, or be experiencing some other anomaly, but for much of the population, the attack works as advertised on that version. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox onUnload + document.write() memory corruption vulnerability (MSIE7 null ptr)
On Tue, 27 Feb 2007, Richard Moore wrote: html body onunload=location = self.location a href=http://slashdot.org/;http://slashdot.org//a /body /html Yeah, and the other way round: http://lcamtuf.coredump.cx/ietrap/, when used with FF 2.0.0.2, puts you on a page that: 1) Has URL bar data and favicon from the target site, 2) Views source of what you added with document.write(), 3) Displays as blank. Moreover, repeatedly setting document.location = xxx; on departure may land you at slashdot.org/xxx instead (meaning the update is being performed in the context of the new page). Although this looks like a Really Bad Thing (tm), I didn't succeed in modifying /ietrap/ to display a malicious payload (though feels like it's sooo close), nor in manipulating DOM in the latter example to do anything other than annoying the user (because 2.0.0.1 kept crashing ;-). Still, I'm not gonna sleep well until this is fixed. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Knorr.de SQL Injection and XSS Vulnerabilities
Significance: Very Critical I'm very pro-disclosure. I do see a point in disclosing flaws in software or hardware we might use. I do see a point in reporting flaws in websites we rely on (banks, online shops). Hey, there might even be a weak case for shaming security vendors, IT companies, or fellow professionals by exposing flaws on their sites; it's mean, but it may have some value. But I'm puzzled at to what's the point in telling the world about a generic flaw in soup-maker's website, where - really - the number of people even marginally affected is truly negligible? Talk to them, tell them, have it fixed; if they're nice, they might even give you a gift or some sort (year's worth of instant noodles, I'm thinking). Blog it if you find it important to tell others about your achievement, but really, that's where it should end. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Firefox: about:blank is phisher's best friend
Firefox suffers from a design flaw that can be used to confuse casual users and evoke a false sense of authority when visiting a fraudulent website. The flaw can be also used to bypass a fix for an old UI spoofing bug that was thought to be addressed. This is a relatively minor issue, but I thought it's worth reporting. It is possible for a script to open 'about:blank' URL in a new tab; this tab will be opened with a blank address bar (the behavior is different for new windows, where the bar will be grayed out or hidden). The script can then interact with this document as if it were a page in the same domain, including the ability to inject of custom HTML. Some methods of adding this HTML, such as win.document.write(), will update document.location and the address bar to that of the interacting script, which seems like an intuitive choice - the user is informed about the origin of the displayed data. Since about:blank is a minimal but valid HTML document with a DOM structure, it is also possible to inject code through the use of win.document.body.appendChild() and friends, in which case, the URL bar remains blank, the 'reload' button is disabled, and 'page info' / 'page source' menu options will show no useful data. Having text displayed in a window that has an empty URL bar can confuse the user as to the origin of the displayed data or security prompts, as if they were internal browser messages; an empty address bar is considerably less suspicious than a shady host name or a panic-inducing data: URL scheme. Furthermore, there was an old UI spoofing bug - when a window was opened without URL bar and menus, the attacker could use strategically placed graphics and HTML controls (or XUL code), so that the fake URL bar read google.com, while an IFRAME below could display zombo.com instead. Similarly, he could spoof a native browser-originating modal warning or dialog to have the user do something dumb. This problem was addressed by forcibly prepending current site name to window title for all URL-bar-less windows, so that the Internet origin of such a pop-up is clear, and so that it will have a hard time mimicking a native window. The problem is that 'about:blank' windows that have no document.location defined can be used to inhibit this behavior - window title can be freely controlled, except for the appended ' - Mozilla Firefox' string, and spoof browser UI elements without the user having a reason to be suspicious. A quick if naive demonstration of the two attacks described here can be found at this URL: http://lcamtuf.coredump.cx/ffblank/ [ Note that I simply used a screenshot of my UI, which is a non-standard one, and the image is not compensated for other screen resolutions etc; as such, you should be able to see that the URL bar is unusual and non-interactive; that's not a limitation of this attack, but rather, an unloved bastard child of my sheer laziness. ] rant PS. On an unrelated note - in 2004, people began to notice that these nifty yellow security notification bars that appear on the top of MSIE7 and FF windows can be trivially spoofed by a webpage (A plugin is required to display this content. / An update to Firefox is available), proving that placing messages in a script-accessible region of the window was a terrible, terrible design decision. These problems were not fixed, but rather dismissed as a user responsibility (to do what exactly, learn all legitimate notices and tell them from fakes?). What the hell? /rant Cheers, /mz http://lcamtuf.coredump.cx ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] a couple of notes on Neal Krawetz image forensics presentation
As a bad photographer with several forays into the forensic world, I have a couple of comments on a recent (and pretty interesting!) Black Hat presentation by Neal Krawetz (www.hackerfactor.com) on image forensics: http://blog.wired.com/27bstroke6/files/bh-usa-07-krawetz.pdf To make things clear: I liked it. I think it's solid. I don't want this to be picked up by the press and turned into a food fight. I respect the author. My point is to express my slight doubts regarding several of the far-fetched conclusions presented later in the talk -before the approach is relied upon to fire someone from his post or the like. First things first: in the presentation, following an overview of some of the most rudimentary manual anslysis techniques, Mr. Krawetz employs several mathametical transformations as a method to more accurately detect image tampering. This is based on a valid high-level premise: when lossy formats are repeatedly edited and recompressed, the quality of various portions of the image will proportionally degrade. If the image is composed from a couple of previously lossy compressed files from various sources, their compression degradation patterns may differ - and the current level of degradation can be quantified, in the most rudimentary way simply by measuring how each compression unit (with JPEG, an 8x8px cell) changes with further compression - which is a nonlinear process. The property that makes this possible is known to all photographers - the progressive degradation is the main reason why professional and prosumer photo editing and delivery is done almost exclusively using storage-extensive lossless formats, and why SLR cameras support RAW / TIFF output (and why skilled image forgers would not use lossy formats until they're done, or if forced to, would rescale their work and add subtle noise to thwart analysis). I'm pretty sure the approach is used as one of the inputs by commercial image forensics software, too - along with a couple of other tricks, such as similarity testing to spot the use of clone tool. Now, to the point: the wow factor associated with the presentation and picked up by the press comes from a claim about an apparent heavy manipulation of certain publicly released pictures of Al Qaeda associates, as a proof of the accuracy and reliability of the automated approach - and that's where I'm not really so sure about the conclusions reached. In essence, my issue with this is that the presentation fails to acknowledge that observed patterns do not necessarily depend on the number of saves alone. There are certain very common factors that play a far more pronounced role - and in fact, some of them seem to offer a *better* explanation of some of the artifacts observed. The two most important ones: - Non-uniform subsampling: JPEG and MPEG typically employ 4:2:0 chroma subsampling. This means that a region where a contrast between objects is primarily a product of color changes (at comparable intensity of reflected light) may appear to be older (already lower frequency contrast, producing less pronounced error difference patterns) compared to a region where the same level of contrast can be attributed to luminosity changes alone. Consider this example: http://lcamtuf.coredump.cx/subsampling.png ...we then compress it as a JPEG: http://lcamtuf.coredump.cx/subsampling.jpg ...and can compare the level of compression-related degradation by converting it to cyan-weighted BW: http://lcamtuf.coredump.cx/subsampling_bw.png I attempted to recreate the RGB error difference approach of Mr. Krawetz, resaving it again at a slightly different compression level, and came up with this image, which seems to suggest that only the top text is brand new (comparing this to the conclusions reached for various TV frame grabs later in his presentation, where similar differences in color and contrast were resolved in favor of manipulation): http://lcamtuf.coredump.cx/subsampling_nk.jpg Simply picking out Y component does not help either - since the working space of the editor is inevitably RGB, each resave causes Cb and Cr resampling imprecision to spill to Y on YCbCr - RGB - YCbCr conversions, and introduce errors comparable to what we're trying to detect. - Quantization. JPEG quality is controlled primarily by the accuracy of image quantization step that discards differences in many high-frequency 8x8 patterns, while generally preserving low-frequency ones, but possibly introducing higher-frequency artifacts around more complex shapes, subject to rapid degradation. A good example of this is the following picture: http://blog.wired.com/photos/uncategorized/2007/08/01/ayman_alzawahiri.jpg http://blog.wired.com/photos/uncategorized/2007/08/01/ayman_alzawahiri_analysis.jpg Krawetz attributes the outline around al-Zawahiri seen on the second
Re: [Full-disclosure] Firefox 2.0.0.6 Remote Variable Leakage vulnerability
On Sun, 12 Aug 2007, carl hardwick wrote: Firefox Remote Variable Leakage I'm afraid don't entirely follow this attack - though I might be wrong... The PoC, in essence, enumerates all Javascript variables and functions that are publicly declared by the browser in the context of the current page (after loading several chrome:// scripts in the security context of the current page to inflate their count [1]). Yes, there's plenty of variables and functions defined, but to consider this a security vulnerability, one should demonstrate that: 1) Sensitive user preferences are disclosed this way (for example, any non-trivial prefs.js setting), 2) Variables set by other sites can be read in violation of same-domain policy. Is this the case here? [1] What I find troubling in your example is that chrome:// URLs are not restricted on Internet-originating SCRIPT SRC=. I'm not sure there's any sensitive data in Firefox chrome:// namespace, but it is certainly unwise to assume this will always be the case for third-party plugins. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox 2.0.0.7 has a very serious calculation bug
On Fri, 28 Sep 2007, carl hardwick wrote: javascript:5.2-0.1 Firefox 2.0.0.7 result: 5.1005 (WRONG!) This is a proper behavior of IEEE 754 64-bit double float, which, IIRC, is precisely what ECMA standard mandates. You will get the same from any C-style 'double' arithmetics. Internet Explorer 7 result: 5.1 (OK) They use a marginally higher precision. Now try 5.002-.001 - chances are, you will get 5.00999... Neither is a very serious calculation bug. Javascript does not guarantee - and nowhere actually delivers - arbitrary GMP-style precision. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox 2.0.0.7 has a very serious calculation bug
On Sat, 29 Sep 2007, Jimby Sharp wrote:
I don't get the same from C-style double arithmetics. Could you provide
a sample code that you believe should show the same behavior?
If you don't, it's presumably because the subtraction is optimized out by
the compiler, or because you printf() with an insufficient precision in
format spec. The following should do the trick:
volatile double a = 5.2;
volatile double b = 0.1;
main() { printf(%.16lf\n,a-b); }
/mz
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux Kernel 2.6.x PRCTL Core Dump Handling - simple workaround
On Thu, 13 Jul 2006, Matthew Murphy wrote: setting 750 on /etc/cron.* would stop this exploit Incorrect. Did you even try this on ONE vulnerable box? The vulnerability exists BECAUSE the kernel doesn't enforce directory permissions when writing a core dump. You cannot chdir to (or access a file within) a directory to which you have no 'execute' permission. Cores are dumped in the current working directory of a process. You cannot make /etc/cron.* your working directory unless the aforementioned permission is given to you. The exploit works by doing a chdir to that directory as an user; if the directory is not accessible, this will fail, and the core will be dumped in elsewhere. The vulnerability still probably can be exploited by other means (mail subsystem? logrotate? etc), but that probably pretty much solves the crond vector. If your users actually have write permissions to /etc/cron.d, do the world a favor and disconnect from the internet as soon as humanly possible. You seem to be confused. Most systems do have a+rx permissions to /etc/cron.* directories, and that most certainly helps with that exploit. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] RE: Crap capitalistic artical in PC World
On Tue, 25 Jul 2006, [EMAIL PROTECTED] wrote: http://www.pcworld.com/news/article/0,aid,126438,tk,nl_wbxnws,00.asp Is that the best they can muster ? No, they have many other equally fine articles ;-) /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Concurrency-related vulnerabilities in browsers - expect problems
Good morning, Fame-hungry sociopath torches cars, finds browser flaws WARSAW, Poland (AP) -- police are on a look out for a local adolescent vandal who continues to terrorize local IT workers in what appears to be a bizzare bid for fame. Larry Seltzer reports from the scene. Well, I just had to do this, forgive me. There seems to be an interesting class of concurrency-related bugs in popular browsers. This is quite similar to signal-handling flaws you might be familiar with: many browser events can be triggered asynchronously, for example using Javascript timers, while some components of the browser are still running. In many cases, a new action might be initiated that interferes with or counters the interrupted (or still executing) task. Problems like this may leave the program in inconsistent state, and later cause double frees or related issues. That usually opens the door to system compromise through careful manipulation of memory contents. The attacks would depend heavily on network latency and jitter, but can be executed. Given that the tip of that iceberg has been probed recently - for example here: http://www.mozilla.org/security/announce/2006/mfsa2006-46.html - I assumed it is now the time to post my older example. A fairly reliable example is when Firefox is interrupted by a Javascript handler while parsing a deeply nested XML document for display. If the browser is then redirected from the script to a new location, the unfinished parsing process is aborted, and all its structures are freed - but these were not left in the expected state by the parser. This is a demo that will usually crash Firefox in a couple of seconds (SEGV on Linux and MacOS, silent crashes on Windows): http://lcamtuf.coredump.cx/ffoxdie.html Have fun! PS. For the easily amused: MSIE loves DTH1 STYLE=width:1pxLI/H1 /mz http://lcamtuf.coredump.cx/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] FYI : Satori - Passive OS fingerprinting, revisited
On Sat, 12 Aug 2006, Thierry Zoller wrote: I found out about Satori while reading the paper [2] Chatter on the Wire Hey, that name rings a bell... ;-) /mz http://lcamtuf.coredump.cx ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: Concurrency-related vulnerabilities in browsers - expect problems
Here's another separate issue that typically causes fault on memory access to website-influenced memory access: http://lcamtuf.coredump.cx/ffoxdie3.html This is separate from the previously presented example (which, remarkably, also had a tendency to trigger an unrelated call stack overflow due to XML parsing glitch on some platforms, which caused some confusion - my bad). Note that because it depends on timing more heavily, it may not work in the first shot on all computers (though it should). /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: [VulnWatch] Re: Concurrency-related vulnerabilities in browsers - expect problems
On Thu, 17 Aug 2006, Steven M. Christey wrote: In other words - concurrency is a rich area for future research Or past research, for that matter ;-) http://en.wikipedia.org/wiki/Therac-25 The lesson learned is... uh... /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apple Safari ... DoS Vulnerability
The fun times of security semantics! Old debates never die... Vulnerabilities are a subset of software engineering bugs. As the name implies, they are defined strictly by the impact they have; if a bug does not render the victim appreciably susceptible to anything that would be of value to external attackers, it is not a security problem. Now, there are two points to be made: 1) Value to the attacker is a broad and fuzzy term that also covers emotional gratification (by just causing hardship to a disliked party) - so loss of availability should be often treated as a security glitch (well, you could also say a reliability glitch and start another argument); but the important thing is, not all bugs that cause a crash will cause noticeable loss of availability - i.e., no service is denied or deferred to third parties. For example, crashing a sshd or ftpd child handling my own connection is not interesting by itself, unless events leading to the crash, or the crash itself, impose a significant and repeatable resource strain. Crashing a keep-alive httpd child might be marginally more expensive, and hence maybe a limited security concern. 2) Appreciably susceptible is just as hard to quantify when dealing with high loss, but low probability scenarios; there were quite a few bugs that likely affected very few or no users (e.g., many of the publicly reported command-line overflows in non-suid programs), but a hypothetical scenario where it would matter could be constructed (in the aforementioned case, say, really bad PHP / CGI scripting). Most people dismiss such vulnerability reports, but it's difficult to draw the line. Anyway... bottom line is, any attempts to formalize the criteria are bound to fail (and have mostly failed in the past), and common sense is the best tool we have. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apple Safari ... DoS Vulnerability
[Thierry Zoller] In my book, maybe only in mine, a software bug is security relevant (sorry for the lack of clarity - it's late over here) as soon as Integrity / Availabilty / Confidentiality are under arbritary direct or indirect control of a another entity (i.e attacker). Period, This is a neat definition, but in reality, not a very practical one (and vague enough to encompass a broad range of scenarios that have nothing to do with security vulnerabilities, including sabotage or social engineering). As an example of why such absolutes are impractical, consider that the availability of any external IT service in the world is under (limited) control of a sufficiently determined attacker, by design - simply because computers have limited resources. Unless we want to consider the presence of any such service an inherent vulnerability in itself, you need to place sensible, common sense constraints on the definition, such as that there must be a plausible effort-benefit ratio involved. Likewise, in that spirit, most cryptographic hash functions and PRNGs are inherently vulnerable to attacks given sufficient resources; but the function (and a system that uses it) is deemed secure if the amount of resources needed, based on currently known attack methods, is absurdly impractical. Or, processors, computer memories, and hard drives are inherently unreliable, although manufacturing processes try to keep the number of failures in check, and recover from certain errors. That said, given enough resources, and a very large number of tries, the attacker could both trigger stress conditions (e.g. elevated CPU temperature), and - unlikely, but not impossibly - eventually hit a random bit flip that benefits him in some way. Realistically, neither of these scenarios is considered a security risk until the cost-benefit ratio comes uncomfortably close to being worth pursued in practice. Security is not an abstract, formal property (attempts to define it as such are usually pretty interesting - but also out of touch), but for better or worse, the job of approximating the impact of the worst-case scenario we can think of. You define vulnerability like a boolean that is true when the impact is of value to the attacker. would be of value to external attacker - I cleary disgress, I don't think that a the nature/ of a bug (vulnerability) can be defined by the value it has for the attacker. What about damage to the victim ? What about lost revenue, agreement breaches etc pp. I think I specifically mentioned this in my original post? [J. Oquendo] So let's place this Safari bug for example as a high impact and use CVSS as a guide: The most amusing part is whenever NVD handlers accidentally enter the same issue twice, cover a regression to an earlier bug, or cover essentially the same bug affecting different products at different times - and the rigorously calculated CVSS scores would somehow deviate wildly. Security deals with unlikely events that are notoriously hard to predict and quantify, and in most cases, carry nearly unlimited damage potential (certainly not tied to an asset, as a good number of high-profile break-ins managed to demonstrate in the past); there is also no direct, cumulative gain from being mostly secure, to offset the cost of compromises. Most attempts to apply the concept of strict, by-numbers risk management to this setting end up just being goofy at best, and extremely negligent and damaging at worst. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apple Safari ... DoS Vulnerability
By the way, I'm now selling a Risk Management and Scoring tool for $19.99 that will allow you to enter a program and define what you think the risk is. The program will allow you to pick your target: CIO, CEO, CSO. It will then go out and create a custom chart to maximize your budgetary request or downplay a potential threat. A sizable percentage of the list is probably thinking Shit, I wish I had thought of that. :) My thought was that the decimal point is off to the left, by three or four digits probably. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
