If you feel like joining the “fun”, here’s the javadoc for #Ghidra Version Tracking:

https://scrapco.de/ghidra_docs/Features/VersionTracking/javadoc/

(I had to update my script again to include this - digging up docs for NSA sw really has some Quest for Knowledge vibes…)

@wendynather and 2 slides into "how to fix it", I've quoted you

Again, really hoping they record your talk, so I have some new quotes from when I update these slides 😅

I’m happy to see that the GOV.UK Service Manual’s “Building a robust frontend using progressive enhancement” page was updated this week and made it to the top of Hacker News today. The technology industry would collectively save unimaginable quantities of time, money, energy and stress if this single page were required reading for everyone involved in building a web site. https://www.gov.uk/service-manual/technology/using-progressive-enhancement

#patchfriday on #cups #vulnerabilities

https://patchfriday.com/158/

@jeffvanderstoep Thanks for your reply! I don’t doubt the validity of your measurement. I’d argue about two things:

• The simpler thing is communication: the phrase “half-life” or “decay” implies that vulns disappear without explicit dev intervention, e.g. as a side-effect of unrelated code changes (or even the passage of time!). While this may be true in some cases I don’t see how the data would (or could) support such an observation.
• My understanding is that when we look at overall results of different vuln discovery strategies (your study) or applying the same strategy with “more force” (Böhme-Falk) we basically see the effects of testing coverage, and it’s no surprise we can grow coverage faster in new code. What I think would be more revealing is looking at new vulns(/LoC?) vs code age when a new discovery method (e.g. a new sanitizer or more intelligent test-case generation ) is introduced. FTR: I bet such data would actually confirm your results, but without data about the effect of new discovery methods I think drawing conclusions about code “maturity” is much harder.

"Sometimes, hacking is just someone spending more time on something than anyone else might reasonably expect.”

— Jerry Gamblin

40th Weekly Vuln Research newsletter is OUT NOW 📰

iOS kernel exploitation from @alfiecg_dev

Elgato hacking from @dt_db

@_tsuro bypasses CET

RCU Internals from @u1f383

Google Teams check off their OKRs

➕ Jobs and more 👇

https://blog.exploits.club/exploits-club-weekly-newsletter-40-ios-kernel-exploitation-cet-bypasses-elgato-hardware-repair-and-more/

Samba can also expose your CUPS configured printers too so it's not just 631/tcp to be watchful of.

That's not typically the default but we're talking about something that is fundamentally designed to be a server & queue manager for others on the network. By default, cupsd (the actual server & queue manager) may well be bound to localhost, with browsing set to no and various IPP API endpoints restricted with location ACLs but all of these can and are changed for various reasons (witness 631/tcp being open).

We had a short look at the buffer overflow found by fuzzing `process_browse_data` to determine its exploitability. Conclusion: this bug alone won't give you RCE, or even an info leak.

https://bird.makeup/@evilsocket/1839394447286751430