full-disclosure - Trustworthy Computing Mini-Poll

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20021220225953.GH2338@localhost>
From: Simon.Richter at hogyros.de (Simon Richter)
Subject: Trustworthy Computing Mini-Poll

Bruce,

> > I'd say protection from binary viruses and stack overflows, plus if
[...]

> I'm sorry, maybe I was sleeping in class...  can somebody explain to me
> how a TCPA machine (as currently hypothesized) would keep stack overflows
> from happening?  Is this a facet of having a "nub" check each and every
> memory access, and having a stack marked "read/write/no execute"? Or is
> my vision not far enough?

Hrm, maybe I expect too much from the TCPA folks, but actually a buffer
overflow (using a "carefully crafted" DVD) that lets me take control of
a trustworthy DVD player would be the first thing I'd think of if I
designed such a system, and thus the first thing I'd like to prevent.

> I see that you qualified "protection from *binary* viruses" - the "nub"
> sure wouldn't allow a file that a file virus (Staog or something like
> that) had tinkered with to execute.  But file viruses were never a serious
> threat as far as I can tell (see http://news.com.com/2009-1001-254061.html).

As an old time Amiga user I tend to disagree. :-)

Seriously though, there isn't much difference between a file virus and a
rootkit. If my computer tells me when I try to run a modified binary, I
have already gained a lot.

[Macro viruses]

Well, we can't do much about that, I think. There are always stupid
people running stupid programs.

   Simon

-- 
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD  ADC6 18A0 CC8D 5706 A4B4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20021220/03b3c290/attachment.bin