HP3000-L Archives

April 2014, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Sun, 13 Apr 2014 10:19:47 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
On 4/12/2014 11:23 PM, Richard Corn wrote:
> Given that lastpass pw's are encrypted on your device, transmitted and stored at lastpass in encrypted form, how would heartbleed compromise them?

Well, as we are frequently required to say, "It depends".

From the architecture of MPE/iX and the 3000 (which is largely
irrelevant here, but it is the architecture that I'm most familiar
with), I would say no, unless something within the process in question
(HTTP, TLS Mail, LDAP, etc) issued a library call to interface with
LastPass.

Heartbleed can read memory of the process in question...  if there are
strict security provisions to prevent cross-process memory access, it
can only read the memory of the affected process, within the bounds of
the process userID.  If it is a unix/linux process executing as root,
then I don't know... can root read memory of any given process?  And the
memory it is reading is typically "heap" memory, as HTTP servers do lots
of malloc() calls to handle memory requests.  But again it is somewhat
architecture dependent...  can you read 64K contiguous bytes from the
malloc() heap and swipe your read across the process static memory as
well? 

It's sort of a "wheel of fortune" spin as to what you get back, subject
to architectural limitations and process privileges. 

But bear in mind that the SSL "heartbeat" in question works both ways. 
It is entirely possible for a server to issue a heartbeat request to a
client, and a lot of client software has been built with vulnerable
libraries.  So a malicious server can read YOUR memory as well.  I don't
know enough details of Windows or MacOS to know what memory might be
exposed there, but would be similarly subject to what is available to
the process under attack. 

Now that most server issues have been addressed, the focus is turning to
the client side.

It's still a "read-only" issue, but can potentially expose a lot.  It's
not the worst that has/is/might happen, but it's primarily the broad
exposure that is scary in this case.  Someone stated on a security list
(Paul Vixie, of Internet foundation fame) said about Bruce Schneier's
reaction to the Heartbleed issue (language alert... I'm making a quote)...:

> "really bruce? on a scale of doesn't-matter-at-all to
> worst-thing-you-could-have-previously-imagined, a read only exploit is
> even worse than that? no remote file modification, no root shell, no
> non-root shell, no data-modification, no arbitrary file system reads...
> just a read only heap exploit, and it's worse than anything you could
> have previously f*cking imagined?
>
> gentlemen and ladies, we have met the enemy, and they are our egos.
>
> vixie "

Jeff

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2