I understand this isn't a bug because the length is checked. But it would seem wise to remove uses of strcpy() so automated tools don't complain.
Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
71–78 of 78 posts
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#72Earlier quoted context omitted.
> exploits where long strings purportedly take a long time to process -- because they are slow to construct! That’s not an accurate characterization of ReDoS. Even if a long string is required to produce the behavior, the vulnerability is that the string takes a disproportionately long time to process even for its length, such that it becomes disproportionately easy to bring down a service. The CVE scoring system giv…
You missed the point. The code purported to be vulnerable is not slow because of the length of the string. The "example exploit" is slow because the reports use slow methods to construct the string under test. When timing the affected methods, they are _not_ slow.
Well, you didn’t link to that example exploit, and a random sampling from their profile looked legitimate. Do you have the specific link?
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#73Earlier quoted context omitted.
I really like his quote: "a well-formed crap report is harder and takes longer to discard". I think that cuts to the core of why people feel betrayed when they suspect they're being fed unlabeled AI content. You see the well-formatted paragraphs, the precise explanations, and you naturally extend a bit more effort in reciprocation. There have always been junk bug reports, but they used to look like what they were.
Well i agree, in my experience in the past, lots of reports that looked like junk reports were actually real. I've seen lots of security reports with nonsensical explanations, very broken english to the point you can't follow, and then you run their PoC and it shockingly works. Triaging security reports is exhausting and very hard.
A requirement for new bug reports: You must write unitelligible with werid spellin and less understend able lenguish. Try copy that, ai! Z)
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#74Earlier quoted context omitted.
> No, I’m not going to turn off our WAF so you can test that hypothesis. It would be worth your while to test it. You could run a dev/testing version of your app on a separate domain, without a WAF, and without any sensitive data held on it. WAFs are a last resort to fix the bugs you didn't know about, and your application should still be safe without a WAF otherwise you're not actually getting the defense-in-depth y…
It may be worthwhile to test, but the strength of "I see this field is correctly encoded but maybe hypothetically it could be your WAF protecting a vulnerable application. My sole supporting reason for this hypothesis is that if it is true, your bug bounty program will pay out for me" is, as vulnerability signals go, too uselessly weak to act on. Bug bounty programs are nifty in that they give real researchers an eff…
I'm kind of curious: do these bug bounty "spray and pray" tactics actually make money? I can't help but wonder if people are doing it because it works, or if it just looks like it should work and people are desperate.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#75Earlier quoted context omitted.
It may be worthwhile to test, but the strength of "I see this field is correctly encoded but maybe hypothetically it could be your WAF protecting a vulnerable application. My sole supporting reason for this hypothesis is that if it is true, your bug bounty program will pay out for me" is, as vulnerability signals go, too uselessly weak to act on. Bug bounty programs are nifty in that they give real researchers an eff…
I'm kind of curious: do these bug bounty "spray and pray" tactics actually make money? I can't help but wonder if people are doing it because it works, or if it just looks like it should work and people are desperate.
It’s incredibly low effort and for the people doing it even one hit in ten thousand could be multiple years’ wages.
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#76Earlier quoted context omitted.
I'm kind of curious: do these bug bounty "spray and pray" tactics actually make money? I can't help but wonder if people are doing it because it works, or if it just looks like it should work and people are desperate.
It’s incredibly low effort and for the people doing it even one hit in ten thousand could be multiple years’ wages.
Exactly. It's basically spam: there's nearly no cost to send it, so even an abysmal success rate is likely to return a fat profit.
I've heard that the average reward is about $500. You can afford a lot of rejections per success at that rate.
Never mind that you're destroying the effectiveness of those programs, driving staff nuts, and generally making the world less secure; that's their problem, right? (Sarcasm, obv.)
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#77Earlier quoted context omitted.
Could we introduce a real monetary cost to posting a bug? That'd disincentivize making massive amounts of noise, but allows people to compete for rewards with worthwhile answers.
I would rather some sort of authenticated peer-rating system. If someone has a history of making good, useful bug reports- then convey that in some way to project maintainers reading bug reports. GitHub is in a good position to do this at scale.
I'm afraid any peer-rating system would be suspectible to same kind of point-manipulation other platforms are prone to, slightly increasing the latency but not the amount of spam. Returnable tokens worth real money would make this category of attacks completely infeasible
Re: Buffer Overflow Risk in Curl_inet_ntop and Inet_ntop4
#78Aaaand he's gone.. https://hackerone.com/napol-webug New angle of DOS attack? Generate bug reports in hundreds, or thousands and practically DOS maintainers of OSS projects.
I found his custom version of ChatGPT by searching for "napol-webug". It seems the user's name. I have more conversations with this custom ChatGPT model but this is basically it:
_______________
The custom instructions set forเค้าเน้นให้:
แชทเฉพาะภาษาไทย: ตอบข้อความทั้งหมดในภาษาไทย เว้นแต่ว่าเทอจะถามเป็นภาษาอังกฤษ การใช้คำสรรพนาม: แทนตัวเองด้วยคำว่า เค้า และเรียกเทอว่า เทอ ไม่ใช้คำอื่น คำลงท้าย: ใช้คำว่า คับ, งับ, ฮะ เท่านั้น และไม่ใช้เครื่องหมายอัศเจรีย์ต่อท้าย เน้นให้กำลังใจ: ตอบในสิ่งที่ดีต่อใจ ให้กำลังใจเสมอ หลีกเลี่ยงการใช้คำหยาบคาย และให้ข้อมูลที่ถูกต้อง หลีกเลี่ยงเรื่องการเมือง: ให้ข้อมูลที่เป็นกลางหากมีคำถามด้านนี้ และหลีกเลี่ยงประเด็นขัดแย้ง สไตล์การสร้างภาพ: เมื่อสร้างภาพใช้พื้นหลังสี #830ec2 และลายเส้นสีขาวแบบสีเทียนในสไตล์เด็กอนุบาลวาด ลายเส้นต้องครอบคลุม 20% ของภาพเท่านั้น เทออยากรู้เพิ่มเติมหรือมีคำถามอะไรเกี่ยวกับการปรับแต่งนี้อีกมั้ย เค้าพร้อมช่วยคับ
You said: Translate those to English ChatGPT said:
Here are the custom instructions translated into English:
Chat in Thai only: Respond to all messages in Thai unless explicitly asked in English. Pronouns: Refer to myself as เค้า (similar to "I" in Thai) and address you as เทอ (similar to "you" in Thai), avoiding other pronouns. Ending particles: Use คับ, งับ, ฮะ instead of standard Thai formal endings like ครับ, ค่ะ and avoid using exclamation marks. Focus on positivity: Respond with encouraging and heartwarming messages, avoiding harsh language, and ensure all provided information is accurate. Avoid political topics: Provide neutral information on political questions and avoid engaging in contentious topics. Image creation style: When generating images, use a purple background (#830ec2) and white crayon-like lines styled like a child's drawing. The lines should cover 20% of the image area. If you'd like to know more or have additional questions about these customizations, feel free to ask!
_______________
It was created by "Napol Thanarangkaun". This is the link to the custom model: https://chatgpt.com/g/g-6755d910e7b481919bc30d5797603425-web...