http://www.secuobs.com Observatoire de la securite Internet fr webmaster@secuobs.com 2010-07-26 23:57:03 - lcamtuf's blog : The New York Times, July 2010 link Steven Aftergood, head of the project on government secrecy at the Federation of American Scientists, in his blog posting on June 28 accused WikiLeaks of 'information vandalism' with no regard for privacy or social usefulness 'WikiLeaks must be counted among the enemies of open society because it does not respect the rule of law nor does it honor the rights of individuals,' he wrote Scott Culp, October 2001 link If we can't eliminate all security vulnerabilities, then it becomes all the more critical that we handle them carefully and responsibly when they're found Yet much of the security community handles them in a way that fairly guarantees their use, by following a practice that's best described as information anarchy It's simply indefensible for the security community to continue arming cybercriminals http://www.secuobs.com/revue/news/244035.shtmlhttp://www.secuobs.com/revue/news/244035.shtml Secuobs.com : 2010-07-26 10:29:17 - lcamtuf's blog - To continue the revered tradition of inconsequential, off-topic posts about hobby work, here's my current project Youtube video Description page In a desperate attempt to keep you from unsubscribing some interesting security bugs coming soon http://www.secuobs.com/revue/news/243790.shtmlhttp://www.secuobs.com/revue/news/243790.shtml Secuobs.com : 2010-07-21 23:46:45 - lcamtuf's blog - When explaining why it is not possible to meet a particular vulnerability response deadline, most software vendors inevitably fall back to a very simple and compelling argument testing takes time I have dealt with a fair number of vulnerabilities on both sides of the fence - and I am often skeptical of such claims while exceptions do happen, many of the disappointing experiences appeared to stem from trouble allocating resources to identify and fix the problem, and had very little to do with testing the final patch That said, my personal experiences are necessarily limited - so for the sake of this post, let's take the claim at its face value To get to the root of the problem, it is important to understand that software quality assurance is an imperfect tool New code is never written with the intent of breaking anything it's a completely unintended and unanticipated consequence of one's work the same human failings that prevent developers from immediately realizing the potential side effects of their code also put limits of what's possible with QA there is no bound of what could be tested given enough time, and no way to truly predict what will go wrong with modern, incredibly complex software Within these constraints, most corporations simply learn to err on the side of caution settle on a maximum realistically acceptable delay between code freeze and a release that still keeps you competitive - and then structure the QA work to be compatible with this plan There is always one more test one could be doing, given more time or more resources and chances are, a lot less could be tested without ever running into a single problem, too One of these options is not commercially viable, the other is simply scary Once a particular organization has this process in place, it is tempting to treat security problems exactly the same way one would handle feature enhancements there is a clear downside to angering customers with a broken release - and as long as vulnerability researchers can be persuaded to engage in long-term bug secrecy, there is seemingly no benefit in trying to get the fixes out the door any sooner This argument overlooks a crucial point, however vulnerabilities are not obviously created by the researchers who spot them they are already in the code, and tend to be routinely rediscovered by unrelated parties at roughly the same time I would expect that at least 10pourcents of current privately reported vulnerabilities are known independently to multiple parties - and the longer they are allowed to persist, the more pronounced this problem is bound to become Secret vulnerabilities pose a definite and extremely significant threat to the IT ecosystem in many cases, this risk is far greater than the speculative risk of occasional patch-induced breakage - doubly so when one happens to be a high-profile target Vendors often frame the dilemma the following way Let's say there might be a vulnerability in one of our products Would you rather allow us to release a reliable fix for this flaw at some point in the future or rush out something potentially broken but this is, essentially, a loaded question I am willing to argue that a more realistic way to frame this is A vulnerability in our code allows your machine to be compromised by others there is no widespread exploitation, but targeted attacks are an appreciable risk Do you prefer to live with this vulnerability for a few more months, or install a patch that stands a remote chance of breaking a functionality you depend on - in which case, the burden of testing would be on you Or would you be inclined to pay X more for our products to have our QA process more streamlined, instead The answer to that second set of questions is more complex than vendors would like it to be - but more relevant to the problem at hand Yes, quality assurance is hard It can also be expensive expensive to better parallelize or improve automation in your QA work and it is disruptive to your business to change the way you support and release your products some vendors still target security fixes for the next major release, along with hundreds of other tweaks It is also inevitable that some of these changes would fire back in unexpected ways - but nothing of this makes the problem go away Indefinite bug secrecy hurts us all by removing all incentives for improvement, and giving very little real security in return http://www.secuobs.com/revue/news/242639.shtmlhttp://www.secuobs.com/revue/news/242639.shtml Secuobs.com : 2010-07-21 00:48:23 - lcamtuf's blog - I am very proud to have this official blog post out Rebooting Responsible Disclosure a focus on protecting end users I am proud of this post not because it adds a yet another voice in the ongoing debate I am proud because I think it is important and significant for a major commercial vendor to suck it up - and take a genuine, passionate stand behalf of all users instead The rhetoric invoked by most software vendors today is very one-sided, and aims to portray the disclosure debate as a petty feud with selfish, arrogant researchers oblivious to the realities of doing business I find this disingenuous - and so, I sincerely hope that this blog post sets a brand new stone rolling PS On a related note 3,1337 http://www.secuobs.com/revue/news/242230.shtmlhttp://www.secuobs.com/revue/news/242230.shtml Secuobs.com : 2010-07-07 12:41:45 - lcamtuf's blog - There are about three people in the world who could possibly ever care about this epic work - so today, I am happy to unveil my least useful project to date the 70,000 word CNC machining and resin casting guide for hobbyist robot builders Volume I Volume II Thank you We now resume our regularly scheduled programming http://www.secuobs.com/revue/news/238312.shtmlhttp://www.secuobs.com/revue/news/238312.shtml Secuobs.com : 2010-07-06 23:57:54 - lcamtuf's blog - It always struck me as a simple deal there are benefits to openly participating in the security research community - peer recognition and job opportunities There is also a cost of doing it as a hobby - loss of potential income in other pursuits After having made a name for themselves, some people decide that the benefits no longer offset the costs - and stop spending their time on non-commercial projects Easy, right Well, this is not what's on the minds of several of my respected peers Somewhere in 2009, Alex Sotirov, Charlie Miller, and Dino Dai Zovi announced that there will be no more free bugs in Charlie's own words As long as folks continue to give bugs to companies for free, the companies will never appreciate or reward the effort So I encourage you all to stop the insanity and stop giving away your hard work The three researchers did not feel adequately compensated for their unsolicited research, and opted not to disclose this information to vendors or the public - but continued the work in private, and sometimes boasted about the unverifiable, secret finds Is this a good strategy I think it is important to realize that vendors, being driven by commercial incentives, spend exactly as much on security engineering as they think is appropriate - and this is influenced chiefly by external incentives PR issues, contractual obligations, regulatory risks Full disclosure puts many of the poor performers under intense public scrutiny, and may force them to try harder and hire security talent that's you On the other hand, they do not benefit from these free services, and will not work with you to nourish them if you threaten them by promising to stop being a PR problem unless compensated - well, don't be surprised if they do not call back soon with a job offer or two There is an interesting way one could make this work, however the pay us or else approach - where the else part may be implied to mean Selling the information to unnamed third parties, to use it as they see fit with potential consequences to the vendor's customers , Shaming the vendor in public to suggest negligence company X obviously values customer safety well below our 10,000 asking price , Simply tellling the world without giving you a chance to fix it There's only one problem I think these tricks are extremely sleazy There are good and rather uncontroversial reasons why disclosing true information about an individual is often legal, but engaging in blackmail never is the parallels are really easy to draw This is why I am disappointed by the news of VUPEN apparently adopting this strategy full article and equally disappointed by how few people called it out French security services provider VUPEN claims to have discovered two critical security vulnerabilities in the recently released Office 2010 but has passed information on the vulnerabilities and advice on mitigation to its own customers only For now, the company does not intend to fill Microsoft in on the details, as they consider the quid pro quo a mention in the credits in the security bulletin inadequate 'Why should security services providers give away for free information aimed at making paid-for software more secure ' asked VUPEN CEO Bekrar Here's the thing security researchers don't have to give out any information away for free but if you need to resort to arm-twisting tactics to sell a service, you have some serious soul searching to do http://www.secuobs.com/revue/news/238140.shtmlhttp://www.secuobs.com/revue/news/238140.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - The Usenet is long dead, and mailing lists such as BUGTRAQ or full-disclosure seem to be on their way out, too A growing number of security researchers opts to discuss their research on Twitter, through blogs, or by directly reaching out to the media For what it's worth, I think it's a bad idea instead of having a single aggregation point for all the industry news, you now need to maintain a long list of researchers to follow, painstakingly discover new sources through social networking, and filter a lot of noise But, it also seems to be the way we are doing business these days - so no point in whining In this spirit, and because people who do not follow the aforementioned lists usually think I am dead, I decided to check out this newfangled blogging thing I promise to update it infrequently and to generally make very little sense To kick it off, here are some recent developments to share New tools, etc I released skipfish - a ridiculously fast site brute-forcing and security testing tool It is really snappy and generates pretty, interactive reports with virtually no fluff Several people on Twitter reported problems with their scans, but this page covers most of the issues you can run into Of slightly older developments, you may enjoy the Browser Security Handbook or ratproxy Vulnerability research after some painful experiences, I posted a list of upcoming vulnerabilities on my home page, and will try to keep it up to date One of the most notable cases is ref_fuzz - series of exploitable, fuzzer-triggered DOM crashes that remain unfixed in MSIE and Safari almost two years after the inception of the tool Geeky hobbies mechanically-inclined folks may be interested in my 25D imaging project, a cheesy Geiger-Müller mood lamp, or my guerrilla CNC guide I also have some new photos to show http://www.secuobs.com/revue/news/234843.shtmlhttp://www.secuobs.com/revue/news/234843.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - The debate around responsible disclosure is as old as the security industry itself, and unlikely to be settled any time soon Tellingly, both sides of the debate claim to be driven by the same motive - to keep users safe Yet, both accuse the opponent of saying so under false pretenses vendors and businesses see full disclosure proponents as attention whores, while researchers think vendors only care only about PR and legal liability damage control The controversy will continue, and it would be pointless to recapture it here Having said that, I have an issue with one of the common assumptions made in this debate the belief that vulnerabilities are unlikely to be discovered by multiple parties at once, and therefore, the original finder of a flaw is in a unique position to control the information Intuitively, it sounds pretty reasonable security research is hard, and the necessary skills are nearly impossible to formalize or imitate The press, in particular, likes to think of vulnerability finding as an arcane form of art But is it so I found over 200 vulnerabilities in high-profile client- and server-side apps I think it is a pretty good data set to work with - and curiously, I am strongly convinced that none of these findings should be attributed to my unique brilliance or skill, divine intervention, or any other unique circumstances that could not be easily reproduced elsewhere It feels that a vast majority of these findings were just a matter of the security community reaching a certain critical body of knowledge - gaining a better understanding of what can go wrong, where to look for it, and how to automate the testing with simple fuzzers and similar validation frameworks At that point, finding bugs is simply a matter of picking a target to go after who happens to be behind the wheel is largely immaterial What's more, I found that when you go after a sufficiently buggy and complex application, most of the problems you find would turn out to be dupes of what other researchers discovered weeks or months earlier This pattern proved to be particularly prevalent in the browser world, where I had multiple bug collisions with Georgi Guninski or Amit Klein I suspect the same can be said by a vast majority of other security researchers - though not all of them are willing to make the same self-deprecating admission in public Sadly, by enjoying being portrayed as wizards, we are also making it easier for vendors to advocate the view that the discovery of a vulnerability is what creates a threat - and that researchers have an obligation to wait indefinitely to help protect users against attacks While giving a responsive vendor some advance notification is often a good idea, creating a social pressure on researchers to wait for patches removes any incentive for vendors to respond in a timely manner This would not be a problem if vendors were consistently awesome - but they certainly aren't today We are commonly seeing some of the leading proponents of responsible disclosure taking from six months to two years to address even fairly simple, high-risk bugs - and seldom facing any criticism for this Researchers who behave irresponsibly , on the other hand, are routinely called names if they are lucky and are formally or informally threatened if not Vulnerability disclosure, however done, does not make you less secure More often that we are willing to admit, it merely brings out an existing risk from the thriving underground market and into the spotlight Naturally, this can be disruptive in the short run, which is why the practice is controversial it's certainly easier not to have to scramble to fix an issue on a short notice That said, timely and verbose disclosure also levels the playing field by keeping vendors accountable, and giving all users the information needed to limit exposure - even if by stopping to use a particular service until a fix is available http://www.secuobs.com/revue/news/234842.shtmlhttp://www.secuobs.com/revue/news/234842.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - I should soon be able to share several really interesting browser design flaws, but until then, let me kill some more time by getting on the soapbox again There is something interesting going on in the security industry we are witnessing the rapid emergence of vulnerability trading markets Hundreds of security researchers now routinely sell exploits to intermediaries for an easy profit anywhere from 1,000 to 50,000 , instead of talking to the vendors or announcing their findings publicly these intermediaries in turn sell the knowledge to unspecified end users, most likely at several times the original price tag Some intermediaries may eventually release the information to the public others withhold it indefinitely Predictably, the latter bunch is willing to pay you a lot more The interesting part is that both classes of intermediaries often demand weaponized, multi-platform exploits, and not just a nice write-up on the nature of the glitch Apparently, some of their valued customers are less interested in just knowing how to detect the vulnerability or deploy robust workarounds, and want an efficient attack tool instead Why Some use cases in the IDS industry could be strenuously made, but I do not find them all that believable If not this, then what's going on A likely hypothesis is that at the end of the chain, you can find several players who are not exactly benevolent, and have a clear business case to justify the significant expense, or the need to go through multiple hops as opposed to hiring local talent at fraction the price When confronted about this, the intermediaries usually allude to unspecified government agencies - but even if this somewhat uncomfortable claim is true, there is a slight problem the researcher does not get to choose which government he may be aiding with his work Many people find it difficult to sympathize with Jethro's legal troubles he was offered a lot of money, in cash, for an exploit that would rather obviously be used for something illegal or at least morally dubious - and didn't think twice While the proxy arrangement practiced by the industry may superficially look different, I am not sure it really is can the sellers honestly claim they understand who wants these exploits, and why do these tools happen to be so unusually valuable And if not, should we be selling them for a lot of money, no questions asked There is an argument made by Charlie Miller and several other researchers that the vendors should not be entitled to free vulnerability research services from the security community Maybe so - although it's worth noting that researchers profit from that bona fide work by gaining recognition and respect, and landing cool jobs later on vendors gain much less from the extra public scrutiny, and some of them would probably prefer for this arrangement to go away But in any case, I do not think this argument genuinely supports the idea of selling the information to the highest bidder with no regard of how it may be used it may be legal, and it may be profitable, but it certainly does not feel right http://www.secuobs.com/revue/news/234841.shtmlhttp://www.secuobs.com/revue/news/234841.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - Another soapbox infomercial while waiting for vendor patches Sorry I have no idea why this is still unclear THE CURRENT CONTENTS OF THE ADDRESS BAR ARE YOUR ONLY GOD Really There is nothing else browsers do not have any other universal, reliable content origin indicator, and no way to predict where you will be taken next People who do not understand this, or who do not understand the URL syntax, will suffer Over and over again It is fair to note that way too many users fall into this category in fact, even the experts can't always be sure Guess where the following URLs will take you in MSIE, Firefox, and Chrome http examplecom coredumpcx http examplecom coredumpcx Chances are, you got the answers wrong The problem is easy to pin squarely on the users, but it's the geeks who created a huge gap between the skill level needed to proficiently operate a browser, and the skill level required to do so safely The health of the entire networked ecosystem suffers as a result This is one of the great unsolved problems in information security - and it calls for fundamental changes to how web browsers interact with the users and identify sites Alas, not every quick kludge is necessarily a good one careless users will be exactly just as doomed if we outlaw HTTP authentication, change onclick behavior, rework tooltips, or close all the open redirectors in the world The few hundred remaining pages in the relevant RFCs make the world interesting Please, pick your battles wisely http://www.secuobs.com/revue/news/234840.shtmlhttp://www.secuobs.com/revue/news/234840.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - There are quite a few extensive vulnerability databases in existence today While their value in the field of vulnerability management is clear and uncontroversial, a relatively new usage pattern can also be seen the data is being incorporated into high-level analyses addressed predominantly to executive audiences and the media to provide insight into the state of the security industry threat reports from IBM and Symantec are good examples of this Which vendor is the most responsive Who has the highest number of high-risk vulnerabilities These and many other questions are just begging to be objectively answered with a clean-looking pie chart Vulnerability researchers - the people behind the data points used - are usually fairly skeptical of such efforts but their criticisms revolve primarily around the need to factor in bug severity, or the potential for cherry-picking the data to support a particular claim These flaws are avoidable in a well-designed study Are we good, then Well, not necessarily so The most important problem is that today, for quite a few software projects, the majority of vulnerabilities is discovered through in-house testing - and the attitudes of vendors when it comes to discussing these findings publicly tend to vary This has a completely devastating impact on the value of the collected data vulnerability counting severely penalizes forthcoming players, benefits the more secretive ones, and places the ones who do not do any proactive work somewhere in between Consider this example from the browser world in recent years, the folks over at Microsoft started doing a lot of in-house fuzzing, and have undoubtedly uncovered hundreds of security flaws in Internet Explorer and elsewhere It appears to be their preference not to routinely discuss these problems, however - often silently targeting fixes for service packs or other cummulative updates instead In fact, here's an anecdote I reported a bunch of exploitable crashes to them in September 2009, only to see them fixed them without attribution in December that year The underlying flaws were apparently discovered independently during internal cleanups So be it as long as bugs get fixed, we all benefit, and Microsoft is definitely working hard in this area Contrast this approach with Mozilla, another vendor doing a lot of successful in-house security testing in part thanks to the amazing work of Jesse Ruderman They are pretty forthcoming about their results, and announce internal, fuzzing-related fixes almost every month Probably to avoid shooting themselves in the foot in vulnerability count tallies, they tend to report them cummulatively as crashes with evidence of memory corruption, however - and usually assign them a single CVE number to this every month Again, sounds good Lastly, have a look at Chromium several folks are fuzzing the hell out of this browser, too - but the project opts to track these issues individually, partly because the need to coordinate with WebKit developers - and each one of them ends up with a separate CVE entry The result Release notes often look like this All these approaches have their merits - but how do you reconcile them for the purpose of vulnerability counting And, is it fair to compare any of the above players with vendors who do not seem to be doing any proactive security work at all Well, perhaps the browser world is special one could argue that at least some products with matching security practices must exist - and these cases should be directly comparable Maybe, but the other problem is the quality of the databases themselves recent changes to the vulnerability handling process, including the emergence of partial- or non-disclosure, the popoularity of vulnerability trading, and the demise of centralized vulnerability discussion channels, all make it prohibitively difficult for database maintainers to reliably track issues through their lifetime Common problems include The inability to fully understand what the problem actually is, and what severity it needs to be given Database maintainers cannot be expected to be intimately familiar with every product, and need to process thousands of entries every year - but this often leads to vulnerability notes that may at first sight appear inaccurate, hard to verify, or very likely not worth classifying as security flaws at all The difficulty discovering how the disclosure process looked like, and how long the vendor needed to develop a patch This is perhaps the most important metric to examine when trying to understand the performance of a vendor - yet one that is not captured, or captured very selectively and inconsistently, in most of the databases I am aware of The difficulty detecting the moment when a particular flaw is addressed - all the databases contain a considerable number of entries that were not updated to reflect patch status apologies for Chrome-specific examples There seems to be correlation between the prevalence of this problem and the mode in which vendor responses are made available to the general public Furthermore, when a problem is not fixed in a timely manner, the maintainers of the database generally does not reach out to the vendor to investigate why is the researcher's claim contested, or is the vendor simply sloppy This very important distinction is lost Comparable problems apply to most other security-themed studies that draw far-fetching conclusions from simple numerical analysis of proprietary data Pie charts don't immediately invalidate a whitepaper, but blind reliance on these figures warrants a closer investigation of the claims http://www.secuobs.com/revue/news/234839.shtmlhttp://www.secuobs.com/revue/news/234839.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - Researchers say they've devised a way to bypass protections built in to dozens of the most popular desktop anti-virus products, including those offered by McAfee, Trend Micro, AVG, and BitDefender - The Register Sounds familiar For the past three years or so, such headlines have appeared in the press on a fairly regular basis This makes one wonder is there something rotten in the antivirus world After all, of all things, we ought to be able to get the security tools right Well, the picture is more complicated than it may seem We intuitively draw parallels between these findings and the vulnerabilities commonly found in other types of software - but the issue here is very different all consumer-grade antivirus software simply must be designed to be bypassable, even if only transiently so To understand this, we need to realize that there is nothing fundamentally different between a botnet client and a legitimate chat application they both use roughly the same OS facilities in a very similar manner, and while differences are often observed in practice, they are not essential in any way The intent of the actions performed by these two programs is the only distinguishing factor Yet, this property can't be algorithmically assessed - not only because the task is notoriously hard to formalize, but also because automated reasoning about the behavior of computer programs is, in many cases, provably impossible Because of this, the antivirus model is nothing like that of proper security tools Instead of eliminating essential mechanisms depended on by the rogue code, AV software tries to stop specific, previously recorded attack patterns known bad binaries, known suspicious sequences of system calls, and so forth Some heuristics are employed, but in the end, it always comes down to blacklisting - a canonical bad practice in the field of information security Surprisingly, in this particular context, it actually works 1 Most users are not running up-to-date antivirus software - therefore, there is relatively little incentive for attackers to spend too much time on evading the checks As a result, most of the malicious code you can run into will trip existing signatures or simple behavioral heuristics The users of antivirus products remain at a distinct advantage 2 Although a percentage of new malware is created specifically to avoid detection, the two possible outcomes are just as favorable to the users of antivirus products When malware authors aim for rapid, nondiscriminate propagation, the new variant is quickly captured in the wild, and the tools are updated with new signatures or scan algorithms In this case, a majority of users are protected before they come into contact with the new payload When malware authors want to stay under the radar, and only go after select targets, the majority of users are not interesting enough to end up in the crosshairs - and therefore, the problem is highly self-limiting As should be evident, this model works reasonably well to protect casual users It also tends to fall apart for any entity interesting enough to attract specific attention of determined but not necessarily skilled attackers for these targets, antivirus software perhaps reduces operational costs by reducing the likelihood of nuisance infections, but does relatively little to prevent more serious trouble Some of the recent reports of antivirus bypass tricks are interesting this particular research rehashes a problem that all ptrace -based debuggers and sandboxing tools have to deal with - but in light of the above, I am inclined to think they do not constitute a security flaw The attention they nevertheless receive demonstrates that we have only a vague idea of the limitations of AV applications sadly, with poor understanding, come unrealistic expectations - a major foe of any and all security work PS It is frustrating that contemporary computers are so confusing and vulnerable, that we need such a wonderfully imperfect mechanism to protect the casual user to begin with That, however, is a wholly different tale http://www.secuobs.com/revue/news/234838.shtmlhttp://www.secuobs.com/revue/news/234838.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - I am very surprised by the number of reactions to the previous entry in this blog Here are some particularly interesting, full-length responses from my acclaimed peers Ivan Arce Core Security , David LeBlanc Microsoft , Amrit Williams BigFix , Charles Smutz Lockheed Martin I complained about the failings of formal methods, and failed to acknowledge that at times, more pragmatic approaches to security testing work just fine That's true - but allow me to clarify the excerpt comes from an introduction to an upcoming book, and simply explains why the remainder of this work will not focus on any sort of an overarching security engineering paradigm The book indeed advocates simple, technical-minded pragmatism instead Alas, down-to-earth pragmatism seldom moves products off the shelves As a result, our industry is extremely prone to harmful hyperboles - and so, it deserves a mild slap on the wrist This alone makes me think the original post stands on its own merit PS Then, there's a response from David Mortman, complaining about people who complain http://www.secuobs.com/revue/news/234837.shtmlhttp://www.secuobs.com/revue/news/234837.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - Looks like I am finally free to discuss the first interesting browser bug on my list - so here we go I really like this one its history goes back to 1994, and spans several very different codebases The following account is speculative, but probably a pretty good approximation of what went wrong Let's begin with this simple URL http examplecom This syntax demonstrates an unintentional and completely impractical quirk in the URL parsing algorithm specified some 16 years ago in RFC 1630 Verbatim implementations are bound to parse this string as a relative reference to protocol 'http', host base_urlhost, path 'examplecom ' It does not make a whole lot of sense, and indeed, in RFC 3986, Tim Berners-Lee had this to say This is considered to be a loophole in prior specifications of partial URI RFC1630 Its use should be avoided but is allowed for backward compatibility Fast forward two years the KDE team is working on a new open-source browser, Konqueror Their browser uses KURL as the canonical URL parsing library across the codebase This parser behaves in an RFC-compliant way when handling our weird input string, with one seemingly unimportant difference if the current parsing context does not have a valid host name associated with it, the address is not rejected as unresolvable the host name is simply set to an empty string No big deal, right Well, somewhere around 2002, the renderer and the JavaScript engine used in Konqueror - KHTML and KJS - are forked off under the name of WebKit, and become the foundation for Safari The fork contains almost all the necessary core components for a browser, with a notable exception of a built-in HTTP stack - and so, Apple decides to reuse their existing CFNetwork library for this purpose When our special URL finally makes it to this library, it is interpreted in a far more intuitive, but technically less correct way - as protocol 'http', host 'examplecom', path ' ' HTTP cookies and other request parameters are then supplied accordingly The result When you open two windows in Safari - one pointing to http hairy-spiderscom, and the other pointing to http fuzzy-bunniescom - the HTTP stack will make sure they are populated with cookie-authenticated data coming from the two different servers named in the URLs but the same origin checks within the browser will rely on KURL instead Remember how KURL spews out an empty host name in both cases Because empty strings always match, both pages are deemed to be coming from the same source, and can access each other at will Oops Well, there's still a catch this attack will only work as expected if the windows are opened by hand in documents opened from a web page, the host name from the base URL will interfere with how the URLs are broken down Thankfully, we can work around it, simply by hopping through a data URL Reported to the vendor in January 2010, fixed in Safari 41 and 50 APPLE-SA-2010-06-07-1, CVE-2010-0544 A simple and harmless proof-of-concept can be found here http://www.secuobs.com/revue/news/234836.shtmlhttp://www.secuobs.com/revue/news/234836.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - Somewhere in 2008, I created a relatively simple DOM binding fuzzer dubbed ref_fuzz The tool attempted to crawl the DOM object hierarchy from a particular starting point, collect object references discovered during the crawl by recursively calling methods and examining properties, and then reuse them in various ways after destroying the original object In essence, the goal was to find use-after-free conditions across the browser codebase The fuzzer managed to crash all the mainstream browsers on the market at that time, in a number of seemingly exploitable ways Early fixes from Opera and Apple started shipping somewhere in 2008 some more arrived in 2009 Today, Microsoft released a fix and a bulletin for CVE-2010-1259 MS10-035 , while Apple released fixes for CVE-2010-1119 - fixing the last of the scary memory corruption cases attributed to the tool The story of ref_fuzz is interesting, because to some extent, it illustrates the shortcomings of one-way responsible disclosure Were I to release this fuzzer publicly in 2008, it would probably cause some short-term distress - but in the end, vendor response would likely be swift, out of simple necessity this certainly proved to be the case with mangleme, a comparably effective fuzzer I developed 2004 my rebel years In this particular case, however, the appropriate parties were notified privately, with no specific disclosure deadline given This, coupled with the inability to create simple repro cases inherently due to the design of the fuzzer , likely prompted the developers to deprioritize investigating and responding to these flaws - in the end, taking months or years instead of days or weeks Given that they need to respond to hundreds or thousands of seemingly more urgent bugs every year, this is not unexpected What's more troubling is that, within that timeframe, many of the crashes triggered by ref_fuzz were independently rediscovered and fixed several exploitable crashes were patched without attribution by Microsoft in December 2009 MSRC cases 9480jr and 9501jr similarly, several WebKit flaws were rediscovered by Alexey Proskuryakov and addressed in WebKit earlier this year say, bug 33729 , and by Pwn2Own winners shortly thereafter Is it unreasonable to assume that malicious researchers were just as likely to spot these glitches on their own In any case - I am happy to finally release the tool today You can check out the fuzzer here warning clicking on this link may cause your browser to misbehave Update looks like the site is temporarily down Should be back up tomorrow, sorry You can download the fuzzer here until then http://www.secuobs.com/revue/news/234835.shtmlhttp://www.secuobs.com/revue/news/234835.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - This is the third interesting bug I had in my pipeline for a while It's far less scary than the previous ones, but nevertheless, probably amusing enough A while ago, I posted a whimsical proof of concept for what I greatly enjoy calling strokejacking The problem amounts to this a rogue site can put an unrelated, third-party web application in a hidden frame - and then, by offering some seemingly legitimate functionality, entice the user to type in a body of text As the user is typing, the attacker is free to examine key codes from within the onkeydown handler - and when desired, momentarily move focus to said hidden frame, causing the actual onkeypress event to be routed there instead The trick essentially permits arbitrary, attacker-controlled input to be synthesized on the targeted site - possibly changing victim's privacy settings, setting up mail forwarding, or authorizing new users to access personal data The attack is arguably more interesting than your traditional, run-of-the-mill clickjacking, mostly because it allows for more complex interactions Still, in most cases, it can be prevented the same way - with X-Frame-Options or with framebusting JavaScript - so no reason to panic, right Well, there's a twist shortly after reporting this problem publicly several months ago, I realized that the attack scenario could be reversed Consider a third-party gadget or an advertisement framed on a legitimate page, a pretty common pattern today The frame is free to grab focus from the top-level document, as this operation is not governed by the same-origin policy Normally, this causes the caret to disappear from where the user is expecting it to be - but by briefly giving up focus at strategically timed intervals, the appearance of a blinking cursor in the top-level document can be maintained The rogue gadget can then read all the typed characters via onkeydown - and have onkeypress delivered to the top-level document, so that everything seems to be working as expected - with an extra copy of all the data silently delivered to the attacker A simple WebKit-specific proof of concept can be found here The usual clickjacking defenses are not applicable in this scenario, for obvious reasons WebKit bug 26824 Firefox bug 552255 CVE-2010-1422 Update looks like the site is temporarily down Should be back up tomorrow, sorry http://www.secuobs.com/revue/news/234834.shtmlhttp://www.secuobs.com/revue/news/234834.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - The prevalence of cross-site scripting - an unfortunate consequence of how the web currently operates - is one of the great unsolved challenges in the world of information security Short of redesigning HTML from scratch, browser developers are not particularly well-positioned to fix this issue but understandably, they are eager to at least mitigate the risk One of the most publicized efforts along these lines is the concept of browser-side, reflected XSS detectors the two most notable implementations are David Ross' XSS filter shipping in Internet Explorer 8 and Adam Barth's XSS Auditor WebKit browsers - currently in Safari 5 The idea behind these tools is very simple if query parameters seen in the request look suspiciously close to any active portions of the rendered page, the browser should assume foul play - and step in to protect the user Naturally, nothing is that simple in the browser world The major design obstacle is that the check has to be passive - active probes are likely to cause persistent side effects on the server Because of this, the detector can merely look for correlation, but not confirm causation try this or this search in Internet Explorer 8 to see a canonical example of why this distinction matters Since passive checks inevitably cause false positives, the authors of these implementations defaulted to a non-disruptive soft fail mode when a suspicious pattern is detected, the browser will still attempt to render the page - just with the naughty bits selectively removed or defanged in some way While a fair amount of issues with XSS detectors were pointed in the past - from hairy implementation flaws to trivial bypass scenarios - the soft fail design creates some more deeply rooted problems that may affect the safety of the web in the long run Perhaps the most striking example is this snippet, taken from a real-world website Safari puts tags into new elements, so let's account for this here sanitized attacker-controlled data goes here The data displayed there is properly escaped under normal circumstances, this page is perfectly safe But now, consider what happens if the attacker-controlled string is body color expression alert 1 - and q is appended by at the end of the URL The filter employed in MSIE8 will neutralize the initial , resulting in the subsequent tag being interpreted literally - putting the browser in a special parsing mode This, in turn, causes the somewhat perverted CSS parser to skip any leading and trailing text, and interpret the attacker-controlled string as a JavaScript expression buried in a stylesheet Eep This particular case should be fixed by the June security update, but the principle seems dicey The risk of snafus like this aside, the fundamental problem with XSS detectors is that quite simply, client-side JavaScript is increasingly depended upon to implement security-critical features The merits of doing so may be contested by purists, but it's where the web is headed No real alternatives exist, too a growing number of applications uses servers merely as a dumb, ACL-enforcing storage backend, with everything else implemented on client side mechanisms such as localStorage and widget manifests actually remove the server component altogether To this client-heavy architecture, XSS detectors pose an inherent threat they make it possible for third-party attackers to selectively tamper with the execution of the client-side code, and cause the application to end up in an unexpected, inconsistent state Disabling clickjacking defenses is the most prosaic example but more profound attacks against critical initialization or control routines are certainly possible, and I believe they will happen in the future The skeptic in me is not entirely convinced that XSS filters will ever be robust and reliable enough to offset the risks they create - but I might be wrong time will tell Until this is settled, I and several other people pleaded for an opt-in strict filtering mode that prevents the page from being rendered at all when a suspicious pattern is detected Now that it is available, enabling it on your site is probably a good idea http://www.secuobs.com/revue/news/234833.shtmlhttp://www.secuobs.com/revue/news/234833.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - Vulnerability researchers Stated incentive make the world a safer place Key incentives 1 Share cool stuff good researchers are passionate about their area of expertise, and usually are in it mainly for the thrills Like all hobbyists, they are proud of their work, want to share their achievements with others, and be praised for a job well done The security community is unusually tightly knit, compared to IT in general, and is reminiscent of the open source movement 2 Get paid security researchers aim to make a living out of their hobby - be it by establishing and maintaining credentials in the community to land interesting gigs, or by directly trading vulnerability data Outcome of full disclosure policies 1 Relatively frequent disruptive exploitation of unpatched vulnerabilities 2 Greatly reduced window of exposure to security attacks 3 Good accountability for security engineering and response practices 4 Increased risk of regulatory response, establishing vendor liability standards for security flaws Software vendors Stated incentive make the world a safer place Key incentives 1 Protect the integrity of operations security does not directly contribute to revenue, so it is usually impractical to disrupt business processes including release engineering and testing workflows , or alter product lines and support approaches, to allow for rapid security response 2 Don't look bad because 1 almost always results in security response capabilities below what would be expected by customers in distress, companies strive to minimize the visibility of these shortcomings, and discourage non-compliant research practices Failure to do so may result in loss of customer confidence - and eventually, prompt the government to step in Outcome of regulated disclosure policies 1 Fewer large-scale attacks using unpatched vulnerabilities 2 Nearly permanent, large scale susceptibility to non-public flaws for all users 3 Limited accountability for security engineering and response practices 4 Reduced likelihood of regulatory action Nobody in this debate is particularly forthcoming Spengler included, as much as I enjoyed his post , and no solution is perfect Only one of these groups has PR departments, though http://www.secuobs.com/revue/news/234832.shtmlhttp://www.secuobs.com/revue/news/234832.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - Today, EFF announced HTTPS Everywhere - a browser plugin that automatically upgrades all requests to a set of predefined websites, such as Wikipedia, to HTTPS This is done in a manner similar to Strict Transport Security Widespread adoption of encryption should be praised - but the privacy benefits of tools like this are often misunderstood The protocol is engineered to maintain the confidentiality and integrity of a priori private data exchanged over the wire - and does very little to keep your actions private when accessing public content Even with HTTPS, every passive, unsophisticated attacker should be able to exactly tell which Wikipedia page you happen to be interested in looking at packet sizes, direction, and timing patterns for encrypted HTTP requests, he can identify the resource with a high degree of confidence With that particular site, you do not even need to crawl the content on your own database dumps are provided by the foundation, and take a couple of hours to download over DSL Adding some random padding and jitter to the communications will help, but can be only taken so far without introducing a very significant performance penalty Because of this, large-scale behavioral analysis is still likely to be very effective even if we do some of that Naturally, there are situations where HTTPS actually helps with privacy but fewer than we probably come to expect Even the contents of encrypted text typed in by the user can be reconstructed in some fascinating cases, as explored in this research paper from Microsoft http://www.secuobs.com/revue/news/234831.shtmlhttp://www.secuobs.com/revue/news/234831.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - As promised, here's another interesting browser bug, showing the perils of being user-friendly You are probably familiar with the usual behavior of the address bar when you click on a link, the browser keeps showing the old location up until the new content is retrieved and actually replaces the previous page Only Safari behaves differently, always showing the new destination - which I think can be deceptive function clicked w windowopen , blank wdocumentbodyinnerHTML Where do I come from wlocation 'http 1234 ' I don't like this behavior, but it perhaps does not constitute an outright security flaw the spinning throbber is a weak, but visible indicator of foul play But to the point If you look carefully at the remaining browsers, you may also notice a curious exception to the rule when a link is opened in a new window or a tab, most browsers will put the destination URL in the address bar right away Why Apparently, usability is the reason doing this seemed more user-friendly than showing about blank for a couple of seconds Alas, this design decision creates an interesting vulnerability in Firefox the about blank document actually displayed in that window while the page is loading is considered to be same origin with the opener the attacker can inject any content there - and still keep his made up URL in the address bar Well, the spinning throbber is there, right As it turns out, you can make it go away The harder way is to use an URL that legitimately returns HTTP 204 the easier way is to simply call windowstop var w function clicked w windowopen http 1234 , blank , toolbar 1,menubar 1 setTimeout 'wdocumentbodyinnerHTML Fake content wstop ', 500 Reported early April, CVE-2010-1206 Mozilla addressed the glitch in release 364 targets this fix for 366 my bad http://www.secuobs.com/revue/news/234830.shtmlhttp://www.secuobs.com/revue/news/234830.shtml Secuobs.com : 2010-06-24 23:45:43 - lcamtuf's blog - Quite a few thick volumes have been written on the topic of securing corporate environments - but most of them boil down to the following advice 1 Reduce your attack surface by eliminating non-essential services and sensibly restricting access to data, 2 Compartmentalize important services to lower the impact of a compromise, 3 Keep track of all assets and remediate known vulnerabilities in a timely manner, 4 Teach people to write secure code and behave responsibly, 5 Audit these processes regularly to make sure they actually work We have an array of practical methodologies and robust tools to achieve these goals - but we also have a pretty good understanding of where this model falls apart As epitomized by Charlie Miller's goofy catchphrase, I was not in your threat model , the reason for this is two-fold You will likely get owned, by kids reasonably clued people with some time on their hands are and for the foreseeable future will be able to put together a fuzzer and find horrible security flaws in most of the common server or desktop software in a matter of days Modern, large-scale enterprises with vast IT infrastructure, complex usability needs, and a diverse internal user base, are always extremely vulnerable to this class of attackers As a feel-good measure, this discussion is often framed in terms of high-profile vulnerability trade, international crime syndicates, or government-sponsored cyberwarfare - but chances are, the harbinger of doom will be a bored teenager, or a geek with an outlandish agenda they are less predictable than foreign governments, too - so in some ways, we should be fearing them more Compartmentalization will not save you determined attackers will take their time, and will get creative if needs be Compartmentalization may buy a couple of days, but simply can't be designed to keep them away forever, yet keep the business thriving as witnessed by a number of well-publicized security incidents, design compromises and poor user judgment inevitably create escalation paths Past a certain point, proactive measures begin to offer diminishing returns throwing money at the problem will probably never get you to a point where a compromise is unlikely, and the business can go on This is not a cheering prospect - but something we have to live with The key to surviving a compromise may lie in the capability to detect a successful attack very early on The attackers you should be fearing the most are just humans, and have to learn about the intricacies of your networks, and the value of every asset, as they go These precious hours may give you the opportunity to recover - right before an incident becomes a disaster This brings us to the topic of intrusion detection - a surprisingly hard and hairy challenge in the world of information security Most of the detection techniques at our disposal today are inherently bypassable this is particularly true for bulk of the tricks employed by most of the commercial AV, IDS, IPS, and WAF systems I know of And that's where the problem lies because the internals of these tools are essentially public knowledge, off-the-shelf intrusion detection systems often amount to a fairly expensive and often by itself vulnerable tool to deter only the dumbest of attackers A competent adversary, prepared in advance or simply catching the scent of a specific IDS toolkit, is reasonably likely to work around it without breaking a sweat The interesting - and highly contentious - question is what happens when the design of your in-house intrusion detection system becomes a secret Many of my peers would argue this is actually harmful in most contexts, security-by-obscurity does nothing to correct the underlying problems, and merely sweeps them under the rug Yet, I am inclined to argue that in this particular case, it offers a qualitative difference Here's why Let's begin by proposing a single, trivial anomaly detection rule, custom-tailored for our operating environment and therefore, reasonably sensitive and unlikely to generate false positives for example, it could be a simple daemon to take notice of execve calls with stdin pointing directly to a network socket - a common sign of server-targeted shellcode When the architecture is not shared with common commercial tools, external attackers stand a certain chance of tripping this check, and a certain chance of evading it - but this is governed almost solely by having dumb luck, and not by their skill The odds are not particularly reassuring, but are a starting point Now, an insider stands a better chance of defeating the mechanism - an unavoidable if less common problem - but a rogue IT employee is an issue that, for all intents and purposes, defies all attempts to solve it with technology alone Let's continue further down this road perhaps also introduce a simple tool to identify unexpected interactive sessions within encrypted and non-encrypted network traffic or even a tweaked version of bin sh that alerts us to unusual -c or stdin payloads Building on top of this, we can proceed to business logic say, checks for database queries for unusual patterns, or coming from workstations belonging to users not usually engaged in customer support Each of these checks is trivial, and stands only an average chance of detecting a clued attacker Yet, as the chain of tools grows longer, and the number of variables that needs to be guessed perfectly right increases, the likelihood of evading detection - especially early in the process - becomes extremely low Simplifying a bit, the odds of strolling past ten completely independent, 50pourcents reliable checks, are just 1 in 1024 it does not matter whether the attacker is the best hacker in the world or not unless also a clairvoyant For better or worse, intrusion detection seems to be an essential survival skill - and I think we are all too often doing it wrong A successful approach on the uniqueness and diversity - and not necessarily the complexity - of the tools used the moment you neatly package them and share the product with the world, your IDS becomes a 250,000 novelty toy Sadly, large organizations often lack the expertise, or just the courage, to get creative There is a stigma of low expectations attached to intrusion detection in general, to security-by-obscurity as a defense strategy, and to maintaining in-house code that can't generate pie charts on a quarterly basis But when you are a high-profile target, defending only against the dumb attackers in a world full of brilliant ones - some of them driven by peculiar and unpredictable incentives - strikes me as a poor approach in the long run http://www.secuobs.com/revue/news/234829.shtmlhttp://www.secuobs.com/revue/news/234829.shtml