Hyper-Threading Considered Harmful
Colin Percival
Edition, Pentium 4, Mobile Pentium 4, and Xeon processors, suffers from a
serious security flaw. This flaw permits local information disclosure,
including allowing an unprivileged user to steal an RSA private key being
used on the same machine. Administrators of multi-user systems are
strongly advised to take action to disable Hyper-Threading immediately.
I will be presenting this attack at BSDCan 2005 in Ottawa at 10:00 AM EDT
on Friday May 13th, and at the conclusion of my talk I will also
releasing a paper describing the attack and possible mitigation
strategies. For more details, see my web page on the topic at
http://www.daemonology.net/hyperthreading-considered-harmful/
I will follow up here with more details after my talk on Friday morning.
Colin Percival
Tom St Denis
Colin Percival wrote:
> Hyper-Threading, as currently implemented on Intel Pentium Extreme
> Edition, Pentium 4, Mobile Pentium 4, and Xeon processors, suffers
from a
> serious security flaw. This flaw permits local information
disclosure,
> including allowing an unprivileged user to steal an RSA private key
being
> used on the same machine. Administrators of multi-user systems are
> strongly advised to take action to disable Hyper-Threading
immediately.
>
> I will be presenting this attack at BSDCan 2005 in Ottawa at 10:00 AM
EDT
Ottawa eh? Wanna grab a pint in the evening? Got work in the morning
but can be around in the afternoon. Email me in private if you wanna
arrange something.
Tom
Bryan Olson
> Hyper-Threading, [...] on Intel [...] suffers from a
> serious security flaw. This flaw permits [...] an unprivileged user
> to steal an RSA private key.
As one who won't be able to make the talk, I'd request that you
post a link to the paper when it's available. Sounds way-cool.
> Administrators of multi-user systems are
> strongly advised to take action to disable Hyper-Threading
> immediately.
I assume you realize how likely it is that the community will
generally take that advice.
The world is going to hyper-threading and multi-core, and
probably then to hyper-threaded-unified-poly-core. Sure, I just
made up that term, but many people foresee the hardware and O.S.
cooperating to figure out how many and which threads to run at
once, to take best advantage of the various execution units.
We'll have a brave new world of side channel attacks.
--
--Bryan
Tom St Denis
Bryan Olson wrote:
> I assume you realize how likely it is that the community will
> generally take that advice.
>
> The world is going to hyper-threading and multi-core, and
> probably then to hyper-threaded-unified-poly-core. Sure, I just
> made up that term, but many people foresee the hardware and O.S.
> cooperating to figure out how many and which threads to run at
> once, to take best advantage of the various execution units.
> We'll have a brave new world of side channel attacks.
Simple. Find a way to remove performance counters from unprivileged
tasks [enable/disable at will]. No RDTSC it's hard to count cycles.
Sure you can use clock() or something but that's way less useful.
Even better is not to have users on your SSL servers.
Tom
Colin Percival
> Colin Percival wrote:
> > Hyper-Threading, [...] on Intel [...] suffers from a
> > serious security flaw. This flaw permits [...] an unprivileged user
> > to steal an RSA private key.
> As one who won't be able to make the talk, I'd request that you
> post a link to the paper when it's available. Sounds way-cool.
I'll post a direct link here after my talk; the paper will also
be linked from the URL I gave earlier.
> > Administrators of multi-user systems are
> > strongly advised to take action to disable Hyper-Threading
> > immediately.
> I assume you realize how likely it is that the community will
> generally take that advice.
Well, this attack only targets Hyper-Threading -- dual cores aren't
a problem. (Ok, let me rephrase that: Dual cores might be a problem,
but I don't have any evidence to suggest that they are.)
Since the performance benefit of Hyper-Threading is fairly minimal
on most of the applications which run on multi-user systems, disabling
htt isn't quite as bad as it sounds.
> We'll have a brave new world of side channel attacks.
We need to convince Intel and AMD to hire lots of cryptographers and
get them involved in CPU design. :-)
Colin Percival
Bryan Olson
> Simple. Find a way to remove performance counters from unprivileged
> tasks [enable/disable at will]. No RDTSC it's hard to count cycles.
> Sure you can use clock() or something but that's way less useful.
To paraphrase /The Hitchhiker's Guide to the Galaxy/, this is
obviously some strange usage of the word 'simple' that I wasn't
previously aware of. The things people with kick-butt
processors want to do, such as displaying HDTV or playing 3-D
games at high frame rates, require a time function much more
precise than clock().
> Even better is not to have users on your SSL servers.
Well, sure, that's a solution if we're only concerned with SSL
servers. I want to be able to watch multi-media streams
downloaded in real-time from a possibly-hostile sites. It
worries me that my browser runs with the same privilege when I'm
on-line-bill-paying as when I'm surfing for ... uh ... multi-
media test files. For example.
--
--Bryan
Ivan Voras
> Hyper-Threading, as currently implemented on Intel Pentium Extreme
> Edition, Pentium 4, Mobile Pentium 4, and Xeon processors, suffers from a
> serious security flaw. This flaw permits local information disclosure,
This is either very well coordinated or just plain fast - I saw your
message, with a timestamp of 02:00 (my time), and several seconds later
I received FreeBSD security advisories on this subject
(FreeBSD-SA-05:09.htt), timestamped half an hour later. :)
Looking at the patch code (there's no description of the attack nor the
precise scope of it, which is unusual at least), it seems that the only
option is to completely disable HTT, there are no workarounds - correct?
(I agree that there will be no grief in disabling HTT as it's mostly
useless, at least in servers).
Colin Percival
> This is either very well coordinated or just plain fast - I saw your
> message, with a timestamp of 02:00 (my time), and several seconds later
> I received FreeBSD security advisories on this subject
> (FreeBSD-SA-05:09.htt), timestamped half an hour later. :)
Let me see, I think the right question for this would be "What is 'what I
spent the last three months doing'?"
I demonstrated that the attack was practical, and wrote the majority of
my paper, over three months ago; since then I've been talking to vendors,
explaining the problem, and encouraging them to have fixes ready at this
time.
Or rather, I've been talking to the vendors who are willing to talk to
me. A few well known vendors apparently decided that this issue required
that they talk to everybody *other* than me.
> Looking at the patch code (there's no description of the attack nor the
> precise scope of it, which is unusual at least),
A revised advisory will be sent out on Friday morning, after I give my
talk -- I asked them to avoid upstaging me. :-)
> it seems that the only
> option is to completely disable HTT, there are no workarounds - correct?
There are other options which involve making changes to the cryptographic
libraries, but my conclusion was that it was much easier to disable
hyperthreading than to rewrite every crypto library in the world.
Colin Percival
D. J. Bernstein
turned off for security. They've been advertising information disclosure
through hyperthreading since at least February. See, for example, the
``Other People's Cache---HyperAttacks with HyperThreading'' abstract in
http://www.esat.kuleuven.ac.be/sista-cosic-docarch/template.php?page=activities
reporting recovery---with ``no access to plaintext or ciphertext''---of
``45 out of 128 key bits from AES encryption of English text in just one
minute on an Intel processor with HyperThreading''; and reporting full
key recovery from known plaintext.
Osvik and Tromer haven't put their talks on the web, as far as I know,
but their attack is discussed in Section 13 of my ``Cache-timing attacks
on AES'' paper, http://cr.yp.to/papers.html#cachetiming, along with the
obvious recommendation: ``AES implementors should encourage computer
owners to disable hyperthreading.''
If Colin Percival has discovered further problems with hyperthreading,
beyond the cache-timing effects exploited by Osvik and Tromer, then it
will certainly be interesting to see the details, so that we have a
better idea of how Intel might screw up our security in the future.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Douglas A. Gwyn
> It has its uses as a compromise, but any system whose fundamental
> security measure is cryptography is doomed from the outset.
No. There have been many successful information protection
systems based on cryptography. Indeed, experience shows
that the opposite is more nearly true: that systems that do
not employ some secret key do not offer much security.
Tom St Denis
> If Colin Percival has discovered further problems with
hyperthreading,
> beyond the cache-timing effects exploited by Osvik and Tromer, then
it
> will certainly be interesting to see the details, so that we have a
> better idea of how Intel might screw up our security in the future.
Indulge me here... The Osvik/Tromer attack is something you apply as a
observer in the middle of a network right?
... oh you need to be on the box?
Ok, so do you have the shell accounts for paypal we need? How about
ebay? Amazon? portal.acm would be nice ;-)
... Again this is another case of "yes it's an attack" and "yes you can
mitigate it" ... EVEN with HT turned on. Just don't have users on
your SSL server box.
Tom
Francois Grieu
Bryan Olson <fakea...@nowhere.org> wrote:
> The world is going to hyper-threading and multi-core, and
> probably then to hyper-threaded-unified-poly-core. Sure, I just
> made up that term, but many people foresee the hardware and O.S.
> cooperating to figure out how many and which threads to run at
> once, to take best advantage of the various execution units.
> We'll have a brave new world of side channel attacks.
A nice alternative is to move cryptography to dedicated hardware;
such as tamper-resistant modules or Smart Cards for Public Key
crypto and low-bandwidth en/decryption, on-the-die crypto support
for fast block ciphers.
François Grieu
Ivan Voras
> Ivan Voras <ivoras@_-_fer.hr> wrote:
>
>>This is either very well coordinated or just plain fast - I saw your
> Let me see, I think the right question for this would be "What is 'what I
> spent the last three months doing'?"
I *did* see your name in the SA, so I guess I was only commenting on
well done coordination :)
Randy Howard
> Well, this attack only targets Hyper-Threading -- dual cores aren't
> a problem. (Ok, let me rephrase that: Dual cores might be a problem,
> but I don't have any evidence to suggest that they are.)
If SMP isn't a problem, then dual-core shouldn't be. HyperThreading
is a different beast.
> Since the performance benefit of Hyper-Threading is fairly minimal
> on most of the applications which run on multi-user systems, disabling
> htt isn't quite as bad as it sounds.
In some cases it actually speeds things up. It's rare indeed,
especially on server workloads, that it actually helps. I/O bottlenecks
badly with Hyper enabled.
--
Randy Howard (2reply remove FOOBAR)
"If the evidence doesn't seem to fit a particular conspiracy theory,
just create a bigger conspiracy theory." --Robert D. Hicks
Nick Maclaren
In article <MPG.1cee596a2...@news.verizon.net>,
Randy Howard <randy...@FOOverizonBAR.net> writes:
|> In article <d610bk$n1l$1...@morgoth.sfu.ca>, cper...@sfu.ca says...
|> > Well, this attack only targets Hyper-Threading -- dual cores aren't
|> > a problem. (Ok, let me rephrase that: Dual cores might be a problem,
|> > but I don't have any evidence to suggest that they are.)
|>
|> If SMP isn't a problem, then dual-core shouldn't be. HyperThreading
|> is a different beast.
Hyperthreading and discrete-board SMP are towards the extremes of
a spectrum, rather than being entirely separate categories. It is
certainly possible that some implementations of dual-core SMP could
have some extra problems caused by its closer coupling. For example,
the POWER4 systems introduced coupling problems that weren't there
with the POWER3, and I have no reason to believe that is the only
example.
But this is niggling rather than disagreeing with your statement.
It is unlikely that most dual-core implementations will be very
different from an SMP system that uses separate CPUs and a shared
L2/3 cache. They may differ from SMP systems that don't share
cache.
Regards,
Nick Maclaren.
Mouse
share a resource, then one entity can deduce something about the other
one from monitoring the use of that shared resource [by the other
entity]. Timing attack over again...
This problem has two solutions: (a) disable the sharing, and (b) alter
the software behavior so that the access to the shared resource does not
reveal the pattern in the secret you don't want to disclose.
Tom St Denis
Mouse wrote:
> Basically this attack comes from the observation: if say two entities
> share a resource, then one entity can deduce something about the
other
> one from monitoring the use of that shared resource [by the other
> entity]. Timing attack over again...
>
> This problem has two solutions: (a) disable the sharing, and (b)
alter
> the software behavior so that the access to the shared resource does
not
> reveal the pattern in the secret you don't want to disclose.
Exactly. I'd say having users other than nobody/root/apache on your
webserver boxes is a significant breach of security.
As for the timing attacks externally...use fixed time implementations,
slotting [*] or hardware crypto accelerators.
[*] this is basically where you say operation takes xN time for some
value of x [e.g. N = 500 cycles]. So an AES encrypt which may go +/- a
few dozen cycles [after bulk of it in cache] can be slotted to the next
500 cycles. You'd pick N large enough so that your expected
distribution would fit in one multiple of N [slotting with N=1 would be
like no slotting, N=2 means always even cycles, etc...].
Bernstein is right that adding noise is not a fix [it makes the attack
harder but not significantly so if you have enough observations]. But
slotting [if done correctly] eliminates the side channel alltogether.
Tom
David Kanter
> a problem. (Ok, let me rephrase that: Dual cores might be a problem,
> but I don't have any evidence to suggest that they are.)
>
> Since the performance benefit of Hyper-Threading is fairly minimal
> on most of the applications which run on multi-user systems,
disabling
> htt isn't quite as bad as it sounds.
>
> > We'll have a brave new world of side channel attacks.
>
> We need to convince Intel and AMD to hire lots of cryptographers and
> get them involved in CPU design. :-)
I think you might find this article interesting:
Apparently, AMD does not encrypt their BIOS update mechanisms.
David
Stephen Sprunk
news:fgrieu-6FECBD....@news5-e.proxad.net...
Or AMD and Intel could just implement Via's AES instructions; they take
minimal die space, especially considering the behemoth processors coming
out these days. Constant-time execution means timing attacks aren't
possible, right?
S
--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
Tom St Denis
Stephen Sprunk wrote:
> "Francois Grieu" <fgr...@francenet.fr> wrote in message
> news:fgrieu-6FECBD....@news5-e.proxad.net...
> > In article <z5Tge.16306$J12....@newssvr14.news.prodigy.com>,
> > Bryan Olson <fakea...@nowhere.org> wrote:
> >
> > > The world is going to hyper-threading and multi-core, and
> > > probably then to hyper-threaded-unified-poly-core. Sure, I just
> > > made up that term, but many people foresee the hardware and O.S.
> > > cooperating to figure out how many and which threads to run at
> > > once, to take best advantage of the various execution units.
> > > We'll have a brave new world of side channel attacks.
> >
> > A nice alternative is to move cryptography to dedicated hardware;
> > such as tamper-resistant modules or Smart Cards for Public Key
> > crypto and low-bandwidth en/decryption, on-the-die crypto support
> > for fast block ciphers.
>
> Or AMD and Intel could just implement Via's AES instructions; they
take
> minimal die space, especially considering the behemoth processors
coming
> out these days. Constant-time execution means timing attacks aren't
> possible, right?
A better solution [and much more flexible]. Would be the ability to
have "lock" memory which would be constant access and can't be removed
by lower privilege tasks.
E.g. you tell the kernel "put blah in memory" and it returns an address
which would be for your table. Make it DRAM for all it matters [and
since it's on die throw a huge bus on it for fun] all you care is that
it's constant time to access, 64KB of it should suffice and it would be
much smaller than an AES core and much smaller than 64KB of SRAM. Then
you could do AES or WHIRLPOOL or TIGER/192 or ... whatever comes next.
so AES would look like
ptables = kernel_lock_cache(base_aes_tables, 4*256*4); <= key invariant
step
if (!ptables) return ERROR;
... do AES with ptables pointing to the four 8x32 tables.
...
kernel_unlock_cache(ptables);
Given that AES tables are 4 KB you could have 16 processes at once in
the 64KB region I proposed. Or if you code your software correctly you
could lock the AES table once and share it between
threads/processes/etc. Very few tasks outside of crypto would need it
(but I imagine things like MPEG encoding/decoding could take advantage
of easily controllable high bandwidth memory) on a typical webserver so
it's likely to be available.
Tom
Colin Andrew Percival
> I will follow up here with more details after my talk on Friday morning.
Ok, I lied. I'm not going to follow up with details, since I want to get
back to the conference. You can read the paper yourselves. :-)
http://www.daemonology.net/papers/htt.pdf
Colin Percival
Louis Scheffer
>To paraphrase /The Hitchhiker's Guide to the Galaxy/, this is
>obviously some strange usage of the word 'simple' that I wasn't
>previously aware of.
Are you sure this is "Hitchhiker's"? I seem to recall this phrase from
"The Princess Bride", when the bad guy comments it is "impossible" for
the good guy to be still following them.
Lou Scheffer
Tom St Denis
Bryan Olson wrote:
> Tom St Denis wrote:
> > Simple. Find a way to remove performance counters from
unprivileged
> > tasks [enable/disable at will]. No RDTSC it's hard to count
cycles.
> > Sure you can use clock() or something but that's way less useful.
>
> To paraphrase /The Hitchhiker's Guide to the Galaxy/, this is
> obviously some strange usage of the word 'simple' that I wasn't
> previously aware of. The things people with kick-butt
> processors want to do, such as displaying HDTV or playing 3-D
> games at high frame rates, require a time function much more
> precise than clock().
Perhaps... Ok, solution, deny existence of the attack. That's simple
too.
> > Even better is not to have users on your SSL servers.
>
> Well, sure, that's a solution if we're only concerned with SSL
> servers. I want to be able to watch multi-media streams
> downloaded in real-time from a possibly-hostile sites. It
> worries me that my browser runs with the same privilege when I'm
> on-line-bill-paying as when I'm surfing for ... uh ... multi-
> media test files. For example.
Multiple users. I have a user for gnutella that I use to get my ... um
... test mpeg streams [good cover] and then my regular user. They're
separated so short of a kernel exploit they never meet.
Tom
Jean-Luc Cooke
HHGTTG's word was "safe", Arther was on the Vogon's ship.
The Princess Bride's word was "inconceivable"... if only I could spell
it.
JLC
--
Tom St Denis
> The Princess Bride's word was "inconceivable"... if only I could
spell
> it.
And you know this because...?
Tom
Tim Smith
wrote:
> To paraphrase /The Hitchhiker's Guide to the Galaxy/, this is obviously
> some strange usage of the word 'simple' that I wasn't previously aware of.
> The things people with kick-butt processors want to do, such as displaying
> HDTV or playing 3-D games at high frame rates, require a time function
> much more precise than clock().
Uhm...neither of those are things you generally do on a multiuser server.
:-)
Ignoring that, gettimeofday() would be good enough for pretty much
everything. The place cycle counting is really useful is development and
performance tuning, which can generally be done off of production servers.
--
--Tim Smith
Tim Smith
wrote:
> A nice alternative is to move cryptography to dedicated hardware; such as
> tamper-resistant modules or Smart Cards for Public Key crypto and
> low-bandwidth en/decryption, on-the-die crypto support for fast block
> ciphers.
For most systems, there is no need for the crytographic hardware to be
tamper-resistant, as all attacks will be software attacks. Does
tamper-resistence add much cost?
--
--Tim Smith
Jean-Luc Cooke
> And you know this because...?
Because I don't pay for cable and I have a pathological memory.
JLC
--
Paul Rubin
> A nice alternative is to move cryptography to dedicated hardware;
> such as tamper-resistant modules or Smart Cards for Public Key
> crypto and low-bandwidth en/decryption, on-the-die crypto support
> for fast block ciphers.
I'm not the slightest bit convinced that tamper resistant modules or
smart cards are, in general, resistant to these attacks. I've been
wanting to try it on some of the modules that I use, but you know
how that goes.
Pubkeybreaker
Nice work.
Mike Amling
> "Francois Grieu" <fgr...@francenet.fr> wrote in message
> news:fgrieu-6FECBD....@news5-e.proxad.net...
>>
>>such as tamper-resistant modules or Smart Cards for Public Key
>>crypto and low-bandwidth en/decryption, on-the-die crypto support
>>for fast block ciphers.
>
> Or AMD and Intel could just implement Via's AES instructions; they take
> minimal die space, especially considering the behemoth processors coming
> out these days. Constant-time execution means timing attacks aren't
> possible, right?
How does that protect the OP's RSA key?
--Mike Amling
Stephen Fuld
"Nick Maclaren" <nm...@cus.cam.ac.uk> wrote in message
news:d62782$980$1...@gemini.csx.cam.ac.uk...
From reading the article, ISTM (but I admit, with a lowerr than normal
probabity of being right) that any system where two cores share cache at any
level (unless some of the mechanisms presented in the paper are implemented)
can be used for this attack. The only caveat is the bandwidth of the covert
channel goes down as the cache "level number" goes up. So a multi core chip
would be suceptible if the cores shared say the L2 cache. In fact, if they
shared the L1 cache (I agree, not likely, but mentioned for purposes of
exposition), it seems that system would be exactly as bulnerable to the
attack presented as an SMP system.
--
- Stephen Fuld
e-mail address disguised to prevent spam
Eric Cordian
performing bignum modular exponentiation on his RSA private key, and the
other monitoring the first users memory cache line use, by timing his own
reads to colliding cache lines in his own process. The RSA operations
leave footprints in the cache which depend on the key bits, which can be
inferred by someone else sharing the cache.
While theoretically interesting, it sounds like a bitch to implement on a
system with lots of users, and the kernel re-assigning threads to
processor contexts 100 times a second.
We've seen such timing attacks on RSA before, even over TCP connections,
and while they can be demonstrated under laboratory conditions, I am not
aware of anyone successfully stealing someone's elses key in real life by
employing one.
My personal opinion is that the recommendation that everyone disable
hyperthreading on multi-user systems is premature. I'd like to hear what
Intel and Bruce Schneier have to say on this issue before declaring the
sky is falling.
--
Eric Michael Cordian 0+
O:.T:.O:. Mathematical Munitions Division
"Do What Thou Wilt Shall Be The Whole Of The Law"
Paul Rubin
> We've seen such timing attacks on RSA before, even over TCP connections,
> and while they can be demonstrated under laboratory conditions, I am not
> aware of anyone successfully stealing someone's elses key in real life by
> employing one.
Do you think they're going to tell you?
Eric Cordian
> Eric Cordian <e...@artifact.psychedelic.net> writes:
I wouldn't expect someone doing it for illegal purposes to tell me, no.
If such attacks were easily accomplished, however, researchers would be
proudly displaying things like SSH private keys extracted from fully
loaded production systems. I don't see this happening much.
There are far easier ways to get peoples keys, in any case.
I'm also less impressed by research in which the press release preceeds
the peer review. :)
I would be greatly surprised if the consensus of the security community is
that all users with HT on multiuser systems should immediately turn it
off.
Greg Lindahl
Eric Cordian <e...@artifact.psychedelic.net> wrote:
>I would be greatly surprised if the consensus of the security community is
>that all users with HT on multiuser systems should immediately turn it
>off.
Given that the benefit of hyperthreading is often negative on a
multiuser system, smart admins have already turned it off.
The proven win is situations such as databases and routers, neither of
which typically run on shared machines. The killer situation is cache
thrashing. Parallel computing usually loses because most programs want
to be in lockstep, and hyperthreading is usually highly asymmetrical.
And so on and so on...
-- greg
Colin Andrew Percival
> I'm also less impressed by research in which the press release preceeds
> the peer review. :)
Let me explain a bit here. I did this work wearing two hats; first as a
cryptographer, but second as part of the FreeBSD security team. Given my
academic background, I wanted my work to get the most extensive review
possible; but given my experience working at the practical level to fix
operating system and application vulnerabilities, I knew that I had to
inform vendors and give them time to prepare fixes before I released the
paper. During this pre-release period, a large number of cryptographers
and people with cryptographic experience read and commented on the paper;
so even though it hasn't had "peer review" in the formal sense, it has
certainly benefited from review.
I hope that other cryptographers, if they discover a problem which (a) is
very easily exploitable, and (b) can be fixed (or worked around in the
operating system), will follow the same approach as I took and allow
vendors to prepare fixes before they publicly release the details of
their work.
Colin Percival
Dave Turner
interesting read, I had no idea about the possibilities of such covert
channels but you've certainly opened my mind up to it. Tantalisingly
intriguing stuff :-)
Thanks
Nick Maclaren
Stephen Fuld <s.f...@PleaseRemove.att.net> wrote:
>
>From reading the article, ISTM (but I admit, with a lowerr than normal
>probabity of being right) that any system where two cores share cache at any
>level (unless some of the mechanisms presented in the paper are implemented)
>can be used for this attack. The only caveat is the bandwidth of the covert
>channel goes down as the cache "level number" goes up. So a multi core chip
>would be suceptible if the cores shared say the L2 cache. In fact, if they
>shared the L1 cache (I agree, not likely, but mentioned for purposes of
>exposition), it seems that system would be exactly as bulnerable to the
>attack presented as an SMP system.
Perhaps to the attack presented, but SMP is also vulnerable to timing
attacks measuring ALU usage, where mere dual-core shared L1 is not.
Not being desperately interested in spookery, and regarding accident
and incompetence as more serious threats than malice, I am far more
concerned about the denials of service.
As HPC people can (or should be able to) witness, this sort of issue
often causes slowdowns of quite large factors, application overall.
2-3 is common, 5-10 is not all that rare, and much large ones have
been observed. There is, of course, an interaction with the operating
systems, especially when it comes to interrupts (TLB misses, floating
point emulation etc.)
Now, this is enough to trigger misbehaviour of the very crude gang
schedulers that are normally used nowadays. We know how to resolve
this, but it needs some rething and new hardware facilities, as well
as software redesigns. In research HPC, this is a pain - but what
would its consequences be when the HPC is part of the control logic
of a chemical plant?
Note that, as I said, SMP is merely towards one end of a spectrum.
Its extra problems are a matter of degree, not kind.
Regards,
Nick Maclaren.
Bryan Olson
Sir!
It has happened, more than once on this very group, that I've
been flat-out wrong technically. And yes, I've gone way too far
in a flame war or two. Or several, or many. But make no
mistake: I know my /Hitchhiker's Guide/ from my /Princess
Bride/. How dare you!
Incidentally, I remembered the phrase as, "some *obscure*
usage", but when I Googled the term, I found more quotes for,
"some *strange* usage". I do not now have a copy at hand, so I
went with the majority. Can some scholar check it out for sure?
--
--Bryan
Bryan Olson
> Bryan Olson wrote:
>>The things people with kick-butt processors want to do, such as
displaying
>>HDTV or playing 3-D games at high frame rates, require a time function
>>much more precise than clock().
>
> Uhm...neither of those are things you generally do on a multiuser server.
> :-)
True, but a single user's decision to watch a current video or
play a new game ought not expose his private key.
> Ignoring that, gettimeofday() would be good enough for pretty much
> everything. The place cycle counting is really useful is development and
> performance tuning, which can generally be done off of production
servers.
I understand the importance of protecting production servers,
and even possible treats to National Security. My own thing is
that I'm most interested in protecting the ordinary user, even
if he or she doesn't bother to learn to protect him or her own
self.
--
--Bryan
D. J. Bernstein
> I hope that other cryptographers, if they discover a problem which (a) is
> very easily exploitable, and (b) can be fixed (or worked around in the
> operating system), will follow the same approach as I took and allow
> vendors to prepare fixes before they publicly release the details of
> their work.
No. This shoot-the-messenger attitude is promoted by designers and
implementors who don't want to take responsibility for their errors. It
encourages sloppiness. In the long run, it hurts the users.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Tom St Denis
D. J. Bernstein wrote:
> Colin Andrew Percival wrote:
> > I hope that other cryptographers, if they discover a problem which
(a) is
> > very easily exploitable, and (b) can be fixed (or worked around in
the
> > operating system), will follow the same approach as I took and
allow
> > vendors to prepare fixes before they publicly release the details
of
> > their work.
>
> No. This shoot-the-messenger attitude is promoted by designers and
> implementors who don't want to take responsibility for their errors.
It
> encourages sloppiness. In the long run, it hurts the users.
So does exagerating every little nuance. Case and point that Cesena
that flew over the capital.
It could have had anthrax, no a missle no a bomb! no an anthrax
missle! So they scurried away like fraid little ants. When in reality
it was pilot error.
In your case you're inability [or unwillingness] to demonstrate the
attack with limited samples (e.g. typical HTTPS or SSH session) didn't
help you out. In Colins case the attack is easily avoidable by not
having users on your webserver box.
That doesn't mean either attack isn't real. Ideally I'd love to see
lockable scratch memory in future x86 processors. That would help
remove these attacks. But it also doesn't mean I'm going to run and
hide in the hills from an attack that doesn't apply to how I [at least]
use cryptography on a daily basis.
Tom
Nicol So
> Colin Andrew Percival wrote:
>
>>I hope that other cryptographers, if they discover a problem which (a) is
>>very easily exploitable, and (b) can be fixed (or worked around in the
>>operating system), will follow the same approach as I took and allow
>>vendors to prepare fixes before they publicly release the details of
>>their work.
>
> No. This shoot-the-messenger attitude is promoted by designers and
> implementors who don't want to take responsibility for their errors. It
> encourages sloppiness. In the long run, it hurts the users.
No, that's not shooting the messenger. The ultimate (but imprecise) goal
in choosing the timing of disclosing a security vulnerability (as well
as the amount of details, to whom made, and in what order) is to
minimize the harm to the user community.
I call the goal imprecise partly because given the same knowledge of a
vulnerability, different users have different options available. Early
general, public announcement of a vulnerability may decrease the risk to
some users, but increase the risk to others. Some users, because of
their particular situations, may have the options of switching to a
different system, disabling the vulnerable system, or working around the
problem some other way. Other users may have no realistic choice but to
live with the now-generally-known vulnerability until a fix from their
vendor is available.
Early disclosure can increases risk, such as by increasing the number of
attackers who may try to acquire, independently develop, and/or execute
exploits of the vulnerability. (I am not saying that bad guys could not
have been exploiting a vulnerability until it is publicly disclosed.)
The pre-disclosure level of risk and the increase in risk caused by the
exposure cannot be determined precisely, although you can try to
estimate it. (Some guesswork seems inevitable.) On the other hand, early
disclosure can also decrease risk by causing users to take appropriate
risk-mitigation measures. As I pointed out already, general public
knowledge benefits only those users who can do something about it. For
some users, being able to "do something about it" depends on the
available on a fix, which often has to come from their vendors.
In deciding what to do with the a discovered vulnerability, the
discoverer can control several aspects of the disclosure process to
reduce harm to the users. Such aspects include, for example, whether to
disclose the vulnerability, the timing of the discloure, the amount of
details to provide, and to whom disclosure is made. Note that it is not
necessary for the discoverer to treat all parties the same way. The
timing and amount of details provided can be varied depending on the
information recipient.
This is an (imprecisely-defined) optimization problem, and should be
handled like an optimization problem. Besides manipulating the
disclosure process, the security community can also improve the
performance of optimization by (covertly) conducting survey on the
prevalence of actual exploitation of a vulnerability and/or the
availability of exploitation tools. (This is analogous to improving the
accuracy of the parameters of a model.)
--
Nicol So
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
pr...@prep.synonet.com
> http://www.daemonology.net/papers/htt.pdf
For 300 bits out of a 512 bit key, we'll allow this time...
You are probaly well read in a few places this morning! Now, does
anyone know if the funky cache lock stuff in a few PPC chips would
defend against the cache probing attack?
It would need a large amount of work to defend against, and could
extend to cf, power noise and variations influencing RNG hardware.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Gregory G Rose
I don't think it means what you think it means.
Greg.
--
Greg Rose
232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Qualcomm Australia: http://www.qualcomm.com.au
John Savard
<cper...@sfu.ca> wrote, in part:
>Administrators of multi-user systems are
>strongly advised to take action to disable Hyper-Threading immediately.
That would, of course, reduce the throughput of such machines
significantly.
Alternatively, users of multi-user systems might *not use them* for
computations involving secret keys. Which seems a very good idea for a
number of reasons, such as the fact that operating systems tend to have
security vulnerabilities.
Any genuinely sensitive data in encrypted form should be taken from a
multi-user system to a single-user system, from there put on a floppy,
and then decrypted on a computer which *is not even connected to the
Internet*.
Of course, sensitive data _can_ be viewed on computers with external
data connections - if they are designed according to red/black
principles, but such equipment is not generally available to home users.
Of course, when advances in technology improve Hyper-Threading to the
point illustrated on
http://www.quadibloc.com/arch/ar0501.htm
where one has perhaps 64 threads running concurrently on a 394-way
superscalar processor, such attacks might have a fair amount of noise to
contend with.
(64 vector arithmetic units, 1 main ALU, each one having separate
add/subtract, multiply, and divide pipelines - the first 390 ways - plus
a 'short vector' MMX-like unit, a decimal/character unit, a bit-matrix
multiply and population count unit, and a user microprogram unit for the
other four.)
John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 120,000 groups
Unlimited download
http://www.usenetzone.com to open account
Greg Lindahl
John Savard <jsa...@excxn.aNOSPAMb.cdn.invalid> wrote:
>On Fri, 13 May 2005 00:00:56 +0000 (UTC), Colin Percival
><cper...@sfu.ca> wrote, in part:
>
>>Administrators of multi-user systems are
>>strongly advised to take action to disable Hyper-Threading immediately.
>
>That would, of course, reduce the throughput of such machines
>significantly.
This must be a meaning for the word "reduce" that I haven't seen
before. Hyperthreading on the Pentium4 is often a loss, and has
only proven to be a benefit in a few niches.
-- g
Paul Rubin
> Alternatively, users of multi-user systems might *not use them* for
> computations involving secret keys. Which seems a very good idea for a
> number of reasons, such as the fact that operating systems tend to have
> security vulnerabilities.
But just about every user session involves secret keys. Consider
connecting to the multi-user system through ssh, for example. If the
multi-user system runs an ssh server daemon that users connect to, the
ssh server is vulnerable to key extraction by the users. Any web
hosting service that lets users upload stuff through secure tunnels
and also run cgi's on the system is similarly vulnerable. What are
you suggesting, really? That all those types of services be shut down?
Tim Smith
Eric Cordian <e...@artifact.psychedelic.net> wrote:
> that all users with HT on multiuser systems should immediately turn it
> off.
Doesn't HT only provide a minor performance boost (if any) for most
real-world uses? If so, the cautious approach seems justified.
--
--Tim Smith
Tim Smith
> that flew over the capital.
>
> It could have had anthrax, no a missle no a bomb! no an anthrax
> missle! So they scurried away like fraid little ants. When in reality
> it was pilot error.
It's worse than a mere overreaction to that plane. The biggest threat a
small plane like that presents is that it might release some kind of
airborne agent. The last thing you want to do is get everyone out of
the buildings and into the open, where such an attack is more effective.
The right thing to do is to have people move to the safest area inside
their buildings.
BTW, there was more than just *a* pilot error. The pilot erroneously
entered restricted airspace, so that is *a* error...but he made more
errors. such as not moving off when the helicopters and fighters tried
to escort him out. Given that, treating it as a serious threat was
probably the right thing to do.
--
--Tim Smith
Del Cecchi
"Tim Smith" <reply_i...@mouse-potato.com> wrote in message
news:reply_in_group-131...@news1.west.earthlink.net...
He was totally lost, and paniced and froze when he looked over and saw the
blackhawk. Hadn't filed a flight plan or reviewed the "memo to airmen".
His companion, who was a student pilot, had to take over the controls. Came
within a few minutes of being smoking debris. Read the story. Talk about
pegging the doughhead meter, as we say.
del
D. J. Bernstein
> minimize the harm to the user community
The ultimate source of harm is the designer or implementor who screwed
up in the first place.
For example, if the AES designers hadn't made a serious mistake (``table
lookup: not vulnerable to timing attacks''), and had designed a cipher
that really _does_ take constant time, then we wouldn't have to worry
about AES timing attacks today. Similarly, if RSA implementors had paid
closer attention to the research on fast constant-time arithmetic, then
we wouldn't have to worry about RSA timing attacks today.
The designers and implementors aren't even mentioned in your message.
Instead you blame the harms on ``early disclosure''---you're shooting
the messenger---and on the attackers---who of course should be blamed,
but this blame doesn't create any incentive for them to stop attacking.
All of this is a distraction from what really matters, which is stopping
the designers and implementors from screwing up in the first place.
I realize that, from a shortsighted corporate security perspective, the
behavior of the designers and implementors is an uncontrollable fact of
life, and the speculative positive effects of shooting the messenger
might outweigh the obvious negative effects. However, from a long-term
perspective, the designers and implementors _do_ change their behavior
in response to pressure, and those changes have gigantic effects on
security, all of which are ignored in your model.
news...@comcast.net
> ... Again this is another case of "yes it's an attack" and "yes you can
> mitigate it" ... EVEN with HT turned on. Just don't have users on
> your SSL server box.
This isn't just about SSL servers. What about someone who gets their
PGP encrypted mail on a shared system? A separate, nonprivileged user
might be able to snoop the decryption key in this situation...
--
That's News To Me!
news...@comcast.net
Juuso Hukkanen
<d...@cr.yp.to> wrote:
>Nicol So wrote:
>> minimize the harm to the user community
>
>The ultimate source of harm is the designer or implementor who screwed
>up in the first place.
A new generation of innocent and thin skinned implementors & designers
are born each year. They can not possible handle all the tools they
are given. And if the most expert designers and implementers can not
do make error free products of those then who can. Perhaps it is
simply irresponsible to provide the public cryptographic tools which
are not oversimplified.
I Think it would be good if especially the members of
cryptographic community would start to routinely review each others
code and give comments to at least mark code parts, which they have
_tested to be working seemingly well_. The original author could then
have the honor to write to top comment for example
/*
* Thanks for advices to
* Mr. D. J Bernstein DJB
* Ms. Jane Blum-Blum-Shub JBBS
* Mr. Rivest Shamir-Adler RSA
*/
Then the code could contain tags showing the limits of what has been
tested
/*-> [DJB - randomness only ] */
...
/* <-[DJB] */
/*-> [RSA - test vectors & timer attack resistance only ] */
...
/*<- [RSA] */
Benefits:
1) other Reviewers would know what to property is unchecked - needs
more checking
2) Tom & EEC need to say more :)
3) Other things unknown to me
What say You, how large share of implementation bugs could such
marking catch? Who would suffer of this praxis - none. The marking
version could also be the separate from real distribution version - so
that reviewers could ask / look for ElGamal-review.c version while the
public would use ElGamal.c.
That way the work load could also be shared, if for example JBBS would
notice suspicious parts She could mark them like
/*->? [JBBS - initiating offset size? ] */
...
/*<-? [JBBS] */
Then the next reviewer could continue, from that. With a mind set
adjustment the cryptographic community members could soon take it as a
honor if someone checks actions of their code.
<OT>
Encrypted message follows: "You are going to love parts of t3d"
</OT>
Juuso Hukkanen
Colin Andrew Percival
> Nicol So wrote:
>> minimize the harm to the user community
> The ultimate source of harm is the designer or implementor who screwed
> up in the first place.
The field of computer security is not about deciding who to blame. The
field of computer security is about making systems (more) secure.
Once a vulnerability is identified, it doesn't matter who was responsible
for it existing; all that matters as far as computer security is
concerned is fixing the problem in a manner which results in as little
risk as possible.
Colin Percival
Nicol So
> Nicol So wrote:
>
>>minimize the harm to the user community
>
> The ultimate source of harm is the designer or implementor who screwed
> up in the first place.
Blame assignment is not the issue here. The issue here is how the timing
and manner of disclosing security vulnerabilities affect the user community.
> For example, if the AES designers hadn't made a serious mistake (``table
> lookup: not vulnerable to timing attacks''), and had designed a cipher
> that really _does_ take constant time, then we wouldn't have to worry
> about AES timing attacks today. Similarly, if RSA implementors had paid
> closer attention to the research on fast constant-time arithmetic, then
> we wouldn't have to worry about RSA timing attacks today.
>
> The designers and implementors aren't even mentioned in your message.
Like I said, we're not dealing with blame assignment here. The
discoverer of a security flaw generally had no control over the design
and implementation of the system involved. When a flaw is discovered, it
already exists. The discoverer cannot change history and make it not
there--that's beyond his/her control. The timing and manner of
disclosure, on the other hand, are under the discoverer's control.
It is not the place of a security flaw's discoverer to assign blame, and
to the extent that the responsible party is not part of the mechanism by
which disclosure increases/decreases risk to the affected parties, the
question of blame should not enter into the decision regarding when and
how disclosure should be made.
> Instead you blame the harms on ``early disclosure''---you're shooting
> the messenger---and on the attackers---who of course should be blamed,
> but this blame doesn't create any incentive for them to stop attacking.
I didn't blame anybody for doing or not doing anything. I approached the
problem (i.e. the discoverer's decision on when/how a discovered
security flaw is disclosed) in an objective and dispassionate manner. I
argued that the problem should be viewed as an optimization problem.
What to disclose to whom and when are the manipulables.
I pointed out plausible ways in which early (and by implication late)
discloure can affect users in different situations differently. That
alone should suggest that the optimal choice may not lie at the extremes
(i.e. immediate full public disclosure on one hand, and indefinite
witholding of the discovery from all parties on the other).
There is at least plausible reason to think that better harm reduction
can be achieved by carefully choosing what to disclosure to whom and on
what schedule.
> All of this is a distraction from what really matters, which is stopping
> the designers and implementors from screwing up in the first place.
That's all well and good, but I don't see how carefully choosing the
timing and manner of disclosure would interfere with that goal. Nor do I
see how making a disclosure in a carefully planned manner will prevent a
responsible party from being identified as such.
> I realize that, from a shortsighted corporate security perspective, the
> behavior of the designers and implementors is an uncontrollable fact of
> life, and the speculative positive effects of shooting the messenger
> might outweigh the obvious negative effects. However, from a long-term
> perspective, the designers and implementors _do_ change their behavior
> in response to pressure, and those changes have gigantic effects on
> security, all of which are ignored in your model.
I never advocated shooting the messenger. And I don't see why
constructive feedback through (adverse) publicity requires vulnerability
information be disclosed to all parties at the same level of details and
the same time.
It seems obvious to me that disclosure helps only when the recipient
can and will put the information to "good" use, and that information
won't help someone unless he/she can actually do something useful with it.
D. J. Bernstein
> The issue here is how the timing and manner of disclosing security
> vulnerabilities affect the user community.
In your analysis of the effects, you're ignoring the fact that shooting
the messenger reduces pressure on the designers and implementors who are
ultimately responsible for creating these security problems in the first
place. The impact of this long-term pressure is vastly more important
than any of the short-term issues you've mentioned.
> The discoverer cannot change history
Irrelevant. The problem is much larger than one historical error. The
problem is a gigantic _pattern_ of designers and implementors creating
security holes. Punishing designers and implementors for their mistakes
creates an incentive for them to be more careful in the future.
Your shoot-the-messenger attitude reduces the punishment, and therefore
reduces the incentive. You're seeing punishment as a bad thing because
you're ignoring the massive long-term benefits of the incentive.
David Malone
>In your case you're inability [or unwillingness] to demonstrate the
>attack with limited samples (e.g. typical HTTPS or SSH session) didn't
>help you out. In Colins case the attack is easily avoidable by not
>having users on your webserver box.
Requiring only one user on any box that that carries out data
dependent ops on private data doesn't really seem like a practical
solution to me. It means I can't let people use ssh to log into
my multiuser shell box, for example.
>That doesn't mean either attack isn't real. Ideally I'd love to see
>lockable scratch memory in future x86 processors. That would help
>remove these attacks. But it also doesn't mean I'm going to run and
>hide in the hills from an attack that doesn't apply to how I [at least]
>use cryptography on a daily basis.
I'm not sure that lockable memory is any more of a practical solution
than rewriting applications/libraries. An application's use of
lockable memory would have to be informed by the application's use
of data dependent code, which basically means the developer has to
rewrite/annotate the code.
David.
Tom St Denis
David Malone wrote:
> "Tom St Denis" <tomst...@gmail.com> writes:
>
> >In your case you're inability [or unwillingness] to demonstrate the
> >attack with limited samples (e.g. typical HTTPS or SSH session)
didn't
> >help you out. In Colins case the attack is easily avoidable by not
> >having users on your webserver box.
>
> Requiring only one user on any box that that carries out data
> dependent ops on private data doesn't really seem like a practical
> solution to me. It means I can't let people use ssh to log into
> my multiuser shell box, for example.
If you're amazon or Ebay or something... you can afford to buy a box
soley for "doing apache", another solely for doing "mysql", ....
If you're a home user, don't give out shells like candy. There is a
security risk in giving out shells. Most people don't use quotas for
instance, kernel exploits do come up from time to time, etc....
> >That doesn't mean either attack isn't real. Ideally I'd love to see
> >lockable scratch memory in future x86 processors. That would help
> >remove these attacks. But it also doesn't mean I'm going to run and
> >hide in the hills from an attack that doesn't apply to how I [at
least]
> >use cryptography on a daily basis.
>
> I'm not sure that lockable memory is any more of a practical solution
> than rewriting applications/libraries. An application's use of
> lockable memory would have to be informed by the application's use
> of data dependent code, which basically means the developer has to
> rewrite/annotate the code.
Not really, a patch for LTC for instance, would add about 5 lines of
code to the existing AES given such a kernel call.
In the case of AES all you have to lock is the sbox tables [4KB]. In
RSA you'd want to lock your temporary variables [<32KB]. Again a
simple [not super trivial] patch to LTM could do this.
Tom
Bernd Paysan
> Irrelevant. The problem is much larger than one historical error. The
> problem is a gigantic _pattern_ of designers and implementors creating
> security holes. Punishing designers and implementors for their mistakes
> creates an incentive for them to be more careful in the future.
... as if punishing an implementor would have a positive effect ...
It is well known that dogs expect punishment (that's the way wolf packs
works), and therefore, to teach a dog tricks, you have to resort to punish
bad behavior (rewarding good ones is helpful, but not strictly necessary).
If you try the same thing with cats, punishment only annoys the cat, so you
never achieve anything by punishing cats. Cats do work on rewards, though.
Programmers in general are rather independent minds, and work more like cats
than dogs. Punishing alienates programmers, leads to stress, and negative
feelings towards the project and the leaders. You don't achieve anything
with punishment, shouting, finger-pointing, and that like, but you achieve
a lot with positive feedback. Positive feedback in cases like this one are
e.g. suggestions for remedies.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Nicol So
>
> Your shoot-the-messenger attitude reduces the punishment, and therefore
> reduces the incentive. You're seeing punishment as a bad thing because
> you're ignoring the massive long-term benefits of the incentive.
Please stop mischaracterizing my position as "shooting the messenger". I
advocated no such thing.
John E. Hadstate
"Del Cecchi" <dcecchi...@att.net> wrote in message
news:3entuvF...@individual.net...
>
>
> He was totally lost, and paniced and froze when he looked
> over and saw the blackhawk. Hadn't filed a flight plan or
> reviewed the "memo to airmen".
The area around the Washington DC monuments, including the
Capitol and the White House, have been marked on sectional
maps as restricted and prohibited since I was a student
pilot more than 30 years ago. You don't go into such
airspace unless you are on an IFR flight plan and under the
control of ATC and ordered to go there by ATC. No American
flight instructor is ignorant of this fact.
tq...@pobox.com
> messenger". I advocated no such thing.
How can you avoid that charge? You're criticising people who do
pro-bono security analysis work, find incredibly valuable information,
and release it to the public free of charge.
Complaints about "irresponsible disclosure" are straightforward
examples of psychological transference. The researcher didn't CREATE
the problem. The researcher DOES have a moral responsibility to publish
the problem (which becomes clear when you contrast them with the
unscrupulous parties who find and then privately SELL vulnerability
details). From what authority do system administrators claim the right
to add further hurdles to this process?
Tony Nelson
Bryan Olson <fakea...@nowhere.org> wrote:
...
> I understand the importance of protecting production servers,
> and even possible treats to National Security. My own thing is
> that I'm most interested in protecting the ordinary user, even
> if he or she doesn't bother to learn to protect him or her own
> self.
Way back when Steam Engines were high-tech, there was a long time when
it was debatable whether a steam boiler should have a safety valve.
After all, the trained experts using steam engines and other boilers
knew well what pressure the boiler could take, and had a guage to watch.
Boiler explosions were common, and often made the local news. Nowadays,
with even water heaters having safety valves, boiler explosions are rare
and ordinary users can have a boiler or two in their house, without much
chance that they will destroy the neighborhood with it.
There are countless other examples, such as safety glass and seat belts
in automobiles. One thing all the examples I know of have in common is
that they were all forced on a reluctant industry by government
regulation.
So I also favor protecting the ordinary user from our fabulous new
gadgets' tendency to blow up, and applaud the efforts to get some of the
problems fixed (decades) before governments force the issue.
________________________________________________________________________
TonyN.:' *firstname*nlsnews@georgea*lastname*.com
' <http://www.georgeanelson.com/>
Nicol So
>>Please stop mischaracterizing my position as "shooting the
>>messenger". I advocated no such thing.
>
> How can you avoid that charge? You're criticising people who do
> pro-bono security analysis work, find incredibly valuable information,
> and release it to the public free of charge.
Go back and re-read my previous messages in this thread. Where did I
"criticise people who do pro-bono security analysis work, find
incredibly valuable information, and release it to the public free of
charge"?
brian_c...@hotmail.com
--- two groups of people whose interests are in conflict but believing
they are the best!
But frankly, designing or implementing secure systems is subtle. If a
system is claimed to be provably secure, it's probably not! There are
always vulnerabilities around the corner when you declare your system
is secure. How could one gurantee he have already considered all kinds
of attacks or adversary capabilities when designing a system. Even
with provable security, what happens if the attacks come from
unanticipated adversary capabilities? Perhaps everyone of us should
keep in mind that the best promise one could give is a system will not
be broken in the forseeable future. When RSA was designed, who knew
the attacker would have the capabilities to launch side-channel
attacks, to measure the timing of computation, etc.. Computer
processors were still in their infant stage. Technology is advancing,
new attacks will definitely come as a consequence. Just blaming the
designer not having considered thorougly is not responsible, of course,
this does not include the careless ones. On the other hand, designers
should be more careful and open to feedback, not just close their minds
to think they have got the most innovative solution....
One question that bothered me for quite a while is what the people
working on cryptanalysis look for. What are their incentive? What are
their goals? Would people admire any destructive acts? I think most
of the hackers or attackers works for their ego, to show the world how
smart they are in showing others' mistakes. That's good! Without
them, all security partitioners would have lost their jobs. These
harsh wording are, of course, not for the researchers with a righteous
goal in locating a system's vulnerabilities ahead of the bad guys.
Frankly, we need the collaboration of both designer and hacker to build
a more secure system. When you start fire, I guess it would always be
a better question to ask what the response of average people would be
when I publish the weakness of a system they are using. Will they care
about how you can achieve such an attack? What they concern is "Well,
is it still secure enough for use? Any fix?". Here I would have my
humble suggestion to the people working on cryptanalysis: if you find a
new attack, it would always be good that you find a fix before you
spread out your incredible work. People tend to admire people with
constructive suggestions and work, and hate those bringing destruction.
If you just want to show how smart you are in breaking others'
designs, there is no need to defend here --- a messenger is still
someone who brings troubles to all common people. If you have guts,
why don't you research on the vulnerabilities in the CIA, FBI or even
military networks and systems, and then publish your findings widely?
For sure, you will be arrested within hours for risking the safety of
the Great United States and charged for having the Weapons of Mass
Destruction. This is the common ground for the US government to accuse
other innocents!
toby
Punishing a programmer personally is probably not meant. I think the
idea of "punishment" proposed here is more one of "negative
reinforcement" in a Darwinian sense. Such penalties are intended to
produce systemic changes - not a personal resolution by the programmer
to "make no more mistakes". One positive effect might be appropriate
budgeting for design, consultation and testing, which would have a
great effect on the frequency of defects.
I am sure I am not alone in being unsurprised when vulnerabilities are
created in large numbers, having observed that "the way things are
done" commercially is "as cheaply and quickly as we can get away with".
I think the commercial system is so dysfunctional that only significant
penalties - such as adverse publicity and boycotts - may have any
effect. Holding vendors publicly accountable for their errors - not
individuals - is necessary. Nobody should think twice about pointing a
finger at a delinquent corporation, and if we quail at this, the
feedback system is weakened to our detriment.
--T
Colin Andrew Percival
cryptographers who have read my paper and would be willing to comment
on it. Obviously Ernie Brickell falls into thie category, but he works
at Intel, so I'd like to find someone who is, err, less subject to
political influence.
I know there are a few well-recognized cryptographers who post here, and
even more who read sci.crypt without posting; would any of you be willing
to talk to the media about this?
Colin Percival
D. J. Bernstein
> Please stop mischaracterizing my position as "shooting the messenger".
You said that ``public announcement of a vulnerability'' would
``increase the risk'' to users. That's shooting the messenger.
Anyway, the terminology doesn't matter. What matters is that you're
ignoring the ultimate source of harm, namely the designers and
implementors who created the security problem in the first place.
Joe Peschel
news:slrnd8fgup...@stoneport.math.uic.edu:
> You said that ``public announcement of a vulnerability'' would
> ``increase the risk'' to users. That's shooting the messenger.
>
No, it isn't. Blaming the messenger for delivering bad news is "shooting
the messenger."
> Anyway, the terminology doesn't matter.
Yes, terminology does matter.
J
--
__________________________________________
http://www.impeach-bush-now.org
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
Nicol So
> Nicol So wrote:
>
>>Please stop mischaracterizing my position as "shooting the messenger".
>
> You said that ``public announcement of a vulnerability'' would
> ``increase the risk'' to users. That's shooting the messenger.
No, that's not shooting the messenger. In this discussion, I never
advocated punishing anyone for disclosing security flaws that they
discover. I've been careful not to assign blame because, unlike
discussing the likely consequences of particular actions, the
attribution of causes to a state of affairs is necessarily
interpretational and prone to be controversial.
My assertion that early disclosure increases the risk to some users is a
purported true statement. You can agree with it or you can disagree with
it. If you don't think it is true, you can refute it with evidence, or
you can at least make a persuasive argument why it is not true. You can
even accept that it is true but deny that anyone should do anything
different because of that.
My analysis is an examination of the connection between choices and
likely consequences. It is not an attitude.
> Anyway, the terminology doesn't matter. What matters is that you're
> ignoring the ultimate source of harm, namely the designers and
> implementors who created the security problem in the first place.
I really don't want to assign blame here, but I want to point out that
it is often not clear what it means for some agent or circumstances to
be the "ultimate" cause of something.
Paul Rubin
> My assertion that early disclosure increases the risk to some users is
> a purported true statement.
I'd say that's definitely true. But your statement was somewhat
stronger, i.e. that early disclosure increases risk in general, not
just to some users. I interpret DJB's view as saying: early
disclosure may increase the risk to some users, but it decreases the
risk to enough other users that the net effect is an overall decrease,
and so early disclosure is good for users in general, even if it's bad
for some specific users some of the time.
So you and DJB really do disagree.
Nicol So
I invite you to go back to my earlier messages to see exactly what I
wrote. Here're excerpts from <Jqohe.1321$sr1.988@trnddc04>, my message
that started this sub-thread:
"... Early general, public announcement of a vulnerability may decrease
the risk to some users, but increase the risk to others. ..."
"Early disclosure can increases risk, such as by increasing the number
of attackers who may try to acquire, independently develop, and/or
execute exploits of the vulnerability. ... On the other hand, early
disclosure can also decrease risk by causing users to take appropriate
risk-mitigation measures. ..."
"This is an (imprecisely-defined) optimization problem, and should be
handled like an optimization problem."
From another message of mine:
"I pointed out plausible ways in which early (and by implication late)
discloure can affect users in different situations differently. That
alone should suggest that the optimal choice may not lie at the extremes
(i.e. immediate full public disclosure on one hand, and indefinite
witholding of the discovery from all parties on the other).
There is at least plausible reason to think that better harm reduction
can be achieved by carefully choosing what to disclosure to whom and on
what schedule."
--
Unruh
>Nicol So wrote:
>> Please stop mischaracterizing my position as "shooting the messenger".
>You said that ``public announcement of a vulnerability'' would
>``increase the risk'' to users. That's shooting the messenger.
No it is not. He said nothing about the messenger. He made a claim of fact.
You can dispute such a claim by other facts or by showing it is wrong. You
cannot change it from a statement of fact to a statement of blame however.
`
>Anyway, the terminology doesn't matter. What matters is that you're
>ignoring the ultimate source of harm, namely the designers and
>implementors who created the security problem in the first place.
The question of how to handle security holes is an old one, with much heat
and little light. Do we actually have any evidence as to which procedure
(public announcemnt vs private discussion with the developer) reduces the
harm to the public most? I do not think so. At that point it becomes a
matter of opinion unsopported by evidence.
John E. Hadstate
"Unruh" <unruh...@physics.ubc.ca> wrote in message
news:d69ahh$r71$1...@nntp.itservices.ubc.ca...
>
>>Anyway, the terminology doesn't matter. What matters is
>>that you're
>>ignoring the ultimate source of harm, namely the designers
>>and
>>implementors who created the security problem in the first
>>place.
>
> The question of how to handle security holes is an old
> one, with much heat
> and little light. Do we actually have any evidence as to
> which procedure
> (public announcemnt vs private discussion with the
> developer) reduces the
> harm to the public most? I do not think so. At that point
> it becomes a
> matter of opinion unsopported by evidence.
Public announcement alerts the public to the fact that they
must trade-off the risks and rewards of using a package with
known vulnerabilities.
Private discussion with the developer may eventually produce
a revised version with the vulnerabilities fixed, but that
does nothing for those people who are using the original
package and, because the public announcement was never made,
don't know that they should upgrade.
If you're considering applications that are used by few
people (so that the developer might reasonably be able to
notify each user that an upgrade is required), private
discussions with the developer might avoid exposing a few
people to exploitation.
Otherwise, it seems clear that public disclosure offers the
public an opportunity to protect itself by not using the
product, or by not doing things with the product that expose
the vulnerability.
Ken Hagan
>
> The question of how to handle security holes is an old one, with much heat
> and little light. Do we actually have any evidence as to which procedure
> (public announcemnt vs private discussion with the developer) reduces the
> harm to the public most? I do not think so. At that point it becomes a
> matter of opinion unsopported by evidence.
I'm somewhat stunned that people here seem to believe they are mutually
exclusive options. The choice is actually how long an interval to leave
between telling the vendor(s) and telling the customer(s). Anyone who
seriously advocates either "zero" or "infinity" is a pillock. The former
is equivalent to assuming the black hats *always* discover the holes
first and the latter assumes they never discover them at all.
Jean-Luc Cooke
> In article <1116003308.1...@o13g2000cwo.googlegroups.com>,> >Jean-Luc Cooke wrote:
> >> The Princess Bride's word was "inconceivable"... if only I could
> >spell
> >> it.
> >
> >And you know this because...?
> I don't think it means what you think it means.
hehe. Now I have to go watch that movie again. :)
JLC
--
brian_ja...@hotmail.com
John E. Hadstate wrote:
> Public announcement alerts the public to the fact that they
> must trade-off the risks and rewards of using a package with
> known vulnerabilities.
>
> Private discussion with the developer may eventually produce
> a revised version with the vulnerabilities fixed, but that
> does nothing for those people who are using the original
> package and, because the public announcement was never made,
> don't know that they should upgrade.
>
> If you're considering applications that are used by few
> people (so that the developer might reasonably be able to
> notify each user that an upgrade is required), private
> discussions with the developer might avoid exposing a few
> people to exploitation.
>
> Otherwise, it seems clear that public disclosure offers the
> public an opportunity to protect itself by not using the
> product, or by not doing things with the product that expose
> the vulnerability.
Man, your argument is misleading. If the car manufacturers find a flaw
in their design, even though it is just a little problem about the seat
belt, they need to inform the customer for exchanging a new one. Note
that they may not give out details about the problem. In another case,
if the milk powder you buy is below certain health standard, the
manufacturer needs to get back all its product on the market.
Exchanging a new one for a flawed product is so common in both high-end
and low-end products. I don't see why an exchange for security product
(with weakness due the vendor's poor design) is not possible. I would
be happy to hear your comments. Of course, for the cash grab vendors,
they won't do so. But customers could choose not to purchase from them
at the very beginning.
When your attack techniques are released to the public, the designers
need to race with the mischievous attackers. If they fail, who will
suffer? It's the customers. You think you could alert the customers
by publishing your attack tenchinque. You are dreaming! I don't see
the average customers would pay so much attention about the news of
their systems being vulnerable to a new attack until they suffer from a
widespread attack. If you don't believe. Look at the computer virus
case. Some viruses are well-known to the computer community who
creates new definition files immediately, but not until they are
widespread affecting millions of people, nobody would be aware of it
and look for a cure.
Unruh
>"Unruh" <unruh...@physics.ubc.ca> wrote in message
>news:d69ahh$r71$1...@nntp.itservices.ubc.ca...
>>
>>>Anyway, the terminology doesn't matter. What matters is
>>>that you're
>>>ignoring the ultimate source of harm, namely the designers
>>>and
>>>implementors who created the security problem in the first
>>>place.
>>
>> The question of how to handle security holes is an old
>> one, with much heat
>> and little light. Do we actually have any evidence as to
>> which procedure
>> (public announcemnt vs private discussion with the
>> developer) reduces the
>> harm to the public most? I do not think so. At that point
>> it becomes a
>> matter of opinion unsopported by evidence.
Opinion is not evidence. What you do below is to give a plausible scenario
which however has no evidence to support it. YOu can equally give the
opposite argument that release of info about the hole alerts the bad ones
to another attack vector, and since only a very small fraction of users
will ever see the wraning, those additional attacks generated by the public
announcements will vastly outweigh the few people the announcement gets to
protect themselves. Again, a plausible scenario without evidence. And
because the evidence is missing the discussions get nasty, and
unproductive.
Unruh
And your evidence is? And "pillock" contributes to the discussion how?
Again vehemence substitutes for evidence.
Nick Maclaren
In article <d6ag62$bd8$2...@nntp.itservices.ubc.ca>,
Unruh <unruh...@physics.ubc.ca> writes:
Let me pour oil onto burning waters :-)
If we ignore the vehemence, there IS evidence for what Ken Hagan
has said - but precious little, as YOU say. We know of cases where
a policy of not telling the customer has led to one of not putting
resources into not fixing the bug. And we know of cases where
telling everyone immediately has caused serious (if temporary)
problems. Beyond that, what do we know? Not a lot.
Regards,
Nick Maclaren.
Terje Mathisen
> Hyper-Threading, as currently implemented on Intel Pentium Extreme
> Edition, Pentium 4, Mobile Pentium 4, and Xeon processors, suffers from a
> serious security flaw. This flaw permits local information disclosure,
> including allowing an unprivileged user to steal an RSA private key being
> used on the same machine. Administrators of multi-user systems are
> strongly advised to take action to disable Hyper-Threading immediately.
>
> I will be presenting this attack at BSDCan 2005 in Ottawa at 10:00 AM EDT
> on Friday May 13th, and at the conclusion of my talk I will also
> releasing a paper describing the attack and possible mitigation
> strategies. For more details, see my web page on the topic at
> http://www.daemonology.net/hyperthreading-considered-harmful/
>
> I will follow up here with more details after my talk on Friday morning.
I read the paper, it did remind of a post I made more than 10 years ago,
about how RDTSC allowed timer-based covert channels between different
processes.
What you've found is yet another instance of the fact that there is no
real security if you allow physical access (or in your case, running
arbitrary user-level code).
OTOH, simply allocating half the L1 and L2 cache to each thread, which I
believe I've seen some support for in recent cpu arcitecture manuals,
would effectively stop this particular leak, right?
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Colin Andrew Percival
> OTOH, simply allocating half the L1 and L2 cache to each thread, which I
> believe I've seen some support for in recent cpu arcitecture manuals,
> would effectively stop this particular leak, right?
Yes (I mention that in the first paragraph of section 6). Current Intel
processors don't have that feature.
There is also a more complex option, but I don't know if it is actually
feasible.
Colin Percival
Valery Pryamikov
disclosure in terms of "shooting the messenger" is: in what position should
we put the developers? Would not it be like advocating shooting Michelangelo
for the flaw he did when he draw the finger of the God in his "Creation of
the Adam". The finger is flawed after all (and that could be confirmed by
... anyone). Should not Michelangelo were shot and crucified for letting
that flaw into his painting? ...
The work of security researchers is of no doubt very difficult and is not
quite rewarding. but what about the work of the developers that put up all
these millions of lines of source code?... Just try to appreciate how much
efforts it would take simply to produce all these lines (not speaking about
designing and debugging them).
I'm totally against shooting the messenger... But please, don't shoot
Michelangelo in the process.
-Valery.
Terje Mathisen
Use the memory range controls to designate these tables as uncacheable
_would_ work, while making the code somewhat (:-() slower.
John E. Hadstate
<brian_ja...@hotmail.com> wrote in message
news:1116259204....@g14g2000cwa.googlegroups.com...
Misleading to whom? I thought it was emminently clear and
obvious.
> If the car manufacturers find a flaw
> in their design, even though it is just a little problem
> about the seat
> belt, they need to inform the customer for exchanging a
> new one.
Your analogy is flawed. Suppose that *you* find a little
problem regarding the seat belt. You make a good faith
effort to contact the manufacturer, with the result that the
manufacturer tells you to go pound sand and reminds you that
it has essentially infinite legal resources that it will use
to pummel you into dust if you announce your findings
publicly. Care to go back and re-read what I wrote?
> When your attack techniques are released to the public,
> the designers
> need to race with the mischievous attackers. If they
> fail, who will
> suffer? It's the customers.
In reality, there are countless documented examples of
responsible software engineers that have gone far beyond the
call of duty to bring problems to the attention of the
manufacturers. Only when they were repeatedly ignored,
rebuffed, and threatened did they opt to make a public
announcement of their findings. This is simply professional
ethics overriding professional courtesy. It's a shame that
the two should be forced into conflict.
The customers will suffer because of the manufacturer's
mis-guided secrecy (around here we refer to it as "security
by obscurity" and take delight in targeting it with various
biochemical materials). Logically, if the software has a
reportable exploit, it has already been discovered and
exploited at least once. Quite likely, it has been
exploited many times and those profiting from the exploit
don't advertise it for obvious reasons.
> You think you could alert the customers
> by publishing your attack tenchinque. You are dreaming!
I don't, and I'm not. It's the manufacturer's
responsibility to close the holes in its software and to
make its customers whole. Why was it so insistent on that
software registration? Surely it wasn't for the purpose of
selling my private information to spammers!
John E. Hadstate
> "John E. Hadstate" <jh11...@hotmail.com> writes:
>
>
>>"Unruh" <unruh...@physics.ubc.ca> wrote in message
>>news:d69ahh$r71$1...@nntp.itservices.ubc.ca...
>>>
>>>>Anyway, the terminology doesn't matter. What matters is
>>>>that you're
>>>>ignoring the ultimate source of harm, namely the
>>>>designers
>>>>and
>>>>implementors who created the security problem in the
>>>>first
>>>>place.
>>>
>>> The question of how to handle security holes is an old
>>> one, with much heat
>>> and little light. Do we actually have any evidence as to
>>> which procedure
>>> (public announcemnt vs private discussion with the
>>> developer) reduces the
>>> harm to the public most? I do not think so. At that
>>> point
>>> it becomes a
>>> matter of opinion unsopported by evidence.
>
> Opinion is not evidence. What you do below is to give a
> plausible scenario
> which however has no evidence to support it.
I won't dispute your right to embarrass yourself publicly.
In claiming that there is no evidence to support my
scenarios you going out of your way to pretend that you are
extremely ignorant about what's going on around you. The
evidence that my scenarios are real is there. It is
documented in such mainstream publications as MSNBC News and
Time Magazine and countless specialized publications with
which you, as a professional in the field, have an
obligation to have at least a passing acquaintance.
John E. Hadstate
"Valery Pryamikov" <val...@nospam.harper.no> wrote in
message news:4288f0f4$1...@news.broadpark.no...
> The thing that I always think in cases when people start
> discussing open disclosure in terms of "shooting the
> messenger" is: in what position should we put the
> developers? Would not it be like advocating shooting
> Michelangelo for the flaw he did when he draw the finger
> of the God in his "Creation of the Adam". The finger is
> flawed after all (and that could be confirmed by ...
> anyone).
How do you know the finger is flawed? Have you ever seen
God's fingers?
Bryan Olson
> David Malone wrote:
>>Requiring only one user on any box that that carries out data
>>dependent ops on private data doesn't really seem like a practical
>>solution to me. It means I can't let people use ssh to log into
>>my multiuser shell box, for example.
>
> If you're amazon or Ebay or something... you can afford to buy a box
> soley for "doing apache", another solely for doing "mysql", ....
O.T.O.H., they cannot feasibly limit each box to running
processes of just one user at a time. They have hundreds, maybe
thousands on their technical staffs, and businesses generally
lose more in theft and fraud to insiders than to external
attackers.
Process separation supports a frighteningly large part of modern
information security. Leaking crypto keys between processes is a
disaster.
[...]
> In the case of AES all you have to lock is the sbox tables [4KB]. In
> RSA you'd want to lock your temporary variables [<32KB]. Again a
> simple [not super trivial] patch to LTM could do this.
Sounds plausible, perhaps in consert with the "slotting" you
noted. If you can demo the methods in your code, and write up
the arguments that the resulting library supports systematic
resistance to these attacks, you might find yourself at the
forefront of an important field.
--
--Bryan
Paul Rubin
> O.T.O.H., they cannot feasibly limit each box to running processes
> of just one user at a time. They have hundreds, maybe thousands on
> their technical staffs, and businesses generally lose more in theft
> and fraud to insiders than to external attackers.
>
> Process separation supports a frighteningly large part of modern
> information security. Leaking crypto keys between processes is a
> disaster.
Here's a low cost PCI plug-in card that does symmetric and public key
crypto in hardware (HiFN 7955 chip). Also does LZS compression, which
is useful on web servers (mod_gzip would need a patch to use it):
http://soekris.com/vpn1401.htm
Info about the chip is here:
http://hifn.com/products/7955-7956.html
The docs for this are no longer online and it's not clear whether it
does any key management and I don't see a guarantee that the crypto
ops take constant time.
David Wagner
>My personal opinion is that the recommendation that everyone disable
>hyperthreading on multi-user systems is premature.
Some personal opinions:
1) I usually assume that any typical multi-user system is insecure.
If you have untrusted users with accounts on your machine, you should
assume they can get root on your machine if they care enough.
Today's commodity OS's usually aren't able to stand up to that threat model.
2) Given that, the real question is whether this attack can be mounted
even if the attacker does not have an account on your system. For instance,
if the attacker can get you to run Java applets of his construction on your
system, can he steal your RSA keys? What is the full extent of ways that
attackers can mount such hyperthreading attacks?
3) If the answer to question 2) is sufficiently limited, we might wish
to consider alternative countermeasures. For example: don't run a web
browser, Java applets from untrusted sources, etc. on the same machine
where you store your RSA key.
4) Any decision on how to respond to this threat should begin by doing
a cost-benefit analysis. What are the possible countermeasures? What
are the costs and benefits of each countermeasure? For instance, if the
performance benefit from hyperthreading is minimal, and the value of the
RSA key is very high, then disabling hyperthreading might be the right
answer in that scenario. But the answers to cost-benefit analyses are
often very fact- and scenario-dependent, so I'm not sure there are any
general answers that are optimal for everyone.
David Wagner
>Requiring only one user on any box that that carries out data
>dependent ops on private data doesn't really seem like a practical
>solution to me. It means I can't let people use ssh to log into
>my multiuser shell box, for example.
You can't let *untrusted* people log onto your box if you
want to be secure against this hyperthreading vulnerability.
If you trust Alice and Bob not to exploit this vulnerability,
you can let them log on. For instance, if Alice and Bob already
have root access on your machine, there's no harm to giving them
user accounts as well.
But if you were letting untrusted users log onto your box,
then you were probably already vulnerable even without this
hyperthreading issue. The sad fact is that few operating systems
today are able to provide adequate security against malicious local
users. There are just too many local-to-root exploits.
My pragmatic philosophy is to not even bother trying to stop
local-to-root-exploits; it's too much like trying to plug a leaky
sieve. Rather, I focus on not letting untrusted users log onto my
machine, and on preventing remote exploits.
David Wagner
>The ultimate source of harm is the designer or implementor who screwed
>up in the first place.
This statement overlooks the fact that, in some cases, disclosing the
vulnerability can increase the likelihood that the vulnerability will
be exploited.
Are you suggesting that if implementor Indy screwed up and wrote buggy
code, then the bug-discoverer should seek to "punish" users who use Indy's
code by publishing the bug, even if this makes it more likely that the
users will be exploited? Is the idea that if we can force users to
feel the pain, then they will stop using Indy's code, and this will
indirectly motivate implementors not to screw up? I guess that this
might be an accurate assessment of what will motivate implementors, but
the idea of improving code quality by deliberately seeking to make users'
lives more painful gives me pause.
As for whether to blame early disclosure or the implementor for
exploitation of vulnerabilities, well, I don't think it makes sense to
try to pin the "blame" on a single factor. Both contribute (at different
rates) to the likelihood that a vulnerability is exploited.
David Wagner
>pro-bono security analysis work, find incredibly valuable information,
>and release it to the public free of charge.
I didn't see him argue that. I saw him write that the question of
the best bug-disclosure policy to follow is an optimization problem,
and the best policy is fact- and context-dependent. That sounds about
right to me.
I don't think there is a single right answer that is right for all
situations. For any given bug, there may be probably multiple approaches
that are not unreasonable. Which one is "best" is a matter for debate,
and may well differ from one bug to another.
brian_ja...@hotmail.com
> > If the car manufacturers find a flaw
> > in their design, even though it is just a little problem
> > about the seat
> > belt, they need to inform the customer for exchanging a
> > new one.
>
> Your analogy is flawed. Suppose that *you* find a little
> problem regarding the seat belt. You make a good faith
> effort to contact the manufacturer, with the result that the
> manufacturer tells you to go pound sand and reminds you that
> it has essentially infinite legal resources that it will use
> to pummel you into dust if you announce your findings
> publicly. Care to go back and re-read what I wrote?
>
Man, did you buy cars from an authorized dealer? Which stupid country
are you living? I didn't face this problem in mine. When I made a
complaint last time, I got a new one and found notice in the paper the
next week.
It sounds like you are talking something irrelevant. You could alert
the public but is it necessary to give a full disclosure of your
attacking techniques? How many average users will care about how you
attack a system? If you let them know there is some kind of
vulnerabilities in the system (but without the details of the attacks),
couldn't you achieve your intention to alert users?
Tom Linden
So do you believe the VMS is reasonably secure only due to its relative
obscurity, or do you think the security module is adequately robust?
Bodo Moeller
[...]
> 2) Given that, the real question is whether this attack can be mounted
> even if the attacker does not have an account on your system. For instance,
> if the attacker can get you to run Java applets of his construction on your
> system, can he steal your RSA keys? What is the full extent of ways that
> attackers can mount such hyperthreading attacks?
>
> 3) If the answer to question 2) is sufficiently limited, we might wish
> to consider alternative countermeasures. For example: don't run a web
> browser, Java applets from untrusted sources, etc. on the same machine
> where you store your RSA key.
I would not expect the scope of hyperthreading cache-timing attacks to
be that limited (or similar attacks on multi-processor systems with a
shared L2 cache, or possibly even single-processor systems where
context switches are not too infrequent compared with the speed of
modular arithmetic).
Consider a server system with a fast network connection, running a
simple (non-cryptographic) server process that allows clients to
initiate directed data reads from memory, such as HTTP "Range" queries
on a file in the operating system's buffer cache. Even such a very
simple server process could allow adversaries to obtain processor
cache timings. Thus, if the server process runs in parallel to a
process doing RSA secret-key computations, an attack may very well be
feasible if the exponentiation algorithm used does not have a memory
access pattern that is independent of the specific exponent.
(An interesting observation is that "extra-secure" very long RSA keys
can actually be *less* secure under this model because they make it
easier to obtain the cache timings in time, before the RSA algorithm
proceeds to another modular multiplication or squaring.)
David Wagner
>So do you believe the VMS is reasonably secure only due to its relative
>obscurity, or do you think the security module is adequately robust?
I'm afraid I don't understand what your question has to do with the post
you were responding to, but since you asked: I don't know enough about
VMS to have any opinion on it.
In case it was unclear, I wasn't recommending security through obscurity.
I was talking about how to choose among multiple countermeasures, all of
which successfully stop the attack, but at different costs and with different
requirements on the rest of the system.