Iconv, set the charset to RCE: Exploiting the glibc to hack the PHP engine (part 3) https://www.ambionics.io/blog/iconv-cve-2024-2961-p3

#PSA #PayPal is changing their privacy statement/terms of service starting November so that they can sell your information to merchants.

You CAN opt out, but you have to do it before they start:

Settings > Data & Privacy > Manage shared info > Personalized shopping, and toggle that shit off

ETA: this is probably country specific, due to differing privacy laws.

You can try privacy>settings>recommendations

Check replies, people have found the same toggle under a different header.

New on blog: "The perils of transition to 64-bit #time_t"

"""
In the "Overview of cross-architecture portability problems", I have dedicated a section to the problems resulting from use of #32-bit `time_t` type. This design decision, still affecting Gentoo systems using glibc, means that 32-bit applications will suddenly start failing in horrible ways in 2038: they will be getting `-1` error instead of the current time, they won't be able to `stat()` files. In one word: complete mayhem will emerge.

There is a general agreement that the way forward is to change `time_t` to a 64-bit type. Musl has already switched to that, glibc supports it as an option. A number of other distributions such as Debian have taken the leap and switched. Unfortunately, source-based distributions such as #Gentoo don't have it that easy. So we are still debating the issue and experimenting, trying to figure out a maximally safe upgrade path for our users.

Unfortunately, that's nowhere near trivial. Above all, we are talking about a breaking ABI change. It's all-or-nothing. If a library uses `time_t` in its API, everything linking to it needs to use the same type width. In this post, I'd like to explore the issue in detail — why is it so bad, and what we can do to make it safer.
"""

https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/

Them: “This is not a paywall.”
Me: “whew”

Them: Provide your Email address”

Me: “that’s a payment, though. Personal information is a payment”

Analog filters, part II: let it ring

https://lcamtuf.substack.com/p/analog-filters-part-2-let-it-ring/?1

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