Risk Assessment

[Richard Lynch]

At 10:27 PM 10/22/98, Edward S. Marshall wrote:
>On Thu, 22 Oct 1998, Richard Lynch wrote:
>> Did everything via telnet, since my ISP is 1000 miles away.

>> Generated keys using insecure memory, since I can't chown the binary to root.
>
>"insecure memory"? It's only insecure if GPG doesn't clean memory properly

PGP seemed very adamant in its warnings that I was using "insecure memory".
I was earlier told that to fix it, I had to chmod the binary to 4xxx
(?)...  My reading of the man page tells me that 4xxx means to suid before
running... My interpretation of that was that it would suExec (suid?) to
the owner, which is just me, who was running it in the first place...

>a) define a non-shared environment that you control for the purposes of
>   this project (ie a machine -you- control), or

I do control the Windoze box... well, as much as one can be said to be in
control of a Windoze box. :-)

>But you've got an implicit level of trust with the administration of the
>system you're doing this on. Don't put anything on the system you wouldn't
>hand them anyway, unless it's password-protected before it gets on the
>system.

I trust the ISP.  They are extremely competent, and seem to be really
on-the-ball security wise.  They are even users of CyberCash.  It's just
that my client's profit margin... well, I've already moaned enough about
that. :-)

>> Elected not to use a passphrase, since it would be in a web-site script,
>> which is publicly visible anyway.
>
>Not much you -can- do here. This is a case where, if you want automation,
>you must rely on the security of underlying operating system (and the
>trust issue between you and the administrator) to save you.
>
>Assume, however, that if you have a root compromise, -all- of your keys
>are compromised. Your "break-in recovery" procedure should cover a means
>by which you'll regenerate those keys and get them to the customer.

That's pretty easy...  I can make new keys whenever I'm feeling insecure,
and getting them to the clients is not too terribly difficult.

>> Yeah, I *could* create a third script in a secure area to call that
>> would spit the password out to the encryptor...  if I knew exactly how
>> to do that...
>
>Again, you're still relying on the security of the system anyway, so I'd
>think you're better off with the original approach.

The system itself is pretty secure... It's my attempting to use it on a $0
budget that's and with minimal understanding that's causing the holes.
Which is why I'm bugging you folks for help.  :-^

>> Sneaker-netting the public and secret keyrings to my client's Windoze box
>> and importing there, with insecure memory, and no real random device.
>
>Lack of /dev/random shouldn't matter here, since they've already been
>generated. Or am I missing something again?

There was no real random device on the key I generated on the Windoze box
as part of the installation...  A key I'm not actually using, as I
currently understand it.

>However, you're now putting your security in the hands of Windows, and are
>assuming you won't be compromised by the latest IE or Netscape exploit.
>I'm assuming that this is a user's workstation?

I'm not seeing IE or Netscape really involved...  The script e-mails them
the encrypted data, and they run the secret decoder ring locally on their
Windoze box.  I can even train them to disconnect from the network before
running the decoder, if it matters...

>> Will be encrypting the data with insecure memory from a PHP web-script.
>
>However, if memory serves, PHP operates as a part of the web server
>(running code as the web server user, not via something like suexec). If
>this is the case, a compromise of the web server itself is a compromise
>for you.

PHP can be set up as a Module or as a cgi.  Currently, it's a cgi, since
I'm the only one using it, and the Micro$loth FrontPage Module all the
other virtual webmasters are using is incompatible.

My ISP set the web up to suExec to my shell login before executing cgis...
or, at least, that's how I understood what he e-mailed me when we set up
the account way back when...  The other option, as I recall, was to run as
'nobody' or as 'www' or whatever, and then my scripts/cgi directory would
be... exploitable... by all my fellow clients.

>Solution: Don't use PHP (or SSI, or anything of that nature) for
>security-critical code. Use an external script (preferably something
>compiled so that you can ensure proper memory cleanup before process
>termination) which runs as -your- userid, so that you minimize the
>potential for compromise (you still have a weak link in suexec, but that's
>hand-auditable code; I know, I've done it ;-).

If it helps, the PHP scripts and such will be running from a secure
server... or at least that's how I think it's going to end up.  My
understanding of secure servers is about on par with my understanding of
gpg.  :-(

>> Or not upgrading as often as I should.
>
>This is a problem; it sounds like you have a trust issue with the
>administrator. There's nothing here that can help you; your best bet is an
>NDA with the ISP, or some sort of legal restraint, because there isn't
>much of a technical means of protecting yourself here.

It's a "reasonable expectation of service level" issue, not a trust issue,
really.  I trust the ISP.  I even am reasonably certain that they know what
they are doing when it comes to security.  [The *seem* to know what they
are doing.]

I just can't expect them to compile gpg as often as it should be compiled
during alpha and beta phases, for what I'm paying them.  I already
negotiated my compiler access so I could stay on top of gpg updates, but it
looks like it was a marginal win, since I still need to bug them all too
frequently to chown/chmod the binary to use "secure memory" =?= "chown to
root and chmod to 4xxx".  If I'm even understanding this secure memory
thing right...

>What is the root of the technical requirement here for root ownership (and
>presumably suid permissions)? I must -really- be missing something here...

They unbent enough to give me compiler access.  *root* access as a client
of an ISP virtual host would be something I simply wouldn't even ask for.
They're already trusting me way more than expected by turning me loose with
a c compiler on a virtual host box.

>Solution: use ssh tunnels for transmission of the message off-site.

I'll have to research ssh tunnels... unless somebody can confirm or deny
their [potential] existence over AOL/modem to the client's Windoze 95
box...

>> The decrypting is all being done by a user on a windows box, who
>> understands infinitely less of this stuff than I do, if you can believe
>> that. :-)
>
>This isn't necessarily a problem, except for the potential of a compromise
>of their own system.
>
>Solution: proper care and feeding of your users. ;-) This means training,
>as well as configuration and upgrade assistance.

Well, it will be the blind leading the blind, but I reckon I'll do what I
can. :-)

>> Why do I get the feeling that there's a lot of folks out there that are
>> just taking credit card orders on a "secure" server, and then transmitting
>> them in clear-text via e-mail to their storefront POS credit-card
>> machines?...  There *have* to be people other than me who are
>> unable/unwilling to pay CyberCash rates...
>
>Not us; we did the CyberCash thing, and provide it to our customers. It's
>worked well, but you've still got a number of issues to work around, as
>well as ensure that your own security is up-to-snuff.
>
>Doing this via email would work well, but this kind of thing -only- works
>when there is a specific level of trust in the systems you're using, and
>their operators (both in terms of intent and skill), as well as a specific
>level of trust in the security of those systems.

The systems as they are seem reasonably secure, so far as I can tell from
what the ISP has told me.  And I trust them.  It's the things I'm trying to
do that worry me. :-)

I really appreciate all your help, everybody.

THANK YOU!!!

-- "TANSTAAFL" Rich lynch at cognitivearts.com      webmaster@  and www. all of:
R&B/jazz/blues/rock - jademaze.com         music industry org - chatmusic.com
acoustic/funk/world-beat - astrakelly.com      sculptures - olivierledoux.com
my own company - l-i-e.com               uncommon ground - uncommonground.com