Hot answers tagged

463

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 ...


101

Memory isolation Your example wouldn't work on Windows 95, but it did work on DOS and Windows up to 3.11 (not Windows NT). The PC architecture, and the Microsoft series of operating systems, started with the Intel 8086 processor and an operating system (DOS) designed to run a single program at a time. You would run a program, and when you were finished ...


76

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 ...


71

This 2013 article analyses retention time for several DRAM chips. Among the relevant information, one may list the following: Retention time depends on a lot of things, including the values of neighbouring bits. A DRAM bit is a potential well, and it loses its contents by moving charges from or into neighbouring areas, so whether there is room in these ...


47

Sometimes applications use untrusted data as the key in a hash map. A simple implementation can allow the untrusted data to cause a denial of service attack. Hash maps are fast - O(1) - in the best case, but slow - O(n) - in the worst case. This is because keys are normally in separate buckets, but some values can result in the same hash - a collision - ...


39

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, ...


35

Insert, search, and remove operations on hash tables have O(n) worst case behavior. If an attacker can choose keys to be inserted into a hash table and they can compute the hash function themselves then that creates an opportunity for denial of service. All they need to do is choose keys that map to the same bucket. The quote suggests that the use of a ...


32

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 ...


32

Yes, it does mean that the key will be stored in the application’s memory. Yes, there is a risk that malware (with sufficient privilege) can read it from there. This risk is hard to avoid — if you want to use the key, you need to put it in memory, just as you need to put your house key in your pocket after you lock the door. This is usually not considered a ...


28

Dumps give too much info for hackers to reverse engineer or hack the software, say to enable features or licenses? The dumps must, at some point, exist in unencrypted form. An attacker with full local control can either grab the dumps at that instant - or simply ignore them, and look at the memory of the running application at will. Some programs, such as ...


27

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, ...


26

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.


25

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 ...


21

There are mechanisms that could result in data remanence in DRAM beyond the charge stored in the gates (which is typically gone in seconds, especially at normal elevated operating temperature). One is movement of ionic contaminants which can cause slight shifts in thresholds. This could be the 'burn in' that Tom's answer refers to. There may not be any ...


19

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, ...


18

I agree that's a little vague and it's going to heavily depend on how the hashmaps are used. Here's my guess: say you're taking some input from users, say [Firstname.Lastname] and using that as the lookup value in your hash table. Let's say you're building your hash table using the simple hash function that takes initials so that [Firstname.Lastname] --> ...


17

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 ...


16

To understand what DEP does, you first need to know a little bit about how memory is laid out in a process. The key concept is that code (instructions the CPU can execute) and data (stacks and objects) exist in separate areas of memory. User input, files, program data, etc. all live in the data areas of memory. DEP allows this separation to be enforced by ...


16

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 executing....


15

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 ...


15

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 ...


15

During the POST, the BIOS traditionally performs a "memory test" which entails writing to and rereading the whole of the physical RAM. However, this process can take a non-negligible amount of time, and is rather bad at detecting bad memory (it reliably detects only very bad memory) so it is disabled in many cases (by the computer vendor, or the user). Thus, ...


14

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 ...


14

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 ...


14

KASLR and SMEP are kernel-mode protections, applying ASLR to kernel space and enforcing privilege ring boundaries on execution respectively. EMET is solely a user-space protection tool, and as such is not involved with KASLR or SMEP. You should also be aware that EMET is not a magic bullet. It is designed with two goals: to raise the cost of exploit ...


14

Actually, almost all of the CPU on the market, save for the very small ones meant for low-power embedded devices, offer "hardware-enforced isolation". This is called a MMU. Synthetically, the MMU splits the address space into individual pages (typically 4 or 8 kB each; it depends on the CPU architecture and version), and whenever some piece of code accesses ...


13

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. ...


13

So I have to admit that my first reaction was "I would never do this." That, however, may be more because I, historically, don't like to let anybody know anything they don't need to, than for any real security reason. So that said, the only security issues I can think of are fairly limited, and fairly esoteric. It could be used to find a DoS or DDoS ...


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