RE: Re[2]: Protecting code and data in Windows

From: Wiest, Damian (dmwiest_at_rc2corp.com)
Date: 10/02/03

  • Next message: Eric Landuyt: "Re[4]: Protecting code and data in Windows" 
    To: "'secprog@securityfocus.com'" <secprog@securityfocus.com>
Date: Thu, 2 Oct 2003 15:21:15 -0500

    Not to troll, but why focus your efforts on attempting to protect a box
    that's already been owned? If they've got admin/root on the machine, then
    there's not a whole lot you can do.

    If you're using a shared secret scheme then you're going to need to trust
    whomever you're giving the secret. You've stated that you don't trust the
    machines you're sharing the secrets with, so I'm not sure how this is going
    to work.

    If you're concerned about the machine with the secrets being hacked into,
    why not try something like running a serial connection between the
    application server and another system with the crypto keys? The application
    server would then request encryption/decryption from the other system, which
    would not be accessible to intruders (assuming they don't have physical
    access).

    -Damian

    > -----Original Message-----
    > From: Muzaffar Mahkamov [mailto:admin@flshlnk.com]
    > Sent: Thursday, October 02, 2003 7:40 AM
    > To: Michael Howard
    > Cc: secprog@securityfocus.com
    > Subject: Re[2]: Protecting code and data in Windows
    >
    >
    > First of all, thank you all for provided references.
    >
    > I've scanned through the "Writing Secure Code" book, especially the
    > Chapter 7 - "Storing secrets". The information there is useful but not
    > exactly what i need.
    >
    > Let's assume that i'm a user and running the proccess. The attacker
    > himself has no direct access to my computer and can only attack using
    > some software, e.g. trojan. So we presume that the attacker here is a
    > software. The user's process have some data encrypted
    > with some key in the memory at run-time. Both the data and the
    > encrypting key (hashed, salted, whatever) reside in memory.
    > So while the
    > attacker cannot read the data itself directly he can access
    > the encypting
    > key and safely decrypt the important data.
    >
    > What i want to know is how to safely store the encrypting password in
    > the memory so no other process, even with the same or higher
    > privilege, may
    > access it. The data must be safe even in untrusted environment. E.g.
    > i'm accessing my remote computer from the untrusted computer where
    > some malicious code may access my password.
    >
    > For now i can outline 2 attack methods i see:
    >
    > 1. An attacker (in this case a trojan) can hook a debugger (int 7) and
    > transparently run your code accessing all the process data at the same
    > time. So i'll need anti debugging techniques to be implemented, right?
    > Does Windows has some feature that doesn't allow any software with any
    > privilege hook the debugger without the user's confirmation?
    >
    > 2. An attacker may force the operating system to run out the memory
    > (continously allocating memory for use) so the memory where
    > encrypting key
    > resides get paged. I've read somewhere that in Windows 9x
    > non-paged memory
    > was implemented using VxD's. But is it possible to lock the memory
    > using the Windows native API so my code will be portable?
    >
    >
    > Thanks,
    > Muzaffar Mahkamov

  • Next message: Eric Landuyt: "Re[4]: Protecting code and data in Windows"

    Relevant Pages

    • Re: "incrementing" ecb mode
      ... But an attacker might still be able to gain some information ... Is the starting key secret or not? ... > in the middle of a file, and this would be easier than a proper MAC, no need ... that are stored in the SFS before encrypting them. ...
      (sci.crypt)
    • Re: Encrypting passwords stored in memory
      ... memory using a key that is available to the running program (whether hidden ... Suppose the attacker can obtain the encrypting key. ... cyphertext (encrypted secret) in order to decrypt. ...
      (sci.crypt)
    • Re: Firewall vs. IPS - Differences now (ISS, Intrushield 2.1?)
      ... > You risk running out of memory. ... That's like saying "it's trivial to DoS Aho-Corasic if you know the ... DoS's and improvements via use of the Jenkins hash are most illuminating. ... > replacement policy gives the worst behavior since an attacker can flood ...
      (Focus-IDS)
    • Re: Ada.Command_Line and wildcards
      ... expect to read in their entire input into memory at once before ... DoS to the attacker. ... It uses a fixed size buffer to read commands from the ...
      (comp.lang.ada)
    • Re: Database Security - Where to store?
      ... of Michael Howard and David LeBlanc's Writing Secure Code book is dedicated ... the LSA secret mechanism of NT 4. ... will also be in memory at some point, and can suffer from the same attack. ... decrypted data as soon as you no longer need them. ...
      (microsoft.public.dotnet.security)
    • Quantcast