Tag Info

Hot answers tagged

363

You are touching a sore point... Historically, computers were mainframes where a lot of distinct users launched sessions and process on the same physical machine. Unix-like systems (e.g. Linux), but also VMS and its relatives (and this family includes all Windows of the NT line, hence 2000, XP, Vista, 7, 8...), have been structured in order to support the ...


34

I work in the consumer electronics arena and security here is somewhat different than in the server environment. Here we have to assume that the product is in a hostile environment. So for subscriber management purposes keys are kept secure. The first line of defence is that the SoC has hidden registers that even the operating system can't actually access, ...


29

Let's trace the flow of the confidential data. In this analysis, it is understood that anything Alice can do, root can also do. Also an external observer “one level up” (e.g. with physical access to snoop on the disk bus, or in the hypervisor if the code is running in the virtual machine) might be able to access the data. First, the data is loaded from a ...


26

Assuming buf's size is either controlled by n or larger than 16, the attacker could make n any number he wanted and use that to read an arbitrary amount of memory. memcpy and C in general do not throw exceptions or prevent this from happening. So long as you don't violate any sort of page protections or hit an invalid address, memcpy would continue ...


18

There is some work being done on the Linux platform to disallow accessing memory of a running process, even by a superuser. With SELinux, you can do it starting with Fedora 17: SELinux Deny Ptrace.


17

There is always something in memory. Each bit contains either a 0 or a 1 at all times. If the same space in memory is used for two different purposes, the computer (the compiler or the runtime system) can't tell: purposes are a human concept, not a machine concept. On most systems that you'd think of as computers nowadays (PCs, servers, mobile phones, ...


15

What language/platform are you using? If it's .NET, check out the PasswordBox control and the SecureString class. The SecureString class represents a way to store the password in memory without making it accessible to anyone - even hackers who sneak peeks at your application's memory. The PasswordBox control is a textbox that incorporates the ...


14

There is an element of truth to this one - an attack was discovered which took advantage of data remanence in RAM, allowing an attacker to grab data from the RAM in a machine. There was a very short timeframe (a matter of seconds or minutes) in which to do this, but it wasn't a hack of the PC as such. Simple Wikipedia link to Cold Boot Attack here And the ...


14

A good answer has already been given by sasha, but I want to look at this from another angle; specifically, what memcpy actually does (in terms of what code gets executed). Allowing for the possibility of minor bugs in this quick-and-dirty implementation, a trivial implementation of memcpy() that meets the C89/C99/POSIX function signature and contract might ...


12

Data in L1 cache will not remain in L1 cache only; the hardware will copy it to main RAM transparently and almost immediately. At least so operate modern CPU. If you want to keep sensitive data out of RAM, then you must keep it in registers only. Context switches will be a problem, also, since they automatically flush registers to a designated RAM space. ...


12

There are two things going on here: On x86 and x86-64 (and most other hardware), the stack grows from the top of memory downwards. Because of this, data used by a function (eg. the buffer you're overflowing) occurs at a lower address number than data used in calling the function (eg. the address to return to after the function is done, which you're trying ...


11

In a perfect world, you are right: there should be no point in keeping data encrypted in RAM. The OS should keep strong separation between processes, clear RAM when it is reallocated to another process, and, if the attack model allows for an attacker stealing the device afterwards and doing some harddisk analysis, encrypt the swap (or use no swap at all, ...


10

Having the RAM encryted helps against a live forensic analysis.


10

No, passwords stored in plaintext in RAM shouldn't be considered as safe. Generally, on the x86 and x86-64 architectures with interfaces such as FireWire, ExpressCard and Thunderbolt which directly access, these interfaces can be used to bypass operating system memory protection, and thus get plaintext passwords from memory. Using FireWire to gain ...


9

Keeping information in RAM can enhance security, if done right and if the requirements allow it. I'm going to show two security architectures where keeping the data in RAM provides a security benefit. These are fairly specific scenarios; most of the time keeping data in RAM doesn't help. Protection against file dump attacks Consider a web application that ...


9

ASLR is a hide-and-seek game: in case the attacker succeeds in overflowing a buffer and overwriting pointers, the OS loads the application code (the main executable and its DLL) in randomized locations, so as to make it harder for the attacker to actually hit a meaningful location. By construction, it works better when the playground is larger. The extended ...


8

One approach is to use highly non-redundant key schedules. For instances, if you can recover any large piece of AES's expanded key schedule in memory you can run the expansion in reverse and recover the original input (which then allows you to generate all of the round keys, even if you were only able to recover the values from a single round, or even ...


8

In a lot of programming languages, memory accesses are checked: by construction, regardless of how incompetent the programmer was and how deviant the data entered by an evil user may be, programs written in these languages cannot write data outside of their buffers, or overwrite pointers with integers or things like that. As real-life example, Java, ...


8

Buffer overflows occur because of a programming bug: due to circumstances unforeseen by the developer, but triggered by the attacker, the code is writing data beyond the end of the buffer. What end ? Well, there are two: toward high addresses, and toward low addresses. The traditional way to write a loop looks like this: for (i = 0; i < n; i ++) and ...


8

tl;dr: Virtual machine RAM is reasonably private, given your stated assumptions. I'm not an expert on virtual machine security (real experts, please come correct any errors in this post), but I found this question interesting enough to do some Googling. Here's what I found. From a NIST publication titled Security Recommendations for Hypervisor Deployment: ...


8

Crash Course in Computer Architecture In an Intel x86 and x64 architectures there is something called the stack. This is essentially where everything to determine the execution path is stored. Parameters to functions, local variables, and return addresses are all stored on the stack. CPU registers keep track of where in the stack the program is ...


7

To answer you question about why you'd want to encrypt RAM and the threats posed to it: Firstly RAM scrapers can read RAM memory for an attacker. Think about the sensitive data that used by computers: encryption keys, personal information, credit cards, and maybe even PIN numbers for Point of Sale devices. That data needs to be unencrypted to be used and if ...


7

The OpenBSD operating system includes automatic encryption of virtual memory; it is enabled by default since version 3.9. Without a CPU with embedded encryption hardware, the data in caches and physical RAM cannot be really encrypted, because the CPU could then not use it; but "virtual memory" as in "RAM blocks copied to and from the disk" is under the ...


7

Encrypting RAM is about preventing unauthorized access to the RAM contents. Under normal operating conditions, the Operating System maintains RAM access permissions and blocks applications from seeing memory from other applications; so we are talking about an attack context where the attacker plugs into the RAM "from the outside". It has been demonstrated ...


7

Modern operating systems work with virtual memory management so that by default it is not possible for user-space / user-mode processes to directly access other processes memory. But in Windows (don't know if this apply to Linux, too) there are interfaces that allow standard users to access the process memory of other processes running with the same ...


7

I don't think you're going to find a type of RAM that is secure against cold boot attacks. It may be possible to build application-layer defenses against this, by ensuring that all sensitive data stored in memory is stored in encrypted form. Then when you shut down, you simply need to securely overwrite the decryption key. However, this is likely to have ...


7

I think this question is asking a bit more about what happens when you encrypt data on a device where that data was previously unencrypted. SSD units and HDD units suffer from different possible compromises related this. This is basically referred to (at least on the venerable Wikipedia) as data remanence. That article offers lots of information about the ...



Only top voted, non community-wiki answers of a minimum length are eligible