bugtraq - Re: PocketPC exploitation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.56.0509301205470.25385@redsky.antelope.net>
Date: Fri, 30 Sep 2005 12:22:05 -0600 (MDT)
From: Joel Maslak <jmaslak@...elope.net>
To: Denis Jedig <seclists@...eticon.de>
Cc: bugtraq@...urityfocus.com
Subject: Re: PocketPC exploitation

On Fri, 30 Sep 2005, Denis Jedig wrote:

> Although it is a Good Idea (tm) to uncover design deficiencies in
> current AV products, we never should forget that "antivirus" is *by
> definition* a reactive thing and thus cannot protect from unknown
> threats. If we wanted to have a *really* proactive approach, we would
> have to either ask for OS capabilities to efficiently compart
> (malicious) code or for the software manufacturers to take damn care
> when using low-level languages and introduce efficient patching
> mechanisms at last.

Once again, there is no silver bullet.

I do agree with you on AV being reactive.  In fact, the need for it just
proves the pitiful state of security today.  That said, I very much
disagree on your proposed "solutions".

OS capabilities?  Like what?  Preventing users from installing and running
applications that aren't approved by the OS vendor, the processor
manufacturer, and/or some government regulatory body?  Preventing any
application from writing to the disk, accessing the network, or
interacting with the user?  Who are you going to allow to make these
decisions for you, on your own machine?  Or do you have a real solution
that addresses more then one specific subcategory of threat, but
doesn't remove your ability to control your own machine and to write code
to do the same?

As for low-level languages, I don't think that's the problem.  Low level
languages, meaning assembly/machine languages and C-based languages, have
problems with making it easy to prevent buffer overflows - that's for
sure.  And many high level languages don't have that problem.  But there
are hundreds of other vectors to use to spread viruses, worms, spyware,
etc.

-- 
Joel