Well, apparently no one planned any information security with the super collider. I love the quote from this guy who is obviously not a security guy “We don’t know who they were but there seems to be no harm done.” Right. No harm done. We’re sorta sure.
Time to buy a tin-foil hat.
An interesting comment recently appeared on my older post about whether or not to use antimalware software. Peter van Dam wondered whether scheduled scans are really necessary, given that anti-malware products scan files as they enter (and sometimes exit) a computer.
He raises a good point, and I’m curious what all of you think? Do you use scheduled scans? If so, why? If not, is it because you’ve decided the same as Peter?
I thought I had posted this link in the past, but it turns out I did not, so ...
Last summer (2007), one of my papers was published in IEEE Security & Privacy, which describes a method for estimating the number of disclosed but unfixed vulnerabilities in some version of software utilizing publicly available data.
The citation reference is:
Jeffrey R. Jones, "Estimating Software Vulnerabilities," IEEE Security & Privacy, vol. 5, no. 4, 2007, pp. 28-32.
IEEE kindly made the paper available online and as a downloadable document here.
Well, I've been in the Xbox Live team for the past 3 days and my head is swimming! I had never thought about all the work that goes into keeping Xbox Live up and operational, but now that I'm here and get to see it, it's pretty remarkable. There is a large team working around the clock to make sure that gamers around the world can get on their Xboxes and have a troublefree experience whenever they want to.
Anyway, I'll have more to post down the road, but right now I'm still focusing on getting my feet underneath me so I can start contributing.
Hello everyone, Celene Temkin here from the MSRC Ecosystem Strategy Team. BlueHat v8: C3P0wned ended a month ago and the success of the con lives on in the outstanding training and networking done between Microsoft employees and external speakers and guests. I'm happy to say the speaker video interviews, podcasts, anecdotes and archives are live on the BlueHat TechNet Page. As promised, we recorded all of Day Two's presentations and we've published them on TechNet for the first time publicly for all to enjoy--so grab your popcorn, 'fluffi bunni' slippers and get to viewing!
As you know by now, Day One sessions were a hybrid of content from in-depth technical security issues to innovative techniques and best practices to use in the information security realm. Day Two focused on the SDL where the Microsoft Security Development Lifecycle (SDL) team hosted sessions emphasizing secure development and testing practices, as well as how to develop with security in mind from the beginning of the software development lifecycle. The BlueHat SDL sessions focused more on proactive and secure development strategies and less on attack techniques.
Notable keynotes included Jon DeVaan, opening the conference on Day One discussing how BlueHat focuses on security and privacy issues facing the entire ecosystem; Day Two was kicked off by Scott Charney, who discussed how to leverage the SDL to discuss not just the threats, but implementing engineering solutions.
Mark your calendars! The next BlueHat is October 22-23, 2009. See you all there.
-Celene Temkin
BlueHat Project Manager
I spent a lot of time trying to think about what to write for a BlueHat pre-conference blog entry and had a pretty hard time focusing on one topic. To handle this, I decided to comment on the state of security.
While I've found plenty of things to be excited about with security, including improved awareness, enhanced vendor responsiveness to issues (although some still lag behind), increasing global awareness of security concerns, etc., I've still found plenty of things to be concerned about.
Security problems of our past rarely disappear for good. You have new progress all the time... new types of bugs, new ways of combating old problems... but you also have old problems coming back into play.
See the GIFAR/Content Ownership stuff, multiple blended threats, hypervisor-based attacks, Clickjacking, Dowd's null pointer exploit, etc., as new attack vectors. ASLR/DEP (whatever else you want to call it) memory protections as a new defense (and of course, Dowd and Sotirov's mad hotness to bypass these mitigations).
See Dan's nasty DNS vulnerability, the SNMP vulnerability, IP stack flaw, etc., as examples of old concerns coming back into play (in dramatic fashion as well). Shoot, there was even a directory traversal flaw recently on Apache Tomcat that reminded me of the old Unicode IIS flaw.
It's concerning that we can't get passed the vulnerabilities of our past. Of course, things keep moving on as well. New technologies have created a wider threat landscape than ever before. Mobile devices, virtualization, and technologies of the future will provide us new challenges. I recently had a client plead with me about virtualized environments saying, "If we can't even secure our physical machines that we can see and touch, how the heck are we going to secure a virtual one that could actually be removed from our company via the network?" A great question, to which I had little in the way of answers.
I will say that while I'm concerned about the cyclical nature of security vulnerability and the potential for even greater vulnerabilities in new technology, I won't be the one to stop innovation, and I'm excited about all of these new technologies. As security researchers/professionals/consultants/whatever, we have to remain vigilant and strive to find vulnerabilities before those who would use them against us. I'm very excited about what I see with security research from a global aspect. I was fortunate enough to speak at Black Hat Japan in Tokyo this year. Beyond the wonderful hospitality of the people of Tokyo, I was also impressed by a few of the native Japanese speakers and what they brought to the table. Some of the discussion around Japanese-based character encoding brought up some interesting research thoughts for myself.
I doubt that research and new defense technologies will ever outpace the growth of new technology and new threats. I also doubt that we'll be able to prevent old concerns from coming back to life, but we're on the verge of making major strides here. Security is, as always, an arms race... it's one we might never win completely, but maybe we can catch up a good deal if we stay vigilant.
-Nate Mcfeters, Ernst & Young
Hello,
This is Scott Stender and Alex Vidergar from iSEC Partners, and our topic for BlueHat is Concurrency Attacks in Web Applications. Database administrators, computer architects, and operating system designers have spent decades solving the problems that arise from concurrency as they apply to their respective technologies, so this should be old, boring stuff, right?
If you are a web application developer, let’s start with a quick question: Is accessing session variables in your web application framework thread-safe? If you don’t know the answer off the top of your head, don’t worry – you are not alone!
Web application developers are caught in the middle of two powerful forces: productivity and abstraction.
Developer productivity reduces costs and can be credited with removing drudgery from programming tasks. In the web application world, the pursuit of productivity has yielded a parade of easy-to-use web application frameworks. No longer do the web developers of the world manage connections and thread pools, they can focus on the creative aspects of their profession. Modern frameworks require the programmer to implement a single function using a handful of APIs, and presto, a fully interactive web page is born.
In order to achieve this, however, we need abstraction. All of the "plumbing" that goes into making a web page work has to be hidden in the web application framework and web server, which means that the average web developer does not have to worry about it, or know it is even there. Furthermore, most of those frameworks are written in an object-oriented manner, meaning that abstraction is more than just a luxury, it is a key tenet of the programming environment.
There’s the problem: When abstraction of such resources is a requirement of the programming environment, we should expect trouble. Because of abstraction, developers can be unaware of resources shared across threads, processes, or servers and will fail to protect them.
As you may have guessed, we have found more than a few instances where well-meaning developers can easily introduce concurrency flaws into their web applications. The problems themselves are difficult to identify, reproduce and can carry a hefty security impact. Our goal is to provide guidance for developers and testers to identify and address this class of flaw. And, with a roomful of people responsible for creating the very technologies we are discussing, we anticipate a healthy discussion on how this problem can be best addressed by security analysts and developers alike.
-Scott Stender and Alex Vidergar, iSEC Partners.
Now, back before there were things such as accurate soil analysis instruments, there was still prospecting. It just wasn’t all that efficient. Just like in security, we’ve been finding bugs through laborious and often gut-instinct driven processes that are simply inefficient. Lately, I’ve been thinking hard about this problem and pooling resources with professionals in the security field as well as academics in the visualization field. I recently had the honor of participating on a panel at VizSec, which is held at MIT, and had presenters and attendees that stretched the globe bringing their heads together to see where visualization is going. The observation I made was that the network security folks are thinking a lot harder about visualization than those specializing in software security and I think I understand why: network data has many concrete properties that are readily consumed by existing data analysis functions and data visualization software. That is to say, they know some of the trends they’re looking for and those values are typically very literal, such as who is sending packets where and of what type, etc. I found myself trying to create parallel scenarios that would fit software security and program analysis and there certainly are some to be found (such as reachability on a graph), however for the most part, software security analysis is facing different problems due to a lack of metrics that can be plugged into functions that find trends.
So, what does this mean to software security prospectors like us in the context of visualization? It means that we need to define metrics that can be measured and then presented visually, of course! There are some good articles you can dig up from ACM on the topic, but one basis for my work has been Matt Miller’s paper titled “Improving Software Security Analysis using Exploitation Properties”. Matt’s paper introduces the concept of exploitation properties which are specific metrics that can be interpreted together to get a sense of whether an area of code is at higher risk of exploitation if a bug is present – you’re going to exploit the stack overflow that isn’t protected by GS before you try to work around the one that is protected with GS, right? Expand this concept a bit and you can begin to collect metrics beyond exploitability that may help improve software security or maintainability.
So my upcoming talk at BlueHat will focus on two areas of concern: what do these metrics look like and what do proper visualizations of multi-dimensional data look like. We have some interesting challenges because not all of our metrics are as reliable as others. In fact, off-the-shelf bug finding tools are often heuristic based and can be highly unreliable, but that just means we have a unique opportunity to take large data sets and correlate them to find out where the real gold is buried.
-Richard Johnson, Security Software Development Engineer, Trustworthy Computing, Microsoft
Another six months has passed – must be time for BlueHat, Microsoft’s internal security conference.
This one is shaping up to be an interesting one. The early BlueHats were all about the raw technology – Shok blowing out the memory manager, Brett Moore facepalming over yet another file format vulnerability. But determining vulnerability requires more than just understanding technology. At the end of the day, there are bad guys, and bad guys don’t necessarily have to take the geekiest of routes to get what they want. So there’s an interesting thread that appears to run through many of the talks this year, linking what we are capable of doing as engineers, with what attackers have been doing as criminals.
For my part, I’ll be talking (unsurprisingly) about the DNS vulnerabilities that made a bit of noise earlier this summer. That was quite the experience, and indeed, continues to be. DNSSEC is making astonishing progress – there’s no question about that. It’s also not going to be deployed on 99% of authoritative servers anytime soon – even .GOV is looking at two years to get coverage across their bailiwick. And the numbers for the pragmatic fix (Source Port Randomization) continue to be astonishingly good. But there is indeed demand for better, and one of the interesting things I’ll be able to discuss is:
What now? What should the next interim fix look like? What is the full set of scenarios that needs to be covered, to justify going through another patch cycle? What sort of real-world deployments do we need to be compatible with?
And why do we have to fix this, anyway? Why are so many things broken, to the point that they fail trivially when attacked by a basic man-in-the-middle?
These are hard questions. The answers to them are not all to be found in DNS, or even just in technology. What has been a clear and fascinating realization is that not just this one vulnerability, but all the major vulnerabilities of 2008 have all been linked to a complete failure to authenticate. Whether it’s Mike Perry finding that many (most?) SSL sites leak their authentication cookies out to unencrypted parties, or it’s Mike Zusman finding that many (most?) SSL-VPN’s don’t actually validate that they’re encrypting their payloads to anyone in particular, or it’s Wes Hardakar finding out that SNMPv3 barely makes a user authenticate at all – a remarkable number of problems are all being found that trace back to us having no idea who we’re talking to.
Identity is not, and never will be, merely a problem of technology. It will take tech to fix – but it will take something more, too. It will take some work to figure out exactly what that something will be – but we have at least one significant data point showing a shocking number of companies expending a tremendous amount of effort, all in pursuit of doing the right thing for themselves and for their customers. We can, and should, learn from this experience, and I look forward to exploring this all at BlueHat.
Dan Kaminsky, IOActive
