in reply to Re: Is data in RAM insecure, or am I just paranoid?
in thread Is data in RAM insecure, or am I just paranoid?

Actually, I did say a bit about the network. Its a windows network, (windows 2003 server, I believe) with the exception of the database servers which are on Linux.

How is it vulnerable after the data is unencrypted? As I stated, the encrypted data is downloaded to a desktop application over SSL and THEN unencrypted via the private key on the desktop users system. (a location not where the servers are).

The data is fairly secure on the way from a users browser to the webserver (via SSL) and even if some program like Ettercap can capture encrypted data .. well, its encrypted.

My biggest worry is the unencrypted data, at the webserver, before I've run it through GNUPG (public/private key encryption at 2048 bits).

So ... how do I protect the pre-encrypted data in memory? or is there no way an ourside program can access data in RAM that perl is using?

  • Comment on Re^2: Is data in RAM insecure, or am I just paranoid?

Replies are listed 'Best First'.
Re^3: Is data in RAM insecure, or am I just paranoid?
by McMahon (Chaplain) on Jul 16, 2004 at 02:52 UTC
    Yes, you're correct: if the data stream is unencrypted on the client's machine, that's pretty secure, although you might want to investigate the encryption scheme, local firewalls, etc..

    So at the risk of oversimplifying: there's a WAN side and a LAN side. In most networks, the LAN side is highly controlled; that does not sound like the case in your situation. I suggest that you imagine that anyone on the LAN side is capable of running ettercap. I suggest that you run ettercap on the LAN side and see what shows up. You might be OK; you might not be OK.

    I think the data in RAM is pretty secure, again with caveats about firewalls, etc.
[reply]
      Update: Okay, my first stab at a reply was too 6-o'clock news sensational... here it goes again.

      Since this is a shared IIS server, I wouldn't consider data in RAM safe. At the very least, how do you ensure physical security of the server, console access, remote logon? Okay, this is a problem faced a lot though, and generally accepted practices prevail.

      Supposing ActiveState Perl is installed, there are 2 ways Perl CGI can be run: in-process and out-of-process. Perl for ISAPI handles CGI's in-process and perl.exe handles them out-of-process.

      Perl for ISAPI's perldoc says:

      The main advantage of PerlIS over perl.exe is that PerlIS runs as a DLL in the web server's process space. Because Win32 platforms set up a protected memory space for each process that is started, there's a lot of overhead in starting a new process or program. Passing scripts to an interpreter, such as perl.exe, requires starting a new process for every script, which gets expensive in terms of system resources.

      DLLs, on the other hand, don't need their own process space; they use the space of the process that calls them. They don't require nearly as much overhead to start, and once loaded they stay loaded until the calling process ends. PerlIS therefore runs Perl scripts with a quicker turn-around time than perl.exe.

      Draw your own conclusions (from extensive testing).

      There is also the possibility of a trojan perl.exe being installed on the server... how can you verify it? Or a trojan cgi script (if the ftp password is snagged--or file permissions are weak--or the shared admins are criminal). Yuk.

      I would be paranoid... but I usually am. YMMV.

      --Solo
      --
      You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
[reply]
        The first point from the ActiveState doc doesn't look right to me. The process space in which an ISAPI extension is run can be changed in the admin console. Typically (by default), an ISAPI DLL will be run by an external process called dllhost.exe. It is rare (and undesirable) to have an extension running in the IIS process space. The idea is that the executable host remains between calls (giving the advantage of not having to spawn a process) but an error in the ISAPI DLL won't crash the other IIS processes as it would if it were in process.

        None of this really matters from a security point of view anyway as any program can debug any one of the IIS executables (or any other executable) and examine it's memory space as long as it has adequate access. The ability to debug an application can however be removed from all users on the system by updating the user rights assignment in the Local Security Policy manager.

[reply]

In Section Seekers of Perl Wisdom