Bug 438131 - (CVE-2008-1390) CVE-2008-1390 asterisk: HTTP Manager ID is predictable (AST-2008-005)
CVE-2008-1390 asterisk: HTTP Manager ID is predictable (AST-2008-005)
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 438132 438133 438134
  Show dependency treegraph
Reported: 2008-03-19 06:24 EDT by Tomas Hoger
Modified: 2008-03-31 05:44 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-31 05:44:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2008-03-19 06:24:39 EDT
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

"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."


This issue is *not* fixed in upstream
Comment 3 Fedora Update System 2008-03-19 11:45:37 EDT
asterisk- has been submitted as an update for Fedora 8
Comment 4 Fedora Update System 2008-03-19 23:50:35 EDT
asterisk- has been submitted as an update for Fedora 7
Comment 5 Fedora Update System 2008-03-21 18:02:52 EDT
asterisk- 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 18:14:17 EDT
asterisk- 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 05:44:13 EDT
This issue was addressed in:


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