Slashdot Mirror

Apple is going to end up killing off the fingerprint security industry singlehanded, just like they did handwriting recognition a few years back. It's another one of these technologies that sounds good at first, but in practice just doesn't quite hold up. Parents shouldn't use it to keep their kids out of their phone for example, because there are available fingerprints to acquire all over the house. http://pacsec.jp/psj06/psj06krissler-e.pdf

Am I reading it correctly that CNet doesn't understand the difference between launching an executeable stored on an external media device, and somehow running it "on" the media device?

You are reading it right. I just finished viewing a Power Point Presentation titled something like "Owned by an i-Pod". The discussion was not about USB, but Fireware which is peer to peer. It can scan memory, do direct reads and writes, etc without the host OS. I would recommend going through the list of seminar materials and find the Power Point presentation.

The link to the Powere Point presentation;
http://pacsec.jp/psj04/psj04-dornseif-e.ppt

I saw in another post USB has some of the same features as Firewire. It may be possible for code running on a USB device to slurp the host just like in the movies.

OpenBSD is really cool. The latest release brings some great new features. It's now possible to have a *fully* redundant firewall/vpn box. (support for keeping filter, nat, queue, ipsec states sync'd on all nodes, support for takeover of failed device, support for interface trunking for layer2 redundancy...) It works very well and it's a snap to setup since everything is in the default install. Mark Uemura is giving a talk about this at PacSec this november in Tokyo. Here are slides from an older one he did.

If you ever find yourself being accused of not practicing responsible disclosure you can take comfort in the fact that you cannot be responsible for everyone's needs. The term "responsible disclosure" doesn't include the part about who you are supposed to be responsible for, that's up to you to decide.

In my humble opinion, the correct way to disclose a bug is however you feel like doing it. You found it. You don't owe anybody for that. Maybe you believe that the fastest route to a more secure and reliable world of software is if people who choose to use certain software are punished as often as possible so that they switch to software written by a more responsible party. Who knows? Maybe it could work. It is definitely not immoral or irresponsible to believe this since we don't know what does work. If there was one obvious true way to make a hole public (or not) that had no ill effects then everyone would be doing that already. duh.

If a researcher, with no prior contact with the vendor posts a vulnerability out of the blue then the people who work at the vendor are going to be pissed. They are going to call the researcher "irresponsible", but that's only because they have to maintain a certain amount of class. They really just think he's an asshole because he is going out of his way to make things harder than they need to be for the developers and the customers who use the software.

I do not think many researchers are acting this way.

On the flipside, when researchers contact a vendor in good faith and that vendor treats them badly then it is unreasonable for the vendor to expect any more good faith efforts from that researcher.

As you so aptly pointed out, having tact is key. If the researcher does a vendor the courtesy of giving advanced notice, and he is open and honest about his motovations and expectations, whatever they are, then I say he is responsible.

examples:

A researcher who found bug by fuzzing, currently has _no evidence_ that it is being exploited giving a heads up to the vendor:

"hi I just found this remotely exploitable heap overflow in WizBang. All versions starting from 2.1 are vulnerable. You can reproduce this bug by blah blah blah. I plan to discuss this during my presentation at PacSec, a security conference that focuses on new research which is being held in Japan on November 15th. You should make sure you have patches ready before then. let me know if you need any more info."

It doesn't matter at all if the vendor really can't fix the problem before then, because it is a major design flaw requiring huge rewrite that will screw over the release schedule for the next 6 months. The vendor may say this and try to stall, then call the researcher "irresponsible" when he follows through and goes public, but it's nothing more than selfish whining. When someone who you don't even know offers you something highly valueable for free you are in no position to start making demands. It is utterly mind boggling how certain companies try to justify behaving this way.

In this example the researcher is being responsible for himself and his career by making it known to vendors who believe they are ultimately responsible for finding their own bugs that he would be worthy of hiring. Or he's making it know that his company has smart people who can find and exploit bugs, not a bunch of monkeys who charge money for running nessus. Either one thing that sure ISN'T his concern is making sure the vendor can patch in time. No amount of vendor temper tantrums can force him to take on that responsibility. How is it even possible to be responsible for the actions of a bunch of programmers who don't even work for you???

Here's another example of responsible disclosure that's sure to draw flames.

A couple

>I prefer to set password for setup, which prevents intruders to change booting options.

That does raise the bar, but every motherboard I've looked at had some way to bypass the BIOS password, and in extreme cases someone with unsupervised physical access could pull out the hard disk and copy it. Not to mention that an attacker could read and write arbitrary memory if the machine has a Firewire port (http://pacsec.jp/advisories.html).

Just a reminder, if you depend on physical security and have 1394 ports powered, any 1394 device can read your system's memory through DMA.

Turn them off in the BIOS if this is an issue for you (the linked article suggest globs of epoxy...).

Coming soon to a sensationalist news story near you.