lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Nov 2013 10:47:47 -0800
From: coderman <coderman@...il.com>
To: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: OpenSSH Security Advisory: gcmrekey.adv

surprised not a peep about this one here yet,... hmmm
  a fun one ;)

we are accustomed to old software adding risk;
 new (secondary effects of combined AUTH+ENC modes)
   also carries risk!

---

OpenSSH Security Advisory: gcmrekey.adv

This document may be found at: http://www.openssh.com/txt/gcmrekey.adv

1. Vulnerability

        A memory corruption vulnerability exists in the post-
        authentication sshd process when an AES-GCM cipher
        (aes128-gcm@...nssh.com or aes256-gcm@...nssh.com) is
        selected during kex exchange.

        If exploited, this vulnerability might permit code execution
        with the privileges of the authenticated user and may
        therefore allow bypassing restricted shell/command
        configurations.

2. Affected configurations

        OpenSSH 6.2 and OpenSSH 6.3 when built against an OpenSSL
        that supports AES-GCM.

3. Mitigation

        Disable AES-GCM in the server configuration. The following
        sshd_config option will disable AES-GCM while leaving other
        ciphers active:

        Ciphers
aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

4. Details

        When using AES-GCM, sshd was not initialising a Message
        Authentication Code (MAC) context that is unused when the
        cipher mode offers authentication itself. This context
        contains some callback pointers, including a cleanup callback
        that was still being invoked during a rekeying operation.
        As such, the address being called was derived from previous
        heap contents.

This vulnerability is mitigated by the difficulty of
        pre-loading the heap with a useful callback address and by
        any platform address-space layout randomisation applied to
        sshd and the shared libraries it depends upon.

5. Credit

        This issue was identified by Markus Friedl (an OpenSSH
developer) on November 7th, 2013.

6. Fix

        OpenSSH 6.4 contains a fix for this vulnerability. Users who
        prefer to continue to use OpenSSH 6.2 or 6.3 may apply this
        patch:

Index: monitor_wrap.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/monitor_wrap.c,v
retrieving revision 1.76
diff -u -p -u -r1.76 monitor_wrap.c
--- monitor_wrap.c 17 May 2013 00:13:13 -0000 1.76
+++ monitor_wrap.c 6 Nov 2013 16:31:26 -0000
@@ -469,7 +469,7 @@ mm_newkeys_from_blob(u_char *blob, int b
  buffer_init(&b);
  buffer_append(&b, blob, blen);

- newkey = xmalloc(sizeof(*newkey));
+ newkey = xcalloc(1, sizeof(*newkey));
  enc = &newkey->enc;
  mac = &newkey->mac;
  comp = &newkey->comp;

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ