Immune Systems:
* Wireshark version 0.99.6 and newer
A vulnerability in the way Wireshark handles DNP3 data allows an attacker
to fool the dissector into thinking a negative value of items has been
provided to it as part of the Application Layer's request to read/write
objects. This in turn causes the loop found in the code:
for (temp16 = 0; temp16 < num_items; temp16++)
{
Signedness error in ccid_serial.c in libccid in the USB Chip/Smart Card
Interface Devices (CCID) driver, as used in pcscd in PCSC-Lite 1.5.3
and possibly other products, allows physically proximate attackers to
execute arbitrary code via a smart card with a crafted serial number
that causes a negative value to be used in a memcpy operation, which
triggers a buffer overflow. NOTE: some sources refer to this issue
as an integer overflow (CVE-2010-4530).
The updated packages have been patched to correct this issue.
_______________________________________________________________________
It is possible to cause Apache HTTP server to return client-supplied scripting code by submitting a malformed HTTP method which would actually carry the payload (i.e.: malicious JavaScript) and invalid length data in the form of either of the following:
Two 'Content-length:' headers equals to zero. i.e.: "Content-Length: 0[LF]Content-Length: 0"
One 'Content-length:' header equals to two values. i.e.: "Content-length: 0, 0"
One 'Content-length:' header equals to a negative value. i.e.: "Content-length: -1"
One 'Content-length:' header equals to a large value. i.e.: "Content-length: 9999999999999999999999999999999999999999999999"
Apache 2.X returns a '413 Request Entity Too Large' error, when submitting invalid length data. When probing for XSS on the error page returned by the server we have 3 possible string vectors:
The code above checks for an error condition based on the value of an
Error Code field in the inbound network packet. An error condition is
explicitly handled if the Error Code value is less than or equal to -1,
in which case a MessageBox with a corresponding descriptive error string
will be presented to the user. However, by crafting a packet with any
negative value in the Error Code field different from -1 the lookup for
the corresponding error string will fail triggering a non-recoverable
error and thus terminating the server process.
The following python code can be used to reproduce the bug:
0x7e (pretty unusual but possible indeed)
After the first iterate within the for(){...} , CurrentLocation will be
0x80 which is a negative value so Irp->CurrentLocation <= (CHAR)
(Irp->StackCount+1) becomes TRUE.Hence, remaining iterations will be
running out of allocated memory, traversing arbitrary and invalid stack
locations.
Thank you for pointing out the misleading text. The vulnerability is a
signedness error which leads to information disclosure. We have updated
the advisory to read as follows.
===
negative value can cause large amounts of kernel memory contents to be
disclosed.
===
VeriSign iDefense Labs
Integer signedness error in the elf_get_dynamic_info function
in elf/dynamic-link.h in ld.so in the GNU C Library (aka glibc or
libc6) 2.0.1 through 2.11.1, when the --verify option is used, allows
user-assisted remote attackers to execute arbitrary code via a crafted
ELF program with a negative value for a certain d_tag structure member
in the ELF header (CVE-2010-0830).
Packages for 2008.0 and 2009.0 are provided as of the Extended
Maintenance Program. Please visit this link to learn more:
http://store.mandriva.com/product_info.php?cPath=149&products_id=490
"""
# V2
# more complex version working too, it have more space for the shellcode
hax="$MyINFO $ALL joseph AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
hax+="\xFF\xFF\xFF\xFE" # local var int len of commands.c:my_info() must be a negative value
hax+="TTTTUUUUVVVVWWWWXXXXYYYYZZZZBBBBCCCCEEEEEEE$"
hax+="\x20\x81\x81\x80" # esp
hax+="\x80\xf7\xfe\xbf" # eip
hax+="\xCC\xCC\xCC\xCC" # useless var
hax+="\x10\xf0\xfe\xbf" # this address + x20 will be overwritten by 4 bytes
