Jan Nielsen to me to Jan: > >Obviously, then, your book does not include the phrase "Halting > >Problem"... > > Sorry, I don't follow you there, you mean that the scan would halt the > system ? fair enough, I don't think any method of scanning a target is > fool-proof, no matter how its done.
Ahh, no... http://en.wikipedia.org/wiki/Halting_problem Basically (and simplifying a lot), the Halting Problem means that you cannot write a computer program to determine if some other program exhibits "function X", _in finite time_. Thus, you cannot write a program to detect all viruses, you cannot write a program to detect key loggers, you cannot write a prorgram to detect all spyware, etc, etc. In short, the Halting Problem means that your suggestion to "beat" the problem of having to run on a compromised system by detecting if the system is compromised is just as impossible as is finding a solution more in line with the OP's suggested (but it turns out, unclearly so) aims. > > ... that would be in the end-users > > best interest I think (and of course report your findings to the users > > mailbox or something, don't tell the hacker that you detected his > > keylogger :-) > > >And what machines do you think users are most likely to check their > >mail from? > > Thanks for pointing that out, but you would wan't to somehow relay to > the person not gaining access, why they are not getting in though, ... It would be _nice_ to do that, but it is an equally fraught problem. After all, even if you could entirely reliably programmatically determine that the users's system was compromised, you cannot trust any response from the system, or that any message you try to send to them to alert them to this will not be intercepted by some warez put on the system as a result of the compromise... > ... a > textmessage/SMS might be wiser. And, as I already pointed out and you seem to have missed (or forgotten already), regardless of whether you try to do such "warning" out-of- band (a good idea on its face) or not, that raises the issue of how do you _reliably_ know who to send the message to that the system has been compromised. You cannot trust that anything returned from the compromised machine will be reliable, and you can't allow the user to perform any kind of "sensitive" authentication (as gaining that information is presumably the aim of the compromiser andd _preventing that_ was the aim of this suggested solution... "Rock?" "Hard place?" "Meet Jan Nielsen..." > >And, of course, your suggestion raises a primacy issue -- if you > >actually did detect the user's machine was compromised before they > >logged in and thus prevented allowing the login by not allowing the > >login dialog to be displayed or somesuch (thereby saving the user > >compromising yet more of their data), how in the heck do you know where > > >to send the warning mail? > > >Hmmmmm... Methinks you should think more before responding. > > Again, somehow they need to know, i don't have any ideas that can't be > intercepted on a compromised system, other than SMS/textmessage or > something. Yes, and while doing the signalling that you have detected their system is compromised out-of-band of the compromise is a genuinely desirable thing, you still have not provided a way to strongly authenticate _who_ to send that message to, regardless of the actual form of OOB signalling used. While you're working that problem you may also want to think about the "chicken and the egg" problem as they are closely related. We look forward to your solutions... Regards, Nick FitzGerald _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
