6 ms·
Not true. Product liability lawsuits have been around for ages. It's just that the tech industry has been able to escape them, by and large. I think one of the
by mikec3010 8y ago
Not true. Product liability lawsuits have been around for ages. It's just that the tech industry has been able to escape them, by and large. I think one of the greater injustices in business was Microsoft's avoidance of a lawsuit from their spate of windows malware from roughly 2003-2010. They just sat on their hands and let for-profit A/V companies and nonprofit volunteers secure their platform, while consumers lost millions of hours and billions of dollars to simply be able to use their computers again after being rooted by 4 lines of JavaScript
- vntok 8y ago> after being rooted by 4 lines of JavaScript Could you provide any sort of source for this extraordinary claim of yours?
- jwalton 8y agoThat's probably an exaggeration, but I agree with the sentiment of what they are saying. It's not crazy hard to write quality software. Most corporations don't bother because they know they don't have to, since they can escape liability laws. It's gotten to the point where most software developers somehow view this situation as "normal". Do you have a QA department? What do they do? If you're like most software companies, they do testing. This is not QA, though, it's QV. The role of QA is to assure that the quality of your product is high. By the time you're testing it, the product is "done" - all of the defects are already there in the product. There is now nothing you can do to affect the quality of the product - all you can do is test and measure the overall quality of the product. I mean, your tests will find problems, and you can fix those problems. But, if you keep track of how many problems you find, and how much test effort was involved to find those problems, you can plot a weibull regression and make a prediction about how many defects you haven't found yet. On any project I've been on where we ran this analysis, it was obvious that testing was finding almost none of the problems - barely skimming the surface. And, when you ran this analysis you could predict how many defects you will find if you spend X days testing, and on any project where I've seen this analysis run, those predictions have been highly accurate. Really good automated tests can help with this, because they can do huge amounts of test effort "for free", but really QA should be about the process you follow when you write software - making sure you have a repeatable process, and then figuring out how to improve it. Almost no one does this.
- freeone3000 8y agoThis sounds like it's really expensive, and hard to prove the benefits of to most purchasers. I doubt we'll get the sort of industry change this would require without since strong formalization of the discipline.
- Nomentatus 8y agoI'm not sure whether you think a line of JS calling out to load a remote procedure would have been extraordinary, a root via a browser would have been extraordinary, any remote rootkit load would have been extraordinary, or whether the fact that it used to be possible to root Windows seems extraordinary. I'm no expert but none of this seems extraordinary to me. Things was loose in those days.
- mikec3010 8y agoSource: The extraordinarily large amount of PCs I fixed for people during that era.
- RyanZAG 8y agoHere's a fairly recent one, I guess. The 3 lines of javascript do most of the work. https://nakedsecurity.sophos.com/2013/10/11/anatomy-of-an-exploit-ie-zero-day-part-1/ https://nakedsecurity.sophos.com/2013/10/11/anatomy-of-an-ex...
- nimih 8y agoI'm not sure what the OP was referring to, but off the top of my head there was a security vulnerability in Windows disclosed last year which seems to fit that description[1][2]. [1] https://twitter.com/natashenka/status/861748397409058816 https://twitter.com/natashenka/status/861748397409058816 [2] https://bugs.chromium.org/p/project-zero/issues/detail?id=1252&desc=5 https://bugs.chromium.org/p/project-zero/issues/detail?id=12...
- bsamuels 8y agoI won't provide a source but i'll provide a modified real life example, since i'm pretty sure this vuln is still in the wild. I was doing a pen test on a router whose manufacturer decided it would be an OK idea to use GET requests to launch their ping diagnostic tool on their router's unauthenticated QA web interface. this ping diagnostic tool was triggered by doing GET http://192.168.1.1/diagnostic/trace&ip=X.X.X.X http://192.168.1.1/diagnostic/trace&ip=X.X.X.X The IP address in the URL parameter would get plugged directly into a "ping" command line command, so you could obtain command injection by going GET http://192.168.1.1/diagnostic/trace&ip=X.X.X.X&&telnetd http://192.168.1.1/diagnostic/trace&ip=X.X.X.X&&telnetd You could exploit this from literally any website on the internet, and since it's a GET request and we don't care about what it returns, CORS won't save your router. I think that counts as a javascript one-liner, but you get the idea how fucking awful some of these routers are.
- namibj 8y agoIt might even be an evil pixel... E.g., worse than javascript-requiring exploits.