New answers tagged

1

It may be dangerous. If your program manipulates confidential data that doesn't end up in the report, then the memory addresses may reveal information about the confidential data. Exploiting this data is likely to be difficult; the attacker would have to have a good working knowledge of what the program does, and they'd only obtain partial information, ...


2

First I want to address the DDR3 vs DDR4 issue. The differences between DDR3 and DDR4 are mostly voltage and clock speed. I've looked to see if there's any research on cold booting DDR4, and so far it looks like there's no academic papers out concerning their practicality. While commercial forensics labs may be performing cold boot attacks on DDR4 they're ...


0

First, what would you lose by hashing those values? I suspect the code isn't particularly performance critical and the speed impact would be relatively minor. If there isn't a big downside it is probably worth doing. As to what the security impact may be - many operating systems use address space layout randomisation (ASLR) to help mitigate against certain ...


2

Purely from a programming point of view, instead of using an objects memory address to link these two pieces of data, you really should be generating an index number and using that to refer between the structure and your annotation. I can't see any reason why it would be dangerous though to include the addresses in the report, since as soon as your program ...


0

I am pretty sure when assembly programmers first heard of high-level system programming languages like C they must have thought some classes of the bugs will never be seen again. What happened is we have exactly the same classes of bugs but under different disguises. Typical command/data confusion (which is behind most injection attacks) will occur no ...


0

You are overlooking the fact of the OSI Layers 8, 9 and 10 problem. Technology has been in place to prevent, minimize, and or disrupt most attacks for years. It does not matter how much more technology you create, theorize, adore, if the processes are broken. Most organizations that have been breached had more than sufficient technology to minimize access, ...


3

There is whole world of vulnerabilities out there which don't need buffer overflows or bad crypto. Just have a look at web applications where you have all these web based insecurities like Cross Site Scripting (XSS) or Cross Site Request Forgery (CSRF). Then take a look at code injections like SQL injection or Remote File Inclusion. If this is not enough ...


4

No, TRESOR was never integrated into the Linux kernel. It is specific to the x86 architecture, and requires AES-NI in order to not have a pretty nasty overhead. Due to the limited size of DR registers where the key is stored, it cannot store and precompute round keys (a common AES optimization), and thus must recompute them every single time. This isn't much ...


-2

In my opinion for the newer SSD is it better to do a full-zeroing on it with "zero" instead of "random" if you want to destroy al the data! BUT every single write to an SSD damages it slightly. Writing to every single erase block causes them all to be marked in use, which will prevent the drive's GC from functioning properly and performance will suffer. ...



Top 50 recent answers are included