Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 4217] Integer overflow in ZBEE zdp discovery dissector

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4217


anomie <roe.anthony@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roe.anthony@xxxxxxxxx
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #2 from anomie <roe.anthony@xxxxxxxxx>  2009-11-09 08:44:27 PDT ---
(In reply to comment #1)
> Your observation would be true if the ep_alloc() would take a guint8 as
> parameter. Instead it takes size_t, which is larger than that. That means
> user_length is promoted first before the addition, with no risk for overflow.
> 

Hi Jaap.

Thank you very much for your response. I was unable to find an RFC for the
protocol to write a proof of concept and make certain that the bug was a bug.
But I decided that I would fail safe and report the issue anyways, just in
case. 

I thought that the cast occurred before the addition operation as well, so I
wrote a small test app and it made it appear that the addition operation
occurred before the cast. (Un)fortunately my test app contains an error, I used
a signed char and not and unsigned char in my test. As you can see below, both
give very different results :). Again, thanks for all of your hard work and I
am very sorry to have wasted your time.

#include <stdio.h>

int f(unsigned int t)
{

  printf("Size: %8x, Val: %8x\n",sizeof(t), t);

  return 0;
}

int main()
{

  unsigned char uc;
  char c;

  c = 0xfe;
  f(c+1);
  c = 0xff;
  f(c+1);

  uc = 0xfe;
  f(uc+1);
  uc = 0xff;
  f(uc+1);

  return 0;
}


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.