Cisco wipes its memory from susceptible-to-Row Hammer list Cisco has worked through data centre and switch products that may have been vulnerable to the Row Hammer vulnerability, and decided there's nothing with the bridge brand on the front that's subject to the bug. Back at the beginning of the month, Google cheerily announced to the world that writing and re-writing memory in DRAMs …
Any RAM chip that is operated within the manufacturer's guidelines should be able to handle any pattern of address and/or data thrown at it. If it fails, it is faulty and should be returned for replacement or refund. Describing the process as 'hammering' unfairly shifts the perceived blame in the same manner as 'overclocking' or 'over/undervolting'. It comes down to a design error in the chip and if the entire line has to be withdrawn and the mask redesigned from scratch, so be it.
This post has been deleted by its author
"Any RAM chip that is operated within the manufacturer's guidelines should be able ..."
Yes, the memory is probably defective. But this kind of defective RAM is installed in many systems today, because the access pattern used by the rowhammer exploit is never found in real-world work loads, so they never tested for it.
http://googleprojectzero.blogspot.in/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
MemTest86 v6 includes a test for rowhammer (test 13), but prior to that, MemTest86 didn't detect the rowhammer fault either.
Please tell me they have enabled BIOS security because a lot of embedded systems can be reflashed using a bootable pendrive.
The problem is that *any* USB device is thus vulnerable, there are at least five exploits such as using the webcam memory (seen that) and network boot which is sometimes enabled as well as malicious code on a pressed DVD which flashes the memory in the optical drive from a library of compatible firmwares.
Also there has been a rash of "fake ECC" which is falsely indicating ECC works when in fact it does not along the same lines as overclocked memory and fakeflash (tm).
The memory chips on DDR/SDRAM/etc are not even locked so converting non ECC to ECC is so trivial that a sufficiently determined hacker could simply cross flash chips from identical manufacturers and speeds.
This post has been deleted by its author
Hmm, I got downvoted. Wonder why?
Also relevant, some MAC systems will work with non ECC DDRx but often have issues relating to timing as the multiplier and FSB are locked.
These really do need to be matched and I've heard horror stories about problems which manifested as kernel panics and even a total lockup on OSX.
Some laptops now also detect the RAM speed (cough HPDell /cough) and if it isn't up to scratch may not boot at all with 3 beeps or display a nasty unavoidable "this card is not recognized" message with non official replacement WiFi cards.
This post has been deleted by its author
"Cisco now says “this issue is not exploitable on devices that are equipped with ECC DRAM and have the ECC checking options enabled in their BIOS” – which is the default configuration. All Cisco UCS products have been cleared if they're using Cisco DIMMs, but if users have installed non-Cisco DIMMs, these could be vulnerable."
HMMMMMMMMMM..........
If ECC protects from this mechanism then how are non-Cisco DIMMs vulnerable?? Unless Cisco claims to be buying only DRAM which is not susceptible in which case the ECC protection for this issue should not be required.
This post has been deleted by its author
You miss the point. Fakes are obviously not OK, so eliminate those, and I'm not talking about real ECC DIMMs (Cisco or not) that are throwing single bit correctable errors.
What Cisco is saying is that a GOOD ECC DIMM that is CISCO brand is protected from rowhammer, but a GOOD ECC DIMM that is NON-CISCO is not protected from row-hammer.
Who seems to think that "RowHammer" is not actually an issue and the normal memory tests should pick up any failing chips long before this manifests.
To which I replied "This assumes companies actually TEST their memory in all cases such as low/high Vcc corresponding to typical 29% laptop battery usage and overheating with slight overclocking which could happen with a specific combination of FSB/multiplier and BIOS designed for gaming and/or using a system with an out of spec CPU which was never fully tested to save a few $$$"
No reply!! :-)
That said I did wonder if the low voltage problem is actually another variant, could a malware writer intentionally wait for just this eventuality as battery voltage isn't exactly hidden from the system and inject malware hoping to trigger a rowhammer-like effect during a brown out condition?
99times out of 100 it would just cause a crash but.. ?
Are you absolutely sure about that?
Like I mentioned earlier applications using very large amounts of data can and will fail with only very slightly flaky (under some combinations of low battery voltage/temperature/etc) memory, and I have personal experience to back this up including earlier Itunes database corruption issues.
Also relevant is that some laptops are well known for misbehaving when powering large USB drives, of which mine is evidently one.
Yet the exact same problem occurs on a lot of machines even new ones in a shop, tested it with a drive (USB3 2TB) and within an hour Windows 8 threw a hissy fit and required a repair.
This was on a very nice netbook which obviously I won't be buying now.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
