IMG_3628.jpg
Date: 11/09/2006
Views: 171
|
|
|
Friday, 28 November 2003 |
Rumor has it SCO may sue Google. These guys are nuts.
Their strategy of extorting money from well endowed companies like IBM is a double edged sword. Those companies are also the most capable of fighting them in court. IBM is fighting, and if sued I imagine Google will too.Write Comment (0 Comments) |
|
Tuesday, 18 November 2003 |
Here's an intersting article discussing a case involving the DMCA and garage door openers.
One company produced a garage opener with a security feature designed to prevent criminals from "Code Grabbing". Apparently, that's door opener security slang for packet sniffing combined with a replay attack. The attacker waits for you to use your door opener and uses a device to record the code you sent to your opener. Then, when you're not home, the attacker sends the same code opens your door and runs away with anything valuable in your garage, or uses access to the garage to mount further attacks.
Another company developed a "universal remote" for garage door openers that worked around the security feature (it was a pretty lame security feature with a built in backdoor). The manufacturer sued them under the DMCA.
What makes this case interesting is why the judge ruled that the universal remote manufacturers were innocent.
a homeowner has a legitimate expectation that he or she will be able to access the garage even if the original transmitter is misplaced or malfunctions
As the author of the article stated, consumers have a right to replace a lost remote with a competing product without violating federal law. This is a very interesting round about way to arrive at fair use.
If this is a valid legal position, and it seems reasonable to me (IANAL!), then it has implications for other cases regarding the DMCA and reverse engineering in general. For example, when I buy an MP3 from iTunes do I have the right to circumvent their copy protection so that I can use the music with a competing product? And what if you see DIVX as a competitor to DVD? Does that all of a sudden make cracking DVD encryption legal?
Write Comment (0 Comments) |
|
Tuesday, 11 November 2003 |
This clever attempt to add a privelage escalation bug into the linux kernel illustrates a very sophistocated and forward thinking form of an attack. A good discussion can be found here.
It also lends some fuel to both sides of the "is open source more or less seucre?" question. Yes, anyone can contribute code (including malicious coders like this one), but all contributions are visible and subject to inspection. Thankfully, this attack was caught right away.
This also illustrates the subtle ways that programming language design decisions can have far reaching and unexpected results. Anyone who's written more that 10 lines of C is familiar with the bug the attacker tried to exploit. "=" means assignment, and "==" tests equality. It's a very easy bug to create that even seasoned C programmers often miss.
Write Comment (0 Comments) |
|
Tuesday, 28 October 2003 |
I've been particularly uncomfortable with the idea of tying product liability to the author(s) of open source software and I think I've finally figured out why:
When source code is available the author enables the user to make a more informed decision about how flawed the software is.
When Microsoft tells us the next version of windows less flawed, the only way to validate their claim is to use it and see. With an open source product, we can at least read the code and have some idea how accurate the claims of the author are before ever running the software even once.
Expecting all users to read the source code of all the software they use isn't rational, but we can expect security minded administrators and developers to do so to at least some extent.
Less sophistocated users can rely on the findings of a public network of experts to help them decide what products are safe enough for their purposes. And for applications where the assets being secured are valuable enough they can pay experts to audit the code before using it.
The BSD family of operating systems (NetBSD, FreeBSD, and OpenBSD) have benefited tremendously from the improvement of the security of the source code rather than relying on waiting for obscure exploits to be found. SELinux, sponsored by the NSA, is another great example.
This helps illuminate one of the claims that Microsoft has often made, that open source software is inherintely more dangerous because all the flaws are there for everyone to see. That may be true, but for a product as critical as a widely used operating system lots of folks have an interest in finding and fixing those problems. I don't think it's an unreasonable assumption to assume that eyeballs on the code is positively correlated with popularity.
As open source projects grow, they become more and more secure (sendmail and BIND are good examples). Conversely, I think it's also safe to assume that security decreases with product complexity and size. These two trends combined mean that as closed source products grow in size and complexity the number of flaws will increase at a faster rate than an open source project of similar size and complexity. The same number of flaws get added, but fewer get found and fixed.
This is a dramatic simplification, but I think it reveals important realities about closed and open source software. A closed source project with a strong emphasis on security, a secure development process, and security trained developers will probably be more secure than an open source project that emphasizes a fast schedule with developers don't have a clue about security. However, all other factors being equal, open source software will tend toward fewer flaws than an equivalent closed source project of the same complexity, especially as the size of the project grows.
Open source also includes an implied contract regarding liability. You can share in judging how risky the software is so you must also share in the risks of using the software.
Ahoy,
Jason
Write Comment (0 Comments) |
| | << Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
|
|
