Re: Clarifying integer overflows vs. signedness errors

["Thiago Zaninotti" <thiago@xxxxxxxxxxxxx>]

Hi Steve,

There seems to have a common association between signedess errors and
integer overflow:
http://www.phrack.org/archives/60/p60-0x0a.txt

IMHO, they are not the same. The issue seems pretty much like Apache
Chunked-Encoding Signedess error (when dealing with chunked http
header values) and getpeername(2) system call in FreeBSD. Both
vulnerabilities exploit a condition where negative signed values will
be casted to unsigned values.

In Rodrigo's advisory, condition is very similar to getpeername
vulnerability in FreeBSD, however, latter refers the error as
"boundary checking errors involving signed integers" -- not an integer
overflow:
http://security.freebsd.org/advisories/FreeBSD-SA-02:38.signed-error.asc

It could be called an integer overflow, for example, on a scenario
where an assignment operation envolving the result of two large
unsigned integer is being stored on a signed integer (causing a
negative value), and later this value being casted to unsigned integer
as length parameter to a memcpy (or generic memory copy) operation.

To summarize: advisory incorrectly refers to "integer overflow" when
vulnerability is related to a "signedess error" condition.

Here are my 2 cents.

Kindest Regards,

--
Thiago Zaninotti,Security+,CISSP-ISSAP,CISM
thiago(at)nstalker.com
thiago(at)zaninotti.net
condor(at)sekure.org

On 11/21/06, Steven M. Christey <coley@xxxxxxxxx> wrote:
> A terminology question for people.
>
> In this reference:
>
>   BUGTRAQ:20061115 Re: DragonFlyBSD all versions FireWire IOCTL kernel integer 
> overflow information disclousure
>   http://www.securityfocus.com/archive/1/archive/1/451677/100/0/threaded
>
> The issue is being described as an integer overflow.
>
> I think of an integer overflow as being: "some computation (addition,
> multiplication) would produce an integer value that is too large to be
> stored in the actual memory location, so the integer wraps to some
> other value."  (let's leave integer "underflow" out of this for the
> moment).
>
> However, the relevant code is given as:
>
>   if (crom_buf->len < len)
>      len = crom_buf->len;
>
>   ...
>
>   err = copyout(ptr, crom_buf->ptr, len);
>
>
> Here, the "len" value is not computed in any way, it's simply set.
> The comparison succeeds because it is in a signed context, but the
> copyout() is using an unsigned value.
>
> So, to me, this doesn't look like an "integer overflow," rather some
> issue that's directly related to what I call a "signedness error" and
> what others sometimes refer to as "signed comparison" issues.
>
> Based on what I've seen, integer overflows and signedness errors are
> often closely related, sometimes appearing in the same part of the
> code, so I think they get confused pretty frequently.
>
> Or am I not understanding something basic here?
>
>
> - Steve



--
Thiago Zaninotti,Security+,CISSP-ISSAP,CISM
Info Security Professional