Re:"The issue was detected by our new AI-powered vulnerabili...
by GuB-42 on Saturday February 24, 2024 @06:28PM
(#39496100)
The problem looks minor, but real.
The reporting is terrible though. Publicly releasing severe vulnerabilities is not very ethical. But they also called it severe without actually analyzing it.
Their AI really looks like a useful tool, but that's not the best way to show it off to say the least.
Is it a commercial system and is their intention to advertise that they found a severe vulnerability in curl with it?
Re:"The issue was detected by our new AI-powered vulnerabili...
by dale_glass on Saturday February 24, 2024 @06:03PM
(#39495948)
Unfortunately, UB has some extremely nasty characteristics, and even if it doesn't do anything nasty now, it's not a guarantee that it won't turn into a problem later.
Making assumptions about what the code should be reasonably interpreted as is unfortunately not a good bet to make.
At any time, a new compiler version may do something bizarre when it figures out the code is UB.
Re:"The issue was detected by our new AI-powered vulnerabili...
by MauranKilom on Saturday February 24, 2024 @06:30PM
(#39496114)
Agreed - I am a bit troubled by the maintainer stance here, even if they have to wade through a bunch of AI nonsense every day and this report is fluffed up way too hard.
"We assume 64 bit overflow is not going to happen because nobody can store that many bytes" could be valid if the existence of those bytes was required for reaching this code. But if user input can lead to UB being triggered here, fixing the code is indeed prudent, even if everyone were fully convinced that current compilers are not outsmarting themselves.
Re:"The issue was detected by our new AI-powered vulnerabili...
by justinclift on Saturday February 24, 2024 @07:27PM
(#39496440)
It looks like a minor bug that was reported as a high severity security issue, with the reporter not being able to explain why other than "this kind of error CAN be bad".
Not sure if I'd be snarky for the first few clueless reports, but I'd probably be getting there after several of them have happened.
Re:"The issue was detected by our new AI-powered vulnerabili...
by SebFender on Sunday February 25, 2024 @09:18AM
(#39501008)
Automation in vulnerability scanning just doesn't work. We've tried many and the end result is too much noise. Code better, review in multiple steps. Simple efforts do work very well.
Also, the bot filed another issue on a different repo referencing the source issue, despite the complaints: https://github.com/mirror/wget/issues/25
The reporting is terrible though. Publicly releasing severe vulnerabilities is not very ethical. But they also called it severe without actually analyzing it.
Their AI really looks like a useful tool, but that's not the best way to show it off to say the least.
Is it a commercial system and is their intention to advertise that they found a severe vulnerability in curl with it?
Making assumptions about what the code should be reasonably interpreted as is unfortunately not a good bet to make.
At any time, a new compiler version may do something bizarre when it figures out the code is UB.
"We assume 64 bit overflow is not going to happen because nobody can store that many bytes" could be valid if the existence of those bytes was required for reaching this code. But if user input can lead to UB being triggered here, fixing the code is indeed prudent, even if everyone were fully convinced that current compilers are not outsmarting themselves.
Not sure if I'd be snarky for the first few clueless reports, but I'd probably be getting there after several of them have happened.
Tell them privately first, ideally with a repro