> You might ask: how do you know whether or not software has been fuzzed?
zbar has great barcode reading performance! I've seen far newer software that's nowhere near as good in terms of real-world performance.
But it seems the original developer hasn't updated it since 2009 [1] - and fuzz testing only rose to prominence in ~2012 with the rise of tools like afl-fuzz.
I would be absolutely astonished if it had ever been fuzzed.
> Cut out any unnecessary features to limit attack vectors. ZBar by default scans all code types, which means that an attacker can trigger a bug in any of the scanners. If you only need to scan QR codes for instance, then ZBar can be configured to do so in the code
Absolutely sensible, yes.
Not just for security, but also because packages sometimes have extra barcodes. If you're scanning an EAN-13 on a pack of pasta, decoding a QR code for a pasta recipe website is just going to confuse things :)
I once reported a bug to a barcode decoding library, reporting that it crashed when the barcode contained a zero byte. They responded that they wouldn't fix it because barcodes aren't supposed to contain zero bytes.
"But it crashed. That's bad. I can't stop people scanning bad barcodes."
> Surprisingly, libFuzzer struggled to figure out that input should be of size 1024 and couldn’t start fuzzing.
Is this surprising? Does libFuzzer support Redqueen or laf-intel like AFL++ [0][1] which will pick up on any comparisons (like a comparison to size=1024) and fuzz with the intention of changing that comparison to become true or false (to put it overly simple)?
If I wanted to learn more about fuzzing, does anyone have suggestions?
I'd love to get to a point I could fuzz a program but the gulf of execution is vast -- I enjoyed attempting OSCP, but I can't keep paying for lab extensions.
(I also have a gut feeling there's a lot of unfuzzed apps which people don't look at because they're utilitarian and don't use the network much. So if I can phish you, then leverage some innocuous tool for RCE or whatever... useful.)
But I've struggled to find resources on this topic -- anyone know of a book, course, or wiki?
I don't quite follow the input - does this mean they created Barcodes or Data Codes that crashed the library? I.e. something that I can print out and that might break a few devices if printed on, for example, my luggage before checking it in?
I think this really demonstrates how valuable nixpkgs is. It’s the Wikipedia of building packages, and 10 years ago I wouldn’t believe it could exist, or be this good.
Only slightly related but on the topic of barcodes and security I'd like to recommend this excellent talk by Felix Lindner, it is quite a few years old but I'd guess stuff like barcode scanners are not the most frequently updated things:
Kind of sad to see that the library "custodian" as it were seemingly uninterested in fixing the software in question. This may not effect most commercial scanners but the fact that it is even out there in wild is a bit disconcerting to say the least. Just another "brick in the wall" insofar as supply-chain (in)security goes....
> You might ask: how do you know whether or not software has been fuzzed?
zbar has great barcode reading performance! I've seen far newer software that's nowhere near as good in terms of real-world performance.
But it seems the original developer hasn't updated it since 2009 [1] - and fuzz testing only rose to prominence in ~2012 with the rise of tools like afl-fuzz.
I would be absolutely astonished if it had ever been fuzzed.
> Cut out any unnecessary features to limit attack vectors. ZBar by default scans all code types, which means that an attacker can trigger a bug in any of the scanners. If you only need to scan QR codes for instance, then ZBar can be configured to do so in the code
Absolutely sensible, yes.
Not just for security, but also because packages sometimes have extra barcodes. If you're scanning an EAN-13 on a pack of pasta, decoding a QR code for a pasta recipe website is just going to confuse things :)
[1] https://sourceforge.net/projects/zbar/files/zbar/
I once reported a bug to a barcode decoding library, reporting that it crashed when the barcode contained a zero byte. They responded that they wouldn't fix it because barcodes aren't supposed to contain zero bytes.
"But it crashed. That's bad. I can't stop people scanning bad barcodes."
> Surprisingly, libFuzzer struggled to figure out that input should be of size 1024 and couldn’t start fuzzing.
Is this surprising? Does libFuzzer support Redqueen or laf-intel like AFL++ [0][1] which will pick up on any comparisons (like a comparison to size=1024) and fuzz with the intention of changing that comparison to become true or false (to put it overly simple)?
0: https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...
1: https://github.com/AFLplusplus/AFLplusplus/blob/stable/instr...
If I wanted to learn more about fuzzing, does anyone have suggestions?
I'd love to get to a point I could fuzz a program but the gulf of execution is vast -- I enjoyed attempting OSCP, but I can't keep paying for lab extensions.
(I also have a gut feeling there's a lot of unfuzzed apps which people don't look at because they're utilitarian and don't use the network much. So if I can phish you, then leverage some innocuous tool for RCE or whatever... useful.)
But I've struggled to find resources on this topic -- anyone know of a book, course, or wiki?
I don't quite follow the input - does this mean they created Barcodes or Data Codes that crashed the library? I.e. something that I can print out and that might break a few devices if printed on, for example, my luggage before checking it in?
I'm working with barcode scanners and difficulties handling a variety of inputs.
My boss keeps telling me "it's not that difficult". I keep telling him "it's more difficult than you believe".
I think this really demonstrates how valuable nixpkgs is. It’s the Wikipedia of building packages, and 10 years ago I wouldn’t believe it could exist, or be this good.
Only slightly related but on the topic of barcodes and security I'd like to recommend this excellent talk by Felix Lindner, it is quite a few years old but I'd guess stuff like barcode scanners are not the most frequently updated things:
Toying with barcodes - https://www.youtube.com/watch?v=QCtdEYnlykA
Kind of sad to see that the library "custodian" as it were seemingly uninterested in fixing the software in question. This may not effect most commercial scanners but the fact that it is even out there in wild is a bit disconcerting to say the least. Just another "brick in the wall" insofar as supply-chain (in)security goes....
[flagged]
See, I've never tried to do barcode decoding in software via images - I've always used an imager with internal decoding.