I'm not assuming that at all. I explained the process in more detail in my previous post (http://it.slashdot.org/comments.pl?sid=157252&cid =13184604 ) but I didn't want to repeat myself. I suppose I should have should have thrown the link in.
The funniest thing though, is that this isn't even a true vulnerability in the strict sense. It demonstrates how to circumvent certain protection mechanisms to build a more reliable exploit for an existing vulnerability. What's more, Cisco was very obviously trying to address the concern, but resolving the issue was taking time. With that in mind, I'm not sure how you can even make the argument that full disclosure was necessary at this time.
They can when they hire independent security firms to perform code assessments, especially when they have enough weight to press the vendor into cooperating. This actually happens regularly with Fortune 50 companies these days, and the process is only growing. They're just tired of getting burned by the vendors so they've started pushing back.
I expect you've never had to help a vendor fix any complex security issues before. A week may not be enough time for the regression testing of any moderately complex issue, much less developing a fix. And seriously, D.J. Bernstein is considered a mildly psychotic zealot by much of the IT security community. I have the utmost respect for his technical ability, but his views on handling security issues can best be described as "slash and burn."
This is completely false. With responsible diclosure the vendor is notified and given adequate time to develop and distribute a patch. Assuming things are coordinated properly the researcher releases their findings in conjunction with the patch. Some times the vendors do exceed what the researcher considers an adequate amount of time. In that case it is the researcher's perogative to distribute the findings in order to press the vendor into acting. Either way, the researcher always takes public credit for their work and it is not a secret process.
Your comment about needing "carnage" to press a business into action was often true five years ago, but it is rarely the case now. The present business climate is not accepting of security flaws and big businesses often press the vendors these days. This and other factors have made vendors far more receptive to addressing security concerns.
That was true a few years ago, but its rarely the case these days. Once you contact the correct people at the vendor they generally move fairly quickly to resolve the issue. Independant researchers can contact CERT and they'll handle all of this legwork for you and make sure you get the credit. Of course the patching process still takes time for development, porting across platforms, and regression testing. So you do have to cut the vendors some slack.
In the case of ISS there's almost no excuse for not getting some serious cooperation from the vendor. ISS has the weight and all the contacts they need to notify the vendors and get a fairly quick response. This was either an extreme circumstance, or Michael had another job lined up and he wanted to exit with a big splash. For that matter, he may have just made enough noise about his Blackhat presentation that he didn't want to have to pull it back.
On an entertaining side note, Blackhat actually reburned all the CD's and cut his section out of the convention notes. Cisco must have come down pretty heavy for them to pull such a strong CYA move.
Isn't this the same guy who was trying to argue that there is no vulnerability in running as root all the time? Honestly, his reality distortion talent could give Jobs a run for his money.
Because the issues with 1.0.5 were identified before they released it for auto-update, so it never went out. This was also explained ad nauseum in yesterday's article.
This problem is not unique to Mozilla, even MS publishes guidance on how to avoid memory leaks in JavaScript and VBScript. This generally occurs because of circular references or hanging on to unnecessary references to large objects. So, while it is an issue, you have to consider what the cause is and how much the application can prevent it.
Except a good attorney bills by the hour plus retainer, and that will cost you at least several hundred. Which is, of course, fine if you have the intent of doing business based on your idea. But I genuinely appreciate the value of boiler-plate licenses. They are an attempt to bring the law down to the layman's level and not continue paying lawyers to further complicate it.
If this was a VHS versus Betamax style debate than one standard would be proprietary and carry heavy licensing fees. That, and the shorter recording times, are the reasons why Beta lost out to VHS. This issue is simply a question of whether or not a derivative standard improves on, and thus should replace, a previous standard.
Yes, both Visual C++ and the GCC ProPolice extensions provide stack and heap protection. And in general these techniques have a minimal impact on execution speed. Unfortunately, this does not solve the problem. There are still viable attacks that can be preformed by avoiding the stack canaries or heap allocation headers and overwriting other vulnerable data. The probability of developing a successful exploit is lower, but it's still there.
I don't disagree that building secure applications is hard, but it's certainly not impossible. Modularized code just adds another layer of compilcation and potentially confusion. Most of this can be addressed by documenting the design and interface constraints, and ensuring that they're followed. At that point even most security vulnerabilities are primarily implementation defects. Defects will of course still occur, but the trick is to build systems that fail gracefully.
Developers must to account for defects and expect that every form of security protection will fail given enough time and effort. This is why the concept of "Defense in Depth" is so important. By layering protective measures you provide a level of security such that multiple layers have to fail before a compromise becomes truly serious. Combine that with logging and monitoring, and a successful attack while usually be identified before damage is done.
Take the above vulnerabiliy and assume it exists in an exploitable form in a web app running on Apache with a Postgres backend. If the server had been configured from a "Defense in Depth" perspective it would be running in a chroot jail as a low privilege account. Any database access required would be performed through a set of stored procedures or a middleware component that validates the user session and restricts data access. SELinux or GRSecurity would be used for fine grained user control on all running processes. All executables would also be compiled with stack and buffer protection.
In the above scenario, you see that this single exploit wouldn't get you much. However, most systems are deployed with one layer of security, and that's the problem.
So now I'm making my second off-topic post on this story and I apologize. I just noticed that someone duped my post above as a reply to an earlier post so it looks like theirs proceeds mine. You can tell by the time stamps, but now my original post is getting modded down redundant. Has anyone else had this happen and is just a new troll trick?
I realize this is offtopic and will risk getting modded down, but why are you duping my post word for word an hour later? Is this karma theft instead of karma whoring? It actually seems to work because you got modded up and I got modded down "redundant."
I assume that you just wait for a higher rated post to scroll off the first page and then repost at the top. I am curious on why you'd even bother though. Are you just trying to game the mods and see if they're paying attention? It seems like an odd hobby.
I totally agree. I appreciate the Make post on how it works, but this product is taking throw away culture to an extreme. The convenience can't possibly be worth all the manufacturing and materials going into a single hot cup of cofee. And given the way it's packaged, there's no way you're going to reasonably recycle any of this. This is so wasteful it honestly offends me.
That's not quite true; XUL is just the user interface markup. Mozilla (FF, TB, SM, etc.) extensions can be written in JavaScript or C/C++. The Thunderbird Enigmail extension, for example, contains numerous binary components and requires a seperate install per OS.
Laws do exist, but the simple reality is that most whistle blowers still get screwed and are never able to work in their respective industry again. That's probably why he tried to resolve the problem internally first, although creating a paper trail exposing misconduct can scare management just as bad.
I truly hope no one takes this advice. First off, your suggestions rely entirely on blacklist and signature protections. The security community has been telling people for years that blacklisting and signatures are not a proper substitute for whitelisting and access control.
Your solution also allows a potentially infinite number of attack vectors and the only reason why it may have worked to this point is that there is still lower hanging fruit than you. It's like the old joke about outrunning a bear. You don't have to be faster than the bear, just the guy next to you. In this case though, the bear will eventually keep coming.
What's worse is that your solution is even more complex and less effective than running as a LUA. For instance, the practices you've suggested should almost cripple IE to the point of unusability. Why didn't you just suggest running another browser? And what happens when you play an online game or view a hostile email or attachment that isn't in your AV or spyware sigs? What about some as yet unknown vulnerability in any client software? Worse yet, what happens when someone runs an attack against your AV or spyware apps themselves?
I realize you were trying to be helpful, but please do not ever suggest this advice to anyone again. LUA protects against known and unknown attacks with a strong model enforced by the kernel. Your suggestions, on the other hand, raise the security bar just high enough to give a completely false sense of safety.
I think you're over-simplifying this. The Windows NT kernel and core services were designed with security in mind. The real issue is that the shell, UI, and API's do a really poor job of enforcing and providing convenient access to that model. MS made a tough choice when they created they Win32 API; they kept developer compatability and convenience but made security a whole lot harder. There are too many default behaviors in Windows that are just dangerous.
Look how CreateProcess will progressively search for an executable at each space delimited chunk in an unquoted path; that makes a great trojan attack. Consider the shatter vulnerability and associated dangers that result from simple window input; that's why services have to be run on a seperate ACL'd desktop to be safe. Consider how trivially a power user can escalate to admin; look at how many apps need at least that privelege. Look how much code you have to write to set a simple multi-user DACL on an object.
The fact is that security is very hard to do properly in an MS environment, and historically MS has done a very poor job of promoting and simplifying it. I audit security software now, but when I wrote software I had a ton of homegrown libraries to handle things shouldn't have been necessary. So while I agree the tools are there, you almost have to be a security expert to use them properly.
Lets not forget software just failing to work. Most third party applications simply will not run correctly in an LUA environment. Honestly, most MS software couldn't run this way before 2000. I run LUA and I have to use runas admin on far too many applications; how is that really LUA? And lets not forget that running IE with reduced rights will also cause many IE plugins and any IStream handoffs (like Media Player) to fail without explanation.
Of course, I totally agree that they claim of lack of user awareness when it is really a lack of MS support. Microsoft has also done nothing to simplify this issue for developers. There are no simple "test and prompt for elevation" routines. It's not a general Windows logo requirement; in fact it's buried in one paragraph in the enterprise logo. And to top it all off, aside from a few proactive devs making blog entries, there's been no attempt to educate users.
Way to go MS, blame user apathy for your own poor performance.
I know the Mozilla devs were talking about this a few weeks back on one of the lists. They said they didn't consider it a severe security issue yet, but were working on the engine so that popups would be tab and window modal. They've also added pieces to the plugin interface so that plugin developers (Flash and Java for instance) can honor Mozilla's popup blocking.
Currently, if you're popup blocking for all but trusted sites you should be relatively safe from this. It really is hard to prevent phishing attacks though. They attack the users judgement, which unfortunately tends to be the weakest link.
Honestly I think the parent was commenting on the practice of buying out the competition. Or, more acurately in this case, buying up a supplier for the competition so you can cut their legs out from under them. On a larger scale it's the exact kind of practice that prompted the creation of anti-trust laws in the US. Of course this is a niche product, so I'd leave it to a lawyer to determine how much anti-trust law applies.
The issue is that the interfaces aren't completely solidified. For instance, plugging some of the Javascript security issues in 1.0.2 required breaking several extensions that relied on those interfaces. The devs have said that the extension versioning will become less of an issue once the existing interfaces have been locked. Unfortuneately there's still quite a bit of active development in that area.
It's either this approach, or the backwards compatability at all costs mantra that made Microsoft a target for years. One must accept some compromises. Though I thought the sarcasm was a bit heavy too.
Opera style "page zoom" should be possible in 1.5, so you may eventually get your wish anyway. It's just not really practical with the current rendering engine.
The logic is that after a patch has been released it is much easier to identify the vulnerability by analyzing the differing code between the original app and the patch (Google on Halvar Flake and BinDiff for more info). Combine this with researchers that still release sample exploit code, and you can see where they're coming from. By using a fixed release schedule MS feels that it reduces the chance of a publicly available exploit before enterprise customers can deploy the fix. MS switched to this approach because their biggest customers were clamouring for it.
By the way, just because I understand the reasoning behind the policy doesn't mean I necessarily agree with it. I know in many cases it's just used by IT departments as a way to salvage their metrics, which in my mind points to a broken process. But it is important to understand the complexity of the issue, and having unscheduled downtime several times a week is usually not feasible for the enterprise.
String handling is not not the only kind of parser attack, and buffer safe routines do not necessarily protect you from the full range of buffer issues that can occur. Integer issues in particular are a growing concern even with buffer safe libraries. Your average programmer does not have an in depth understanding of the C standard on things like type promotion and sign extension. Google on David LeBlanc's SafeInt library and look over the code for some in depth understanding of this.
Of course, there's a lot of fertile territory in parsers for all sorts of non-buffer related exploits. Cross domain context and external includes were both used in the most recent Firefox exploits. These issues are not unique to XML and HTML formats. I've seen exactly the same problems occur in binary OLE document handlers. This is why I stated that the parsers as a whole are complex issues. They touch so many areas and intermingle so many other concerns that they can be a security nightmare.
Slashdot Mirror
I'm not assuming that at all. I explained the process in more detail in my previous post (http://it.slashdot.org/comments.pl?sid=157252&cid =13184604 ) but I didn't want to repeat myself. I suppose I should have should have thrown the link in.
The funniest thing though, is that this isn't even a true vulnerability in the strict sense. It demonstrates how to circumvent certain protection mechanisms to build a more reliable exploit for an existing vulnerability. What's more, Cisco was very obviously trying to address the concern, but resolving the issue was taking time. With that in mind, I'm not sure how you can even make the argument that full disclosure was necessary at this time.
They can when they hire independent security firms to perform code assessments, especially when they have enough weight to press the vendor into cooperating. This actually happens regularly with Fortune 50 companies these days, and the process is only growing. They're just tired of getting burned by the vendors so they've started pushing back.
I expect you've never had to help a vendor fix any complex security issues before. A week may not be enough time for the regression testing of any moderately complex issue, much less developing a fix. And seriously, D.J. Bernstein is considered a mildly psychotic zealot by much of the IT security community. I have the utmost respect for his technical ability, but his views on handling security issues can best be described as "slash and burn."
This is completely false. With responsible diclosure the vendor is notified and given adequate time to develop and distribute a patch. Assuming things are coordinated properly the researcher releases their findings in conjunction with the patch. Some times the vendors do exceed what the researcher considers an adequate amount of time. In that case it is the researcher's perogative to distribute the findings in order to press the vendor into acting. Either way, the researcher always takes public credit for their work and it is not a secret process.
Your comment about needing "carnage" to press a business into action was often true five years ago, but it is rarely the case now. The present business climate is not accepting of security flaws and big businesses often press the vendors these days. This and other factors have made vendors far more receptive to addressing security concerns.
That was true a few years ago, but its rarely the case these days. Once you contact the correct people at the vendor they generally move fairly quickly to resolve the issue. Independant researchers can contact CERT and they'll handle all of this legwork for you and make sure you get the credit. Of course the patching process still takes time for development, porting across platforms, and regression testing. So you do have to cut the vendors some slack.
In the case of ISS there's almost no excuse for not getting some serious cooperation from the vendor. ISS has the weight and all the contacts they need to notify the vendors and get a fairly quick response. This was either an extreme circumstance, or Michael had another job lined up and he wanted to exit with a big splash. For that matter, he may have just made enough noise about his Blackhat presentation that he didn't want to have to pull it back.
On an entertaining side note, Blackhat actually reburned all the CD's and cut his section out of the convention notes. Cisco must have come down pretty heavy for them to pull such a strong CYA move.
Isn't this the same guy who was trying to argue that there is no vulnerability in running as root all the time? Honestly, his reality distortion talent could give Jobs a run for his money.
Because the issues with 1.0.5 were identified before they released it for auto-update, so it never went out. This was also explained ad nauseum in yesterday's article.
This problem is not unique to Mozilla, even MS publishes guidance on how to avoid memory leaks in JavaScript and VBScript. This generally occurs because of circular references or hanging on to unnecessary references to large objects. So, while it is an issue, you have to consider what the cause is and how much the application can prevent it.
Except a good attorney bills by the hour plus retainer, and that will cost you at least several hundred. Which is, of course, fine if you have the intent of doing business based on your idea. But I genuinely appreciate the value of boiler-plate licenses. They are an attempt to bring the law down to the layman's level and not continue paying lawyers to further complicate it.
If this was a VHS versus Betamax style debate than one standard would be proprietary and carry heavy licensing fees. That, and the shorter recording times, are the reasons why Beta lost out to VHS. This issue is simply a question of whether or not a derivative standard improves on, and thus should replace, a previous standard.
Yes, both Visual C++ and the GCC ProPolice extensions provide stack and heap protection. And in general these techniques have a minimal impact on execution speed. Unfortunately, this does not solve the problem. There are still viable attacks that can be preformed by avoiding the stack canaries or heap allocation headers and overwriting other vulnerable data. The probability of developing a successful exploit is lower, but it's still there.
I don't disagree that building secure applications is hard, but it's certainly not impossible. Modularized code just adds another layer of compilcation and potentially confusion. Most of this can be addressed by documenting the design and interface constraints, and ensuring that they're followed. At that point even most security vulnerabilities are primarily implementation defects. Defects will of course still occur, but the trick is to build systems that fail gracefully.
Developers must to account for defects and expect that every form of security protection will fail given enough time and effort. This is why the concept of "Defense in Depth" is so important. By layering protective measures you provide a level of security such that multiple layers have to fail before a compromise becomes truly serious. Combine that with logging and monitoring, and a successful attack while usually be identified before damage is done.
Take the above vulnerabiliy and assume it exists in an exploitable form in a web app running on Apache with a Postgres backend. If the server had been configured from a "Defense in Depth" perspective it would be running in a chroot jail as a low privilege account. Any database access required would be performed through a set of stored procedures or a middleware component that validates the user session and restricts data access. SELinux or GRSecurity would be used for fine grained user control on all running processes. All executables would also be compiled with stack and buffer protection.
In the above scenario, you see that this single exploit wouldn't get you much. However, most systems are deployed with one layer of security, and that's the problem.
So now I'm making my second off-topic post on this story and I apologize. I just noticed that someone duped my post above as a reply to an earlier post so it looks like theirs proceeds mine. You can tell by the time stamps, but now my original post is getting modded down redundant. Has anyone else had this happen and is just a new troll trick?
I realize this is offtopic and will risk getting modded down, but why are you duping my post word for word an hour later? Is this karma theft instead of karma whoring? It actually seems to work because you got modded up and I got modded down "redundant."
I assume that you just wait for a higher rated post to scroll off the first page and then repost at the top. I am curious on why you'd even bother though. Are you just trying to game the mods and see if they're paying attention? It seems like an odd hobby.
I totally agree. I appreciate the Make post on how it works, but this product is taking throw away culture to an extreme. The convenience can't possibly be worth all the manufacturing and materials going into a single hot cup of cofee. And given the way it's packaged, there's no way you're going to reasonably recycle any of this. This is so wasteful it honestly offends me.
That's not quite true; XUL is just the user interface markup. Mozilla (FF, TB, SM, etc.) extensions can be written in JavaScript or C/C++. The Thunderbird Enigmail extension, for example, contains numerous binary components and requires a seperate install per OS.
Laws do exist, but the simple reality is that most whistle blowers still get screwed and are never able to work in their respective industry again. That's probably why he tried to resolve the problem internally first, although creating a paper trail exposing misconduct can scare management just as bad.
I truly hope no one takes this advice. First off, your suggestions rely entirely on blacklist and signature protections. The security community has been telling people for years that blacklisting and signatures are not a proper substitute for whitelisting and access control.
Your solution also allows a potentially infinite number of attack vectors and the only reason why it may have worked to this point is that there is still lower hanging fruit than you. It's like the old joke about outrunning a bear. You don't have to be faster than the bear, just the guy next to you. In this case though, the bear will eventually keep coming.
What's worse is that your solution is even more complex and less effective than running as a LUA. For instance, the practices you've suggested should almost cripple IE to the point of unusability. Why didn't you just suggest running another browser? And what happens when you play an online game or view a hostile email or attachment that isn't in your AV or spyware sigs? What about some as yet unknown vulnerability in any client software? Worse yet, what happens when someone runs an attack against your AV or spyware apps themselves?
I realize you were trying to be helpful, but please do not ever suggest this advice to anyone again. LUA protects against known and unknown attacks with a strong model enforced by the kernel. Your suggestions, on the other hand, raise the security bar just high enough to give a completely false sense of safety.
I think you're over-simplifying this. The Windows NT kernel and core services were designed with security in mind. The real issue is that the shell, UI, and API's do a really poor job of enforcing and providing convenient access to that model. MS made a tough choice when they created they Win32 API; they kept developer compatability and convenience but made security a whole lot harder. There are too many default behaviors in Windows that are just dangerous.
Look how CreateProcess will progressively search for an executable at each space delimited chunk in an unquoted path; that makes a great trojan attack. Consider the shatter vulnerability and associated dangers that result from simple window input; that's why services have to be run on a seperate ACL'd desktop to be safe. Consider how trivially a power user can escalate to admin; look at how many apps need at least that privelege. Look how much code you have to write to set a simple multi-user DACL on an object.
The fact is that security is very hard to do properly in an MS environment, and historically MS has done a very poor job of promoting and simplifying it. I audit security software now, but when I wrote software I had a ton of homegrown libraries to handle things shouldn't have been necessary. So while I agree the tools are there, you almost have to be a security expert to use them properly.
Lets not forget software just failing to work. Most third party applications simply will not run correctly in an LUA environment. Honestly, most MS software couldn't run this way before 2000. I run LUA and I have to use runas admin on far too many applications; how is that really LUA? And lets not forget that running IE with reduced rights will also cause many IE plugins and any IStream handoffs (like Media Player) to fail without explanation.
Of course, I totally agree that they claim of lack of user awareness when it is really a lack of MS support. Microsoft has also done nothing to simplify this issue for developers. There are no simple "test and prompt for elevation" routines. It's not a general Windows logo requirement; in fact it's buried in one paragraph in the enterprise logo. And to top it all off, aside from a few proactive devs making blog entries, there's been no attempt to educate users.
Way to go MS, blame user apathy for your own poor performance.
I know the Mozilla devs were talking about this a few weeks back on one of the lists. They said they didn't consider it a severe security issue yet, but were working on the engine so that popups would be tab and window modal. They've also added pieces to the plugin interface so that plugin developers (Flash and Java for instance) can honor Mozilla's popup blocking.
Currently, if you're popup blocking for all but trusted sites you should be relatively safe from this. It really is hard to prevent phishing attacks though. They attack the users judgement, which unfortunately tends to be the weakest link.
Honestly I think the parent was commenting on the practice of buying out the competition. Or, more acurately in this case, buying up a supplier for the competition so you can cut their legs out from under them. On a larger scale it's the exact kind of practice that prompted the creation of anti-trust laws in the US. Of course this is a niche product, so I'd leave it to a lawyer to determine how much anti-trust law applies.
The issue is that the interfaces aren't completely solidified. For instance, plugging some of the Javascript security issues in 1.0.2 required breaking several extensions that relied on those interfaces. The devs have said that the extension versioning will become less of an issue once the existing interfaces have been locked. Unfortuneately there's still quite a bit of active development in that area.
It's either this approach, or the backwards compatability at all costs mantra that made Microsoft a target for years. One must accept some compromises. Though I thought the sarcasm was a bit heavy too.
Opera style "page zoom" should be possible in 1.5, so you may eventually get your wish anyway. It's just not really practical with the current rendering engine.
The logic is that after a patch has been released it is much easier to identify the vulnerability by analyzing the differing code between the original app and the patch (Google on Halvar Flake and BinDiff for more info). Combine this with researchers that still release sample exploit code, and you can see where they're coming from. By using a fixed release schedule MS feels that it reduces the chance of a publicly available exploit before enterprise customers can deploy the fix. MS switched to this approach because their biggest customers were clamouring for it.
By the way, just because I understand the reasoning behind the policy doesn't mean I necessarily agree with it. I know in many cases it's just used by IT departments as a way to salvage their metrics, which in my mind points to a broken process. But it is important to understand the complexity of the issue, and having unscheduled downtime several times a week is usually not feasible for the enterprise.
String handling is not not the only kind of parser attack, and buffer safe routines do not necessarily protect you from the full range of buffer issues that can occur. Integer issues in particular are a growing concern even with buffer safe libraries. Your average programmer does not have an in depth understanding of the C standard on things like type promotion and sign extension. Google on David LeBlanc's SafeInt library and look over the code for some in depth understanding of this.
Of course, there's a lot of fertile territory in parsers for all sorts of non-buffer related exploits. Cross domain context and external includes were both used in the most recent Firefox exploits. These issues are not unique to XML and HTML formats. I've seen exactly the same problems occur in binary OLE document handlers. This is why I stated that the parsers as a whole are complex issues. They touch so many areas and intermingle so many other concerns that they can be a security nightmare.