ISC Bind 8 Transaction Signatures Buffer Overflow Vulnerability
A colleague clued me 1-28-01 triggering my upgrade to
VERSION.BIND."8.2.3-REL" on 1/29/01
NOT VULNERABLE ISC BIND 9.1
ISC BIND 9.0
ISC BIND 8.2.3
ALL PREVIOUS Releases of BIND 4 & 8 are VULNERABLE.
Overview:
DNS software flaw poses extreme risk
By David McGuire
January 31, 2001
A recently discovered security flaw embedded in the most popular breed of
Internet server software could expose more than 80 percent of the world's
Web sites to debilitating hacker attacks if network administrators don¹t
move quickly to replace the flawed versions, a electronic security expert
said Monday.
"There are a number of potential (vulnerabilities)," CERT Coordination
Center electronic vulnerability expert Shawn Hernan said Monday. "The worst
case scenario is the distribution of malicious software from a popular
site."
In a statement earlier today, CERT outlined the security flaws inherent in
the two most commonly used versions of the Berkeley Internet Name Domain or
"BIND" software, which is used to run most of the world's Internet name
servers.
The flaw exists in BIND 4 and BIND 8, which combined are used by more than
80 percent of name servers worldwide, Hernan said, adding that his estimate
is "conservative."
Originally identified as an exploitable threat by Network Associates' COVERT
Labs more than a month ago, the flaw was kept largely under wraps until the
Internet Software Consortium, which distributes BIND, could make a fix
widely available, Hernan said. That fix can be downloaded from
http://www.isc.org .
While the security hole is "somewhat subtle and requires somewhat of a
moderate degree of skill to exploit, there are a lot of (skilled) intruders
out there" eager to be the first to write software designed to exploit the
flaw, Hernan said.
Once that "exploit" software is written scores of less talented hackers will
be able to crack untreated name servers, Hernan said.
Upon gaining control of a Web site's name servers, a hacker can control
outright the direction of any traffic to that site, Hernan said.
In its mildest form, a hack using the BIND security flaw could result in a
Web site being effectively cut off from the rest of the Internet, Hernan
said.
A more malicious attacker could reroute e-mail, or direct visitors of a Web
site to another site with the intention of disseminating false information,
or worse, spreading viruses, Hernan predicted.
For that reason, CERT is urging "anyone who relies on the Internet" to check
with their Web masters or server operators to make sure they are aware of
the problem and are taking steps to remedy it, Hernan said.
Even home users should contact their Internet services providers to make
them aware of the problem, Hernan said.
Details of the security hole can be found on CERT's Web site at
http://www.cert.org/advisories/CA-2001-02.html
Detail:
BIND is a server program that implements the domain name service (DNS)
protocol. It is in extremely wide use on the Internet. Versions 8.2 and
above of BIND contain a buffer overflow that may be exploitable by remote
attackers.
When BIND recieves a query, it reads it into a buffer and then processes it.
If the request came in via the UDP transport the query is read by the
'datagram_read()' function into the 'u.buf' buffer. This buffer is on the
stack and is 512 bytes in length, the maximum amount of information that can
be sent in a single UDP datagram. If the request came in via the TCP
transport the query is read by the 'stream_getlen()' function into the
'sp->s_buf'. This buffer is allocated via the 'malloc()' function on the
heap and is 64KB in length.
When sending responses, BIND re-uses this buffer for creating the response.
As BIND processes the request, it appends data to the DNS response. When
it's finished it modifies the DNS header and sends the response.
The length of the DNS message as well as the number of bytes that can be
written are kept track of using two variables. 'msglen' is used to keep
track of the amount of data in the buffer. 'buflen' is used to keep track of
the amount of remaining free space in the buffer.
Starting with BIND 8.2 when a transaction signature is included in the
query, BIND skips normal processing of the request and attempts to verify
the signature via the 'ns_find_tsig()' function. If the signature is
invalid, a TSIG response is appended to the buffer while BIND assumes that
'msglen' plus 'buflen' equal the size of the buffer.
As normal processing has been skipped 'msglen' plus 'buflen' are in fact
almost twice the length of the buffer. Thus the TSIG record is written via
ns_sign() beyond the boundaries of the buffer. This can result in the TSIG
response being written partially over the executing function's stack frame
or in overwriting malloc's internal variables.
The TSIG response consists of fixed values, including zero-value bytes. In
the case of a request received via UDP were the buffer is on the stack the
attacker may gain control over some portions of the stack frame of the
calling function in the 'datagram_read()' function. In the Intel IA32
architecture it may be possible to overwrite the least significant byte of
the of the saved frame pointer with a zero. This would result on most
instances on the saved frame pointer pointing into the area of memory with
the original DNS request which is under the control of the attacker. An
arbitrary address supplied by the attacker inserted within this region of
memory can be referenced as a return address when the calling function
returns. If this address points to shellcode, it will be executed with
privileges of named.
Predicting the result of the one byte overflow of the frame pointer can be
made easier by using the BID 2321 vulnerability to retrieve the stack
activation record of the 'datagram_read()' function. This information can be
used to exactly calculate were the frame pointer will point to once it's
least significant byte is overwritten with a zero value.
In the case of a request received via TCP were the buffer is in the 'bss' or
'heap' region of process memory, while this is a buffer overflow, it cannot
be exploited in the same way a stack overflow can be. In addition, this part
of memory is not executable, therefore any shellcode must somehow be put in
the stack.
One way to exploit the vulnerability in this case is through corruption of
malloc() structures. If an attacker can overwrite the beginning of a
malloc()'ed block of memory and have it remain intact until free() is called
on it, arbitrary locations in memory can be overwritten with attacker
supplied-values.
An attacker may, for example, overwrite a return address on the stack with a
value pointing to shellcode somewhere in executable memory. When the
function returns, the supplied shellcode will be executed with privileges of
named (typically root).
This attack against the malloc() structures only work againsts
implementations of this function that maintain the linkage structures in the
same memory area used to allocate memory. Implementation known vulnerable to
this type of attack include the ones in the IRIX libc library, the Linux
glibc library, and the Solaris libc library.
E. Lee Ingalls III
Commercial Tool & Die Inc.
(p)616.785.8100 (f)616.785.8120
eli3@...
Fortitudine Vincimus: “by Endurance we conquer.”
A colleague clued me 1-28-01 triggering my upgrade to
VERSION.BIND."8.2.3-REL" on 1/29/01
NOT VULNERABLE ISC BIND 9.1
ISC BIND 9.0
ISC BIND 8.2.3
ALL PREVIOUS Releases of BIND 4 & 8 are VULNERABLE.
Overview:
DNS software flaw poses extreme risk
By David McGuire
January 31, 2001
A recently discovered security flaw embedded in the most popular breed of
Internet server software could expose more than 80 percent of the world's
Web sites to debilitating hacker attacks if network administrators don¹t
move quickly to replace the flawed versions, a electronic security expert
said Monday.
"There are a number of potential (vulnerabilities)," CERT Coordination
Center electronic vulnerability expert Shawn Hernan said Monday. "The worst
case scenario is the distribution of malicious software from a popular
site."
In a statement earlier today, CERT outlined the security flaws inherent in
the two most commonly used versions of the Berkeley Internet Name Domain or
"BIND" software, which is used to run most of the world's Internet name
servers.
The flaw exists in BIND 4 and BIND 8, which combined are used by more than
80 percent of name servers worldwide, Hernan said, adding that his estimate
is "conservative."
Originally identified as an exploitable threat by Network Associates' COVERT
Labs more than a month ago, the flaw was kept largely under wraps until the
Internet Software Consortium, which distributes BIND, could make a fix
widely available, Hernan said. That fix can be downloaded from
http://www.isc.org .
While the security hole is "somewhat subtle and requires somewhat of a
moderate degree of skill to exploit, there are a lot of (skilled) intruders
out there" eager to be the first to write software designed to exploit the
flaw, Hernan said.
Once that "exploit" software is written scores of less talented hackers will
be able to crack untreated name servers, Hernan said.
Upon gaining control of a Web site's name servers, a hacker can control
outright the direction of any traffic to that site, Hernan said.
In its mildest form, a hack using the BIND security flaw could result in a
Web site being effectively cut off from the rest of the Internet, Hernan
said.
A more malicious attacker could reroute e-mail, or direct visitors of a Web
site to another site with the intention of disseminating false information,
or worse, spreading viruses, Hernan predicted.
For that reason, CERT is urging "anyone who relies on the Internet" to check
with their Web masters or server operators to make sure they are aware of
the problem and are taking steps to remedy it, Hernan said.
Even home users should contact their Internet services providers to make
them aware of the problem, Hernan said.
Details of the security hole can be found on CERT's Web site at
http://www.cert.org/advisories/CA-2001-02.html
Detail:
BIND is a server program that implements the domain name service (DNS)
protocol. It is in extremely wide use on the Internet. Versions 8.2 and
above of BIND contain a buffer overflow that may be exploitable by remote
attackers.
When BIND recieves a query, it reads it into a buffer and then processes it.
If the request came in via the UDP transport the query is read by the
'datagram_read()' function into the 'u.buf' buffer. This buffer is on the
stack and is 512 bytes in length, the maximum amount of information that can
be sent in a single UDP datagram. If the request came in via the TCP
transport the query is read by the 'stream_getlen()' function into the
'sp->s_buf'. This buffer is allocated via the 'malloc()' function on the
heap and is 64KB in length.
When sending responses, BIND re-uses this buffer for creating the response.
As BIND processes the request, it appends data to the DNS response. When
it's finished it modifies the DNS header and sends the response.
The length of the DNS message as well as the number of bytes that can be
written are kept track of using two variables. 'msglen' is used to keep
track of the amount of data in the buffer. 'buflen' is used to keep track of
the amount of remaining free space in the buffer.
Starting with BIND 8.2 when a transaction signature is included in the
query, BIND skips normal processing of the request and attempts to verify
the signature via the 'ns_find_tsig()' function. If the signature is
invalid, a TSIG response is appended to the buffer while BIND assumes that
'msglen' plus 'buflen' equal the size of the buffer.
As normal processing has been skipped 'msglen' plus 'buflen' are in fact
almost twice the length of the buffer. Thus the TSIG record is written via
ns_sign() beyond the boundaries of the buffer. This can result in the TSIG
response being written partially over the executing function's stack frame
or in overwriting malloc's internal variables.
The TSIG response consists of fixed values, including zero-value bytes. In
the case of a request received via UDP were the buffer is on the stack the
attacker may gain control over some portions of the stack frame of the
calling function in the 'datagram_read()' function. In the Intel IA32
architecture it may be possible to overwrite the least significant byte of
the of the saved frame pointer with a zero. This would result on most
instances on the saved frame pointer pointing into the area of memory with
the original DNS request which is under the control of the attacker. An
arbitrary address supplied by the attacker inserted within this region of
memory can be referenced as a return address when the calling function
returns. If this address points to shellcode, it will be executed with
privileges of named.
Predicting the result of the one byte overflow of the frame pointer can be
made easier by using the BID 2321 vulnerability to retrieve the stack
activation record of the 'datagram_read()' function. This information can be
used to exactly calculate were the frame pointer will point to once it's
least significant byte is overwritten with a zero value.
In the case of a request received via TCP were the buffer is in the 'bss' or
'heap' region of process memory, while this is a buffer overflow, it cannot
be exploited in the same way a stack overflow can be. In addition, this part
of memory is not executable, therefore any shellcode must somehow be put in
the stack.
One way to exploit the vulnerability in this case is through corruption of
malloc() structures. If an attacker can overwrite the beginning of a
malloc()'ed block of memory and have it remain intact until free() is called
on it, arbitrary locations in memory can be overwritten with attacker
supplied-values.
An attacker may, for example, overwrite a return address on the stack with a
value pointing to shellcode somewhere in executable memory. When the
function returns, the supplied shellcode will be executed with privileges of
named (typically root).
This attack against the malloc() structures only work againsts
implementations of this function that maintain the linkage structures in the
same memory area used to allocate memory. Implementation known vulnerable to
this type of attack include the ones in the IRIX libc library, the Linux
glibc library, and the Solaris libc library.
E. Lee Ingalls III
Commercial Tool & Die Inc.
(p)616.785.8100 (f)616.785.8120
eli3@...
Fortitudine Vincimus: “by Endurance we conquer.”