Re: DRAM Rowhammer exploits
On 03/09/15 22:37, Bakul Shah wrote: > On Mon, 09 Mar 2015 20:46:19 - "Poul-Henning Kamp" > wrote: >> In message >> <20150309202308.64dfbb...@mail.bitblocks.com>, Bakul Shah >> writes: >>> On Mon, 09 Mar 2015 19:52:04 - "Poul-Henning Kamp" >>> >> wrote: >> >>> Hopefully ECC memory protects against such exploits (at least >>> makes them a lot less vulnerable). >> >> ECC only makes it harder, it doesn't make it impossible. > > According to the small sample in the paper below, the incidence of > 3 bit errors is about 4000 times or more lower than single bit > errors. These are the errors that may not even get detected by > ECC. So not impossible but much better. > > http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_isca14.pdf > > It also proposes a few solutions. It seems to indicate that > reducing refresh time by a factor of 7 (over 64ms) removes such > errors. Hopefully this can be done via a firmware upgrade? > > I don't know if the physical page pool for kernel data can be > isolated enough from user data to avoid this. [Probably not. Likely > there is no standard way to do map a phys addr to a specific > chip/row and diff. mfrs may use diff geometries. Though, perhaps > this same phenomenon can be used to infer chip geometry!] > > Also see: > http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_kim_talk_isca14.pdf > > ___ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security To > unsubscribe, send any mail to > "freebsd-security-unsubscr...@freebsd.org" > A stupid way is to make hash over physical address space. But how much time will it cost to make it, check and write a new value? And when should it control the memory? After each read? Then only small blocks can be controlled. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: DRAM Rowhammer exploits
I have a suggestion. As a simpler measure, would it be possible to implement a test at boot time to determine whether the system is vulnerable? I guess such a test would have to run in the kernel to get the particular memory mapping required. The result would naturally emit a kernel message, but it would be much easier to monitor for automatically if it also set a read-only sysctl. For sure at my company, I would add an alert for such a test on our most accessible systems. I could easily replace any affected hardware on our DMZ and edge networks if I can identify it easily. For that matter, some hardware may not need replacing if I diddle with the over-clocker's BIOS settings. Ongoing monitoring matters because I'd hate to have someone swap hardware or reset the BIOS in an emergency and not know they opened the vulnerability. If the hardware can be worked around, that's very helpful, but the proposals sound like they'd have fairly severe performance impacts and/or be impossible to guarantee for all hardware. On many of our systems, multi-user security is just not an issue, and for them I would choose performance over fixing this problem or replacing the hardware. Indeed, I would keep the hardware removed from sensitive systems to reuse in more protected environments. In any case, I would think that having a reliable test would be very helpful to most of this audience. Without it, I'm fumbling in the dark. Does anyone empathize with this? - Leif ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: DRAM Rowhammer exploits
On Mon, Mar 9, 2015 at 8:49 PM, Dmitry Morozovsky wrote: > Dear colleagues, > > any thoughts we're vulnerable to this? In memtest86 exists a rowhammer test - http://www.passmark.com/forum/showthread.php?4836-MemTest86-v6-0-Beta-%282015-02-13-Update-Beta-testing-is-now-closed%29 . > > http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: ma...@freebsd.org ] > > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** > > ___ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
sendmail broken by libssl in current
[sorry for reposting but the original copy I got back had been truncated]
libssl has a new "feature"
implemented by:
crypto/openssl/ssl/t1_lib.c
672 /* Add padding to workaround bugs in F5 terminators.
673 * See
https://tools.ietf.org/html/draft-agl-tls-padding-03
674 *
675 * NB: because this code works out the length of all
existing
676 * extensions it MUST always appear last.
677 */
678 //if (s->options & SSL_OP_TLSEXT_PADDING)
unfortunatly this makes sendmail incompatible with various email
servers around the world,
including (apparently (ironically (*))) Ironport email gateways.
It fails in TLS handshake.
These are commonly installed at companies and government departments.
consequently if you are mailing an important documant to your bank, or
maybe some tax information to
your friendly tax department, youe emails sit in your queue for a week
until they time out and get dropped.
(you may r may not get notified depending on your spam filters)
I had to make the following "fix" to libssl to get sendmail to be able
to get my tax forms out.
Index: crypto/openssl/ssl/t1_lib.c
===
--- crypto/openssl/ssl/t1_lib.c(revision 279747)
+++ crypto/openssl/ssl/t1_lib.c(working copy)
@@ -675,7 +675,8 @@
* NB: because this code works out the length of all existing
* extensions it MUST always appear last.
*/
-if (s->options & SSL_OP_TLSEXT_PADDING)
+//if (s->options & SSL_OP_TLSEXT_PADDING)
+if (0)
{
int hlen = ret - (unsigned char *)s->init_buf->data;
/* The code in s23_clnt.c to build ClientHello messages
I saw some hints that there is a change in send mail somewhere that gets
around this but haven't been able to find the exact configuration
change required
to make it happen.
Julian
(*) Ironically because :
1/ Ironport runs on FreeBSD
2/ I used to work there.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
