ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Fuzzing Wireshark with oss-fuzz

From: Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>
Date: Wed, 21 Dec 2016 13:49:25 +0100


On Wed, Dec 21, 2016 at 1:38 PM, Moshe <me@xxxxxxxxxxxxxxx> wrote:
I apologize for my lack of clarity. Peter is correct, I am interested in fuzzing dissectors.

My plan is to have the sequence of raw bytes represent a pcap file. There can be many packets in a single pcap, which would allow testing state interactions.
I will be also interessing to fuzze also libwiretap because often found some issue on this part of code

about cmake VS autotool
cmake is now the default for Windows (and macOS ?) but there is always autotool and no plan to remove for the moment...
But i think better to use cmake !
 

Moshe


On Dec 21, 2016 6:19 AM, "Guy Harris" <guy@xxxxxxxxxxxx> wrote:
On Dec 21, 2016, at 2:12 AM, Peter Wu <peter@xxxxxxxxxxxxx> wrote:

> From the efforts that I have seen, Moshe seems to be targeting the
> dissectors functions. Since these may appear over the network, it is
> probably one of the more interesting parts to tackle first.

Then I'm not sure how well

> The second step is to create a fuzzing interface. The fuzzing interface needs to have the following signature:
>
> extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
>   DoSomethingInterestingWithMyAPI(Data, Size);
>   return 0;  // Non-zero return values are reserved for future use.
> }

matches the way it works.

If you have a program called "rednose", that takes a JPEG image, looks for noses, and colors them red, you could have an API that takes a pointer to an array of bytes containing a JPEG image, and a size_t giving the total number of bytes in the image, and call the nose-detector-and-colorer API (although, given that the argument is a const pointer, it'd have to provide some output buffer).

I guess you *could* have an API that takes a *single* blob of data and hands it to the frame dissector, with enough metadata to have it interpreted as an Ethernet frame, and that would catch *some* issues.  It wouldn't catch any issues that would only show up with a sequence of packets.

Is there some way to fuzz code that's *not* stateless, and that takes a *sequence* of bits of input, in order?

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe