Bug 438131 (CVE-2008-1390) - CVE-2008-1390 asterisk: HTTP Manager ID is predictable (AST-2008-005)
Summary: CVE-2008-1390 asterisk: HTTP Manager ID is predictable (AST-2008-005)
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2008-1390
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: http://nvd.nist.gov/nvd.cfm?cvename=C...
Whiteboard:
Depends On: 438132 438133 438134
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-19 10:24 UTC by Tomas Hoger
Modified: 2008-03-31 09:44 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-03-31 09:44:13 UTC


Attachments (Terms of Use)

Description Tomas Hoger 2008-03-19 10:24:39 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2008-1390 to the following vulnerability:

Asterisk Project Security Advisory - AST-2008-005

Due to the way that manager IDs are calculated, this 32-bit integer is likely
to have a much larger than average number of 1s, which greatly reduces the
number of guesses an attacker would have to make to successfully predict the
manager ID, which is used across multiple HTTP queries to hold manager state.

"The issue is the generation of session ids in the AsteriskGUI HTTP server.
When using Glibc, the implementation and state of rand() and random() is
shared. Asterisk uses random() to issue MD5 digest authentication
challenges and rand() bitwise-ORed with a malloc'd pointer to generate
AsteriskGUI session identifiers. An attacker can synchronize with
random() by retrieving 32 successive challenges and predict all subsequent
output of calls to random() and rand(). Because a pointer returned by
malloc has at best 21 bits of entropy, the attacker will on average only
need to guess 1448 session identifiers in order to steal an established
session.

"The crux of the problem is that under Glibc, the implementation of rand()
and random() is shared. rand() is just an alias to random(). This means
that they all come from the same randomizer with the same state.

"A remote attacker can synchronize with all subsequent output of a remote
system's random() state by just observing or retrieving 32 successive
outputs. They can easily do this by generating 32 MD5 digest
authentication challenges. At this point, they will be able to predict
all subsequent output of random() and rand().

"The memory address returned by calloc() is also not sufficiently random.
In practice, it will be in low memory, immediately following the executable.
In addition, the buffer returned will be 8-byte aligned. This means that
the high order 8 bits and low order 3 bits will always be zero. Finally,
this value is bitwise ORed with the output of random(), so any bits that
are set will be preserved.

"An attacker will only have to guess 2^N session ids, where N is the number
of zeros in the number return by random() between bit positions 3 and 24.
On average, this will be 1448 guesses.

"However, an attacker can do better than this by consuming challenges until
the following number output by random() has many 1's in those significant
bit positions."

References:
http://downloads.digium.com/pub/security/AST-2008-005.html

Note:
This issue is *not* fixed in upstream 1.4.18.1.

Comment 3 Fedora Update System 2008-03-19 15:45:37 UTC
asterisk-1.4.18.1-1.fc8 has been submitted as an update for Fedora 8

Comment 4 Fedora Update System 2008-03-20 03:50:35 UTC
asterisk-1.4.18.1-1.fc7 has been submitted as an update for Fedora 7

Comment 5 Fedora Update System 2008-03-21 22:02:52 UTC
asterisk-1.4.18.1-1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Fedora Update System 2008-03-21 22:14:17 UTC
asterisk-1.4.18.1-1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Red Hat Product Security 2008-03-31 09:44:13 UTC
This issue was addressed in:

Fedora:
  https://admin.fedoraproject.org/updates/F7/FEDORA-2008-2620
  https://admin.fedoraproject.org/updates/F8/FEDORA-2008-2554




Note You need to log in before you can comment on or make changes to this bug.