tetha

I don't think a UAF on its own allows control hijacking in an exploit. You will need further logic bugs or the ability to legitimately or illegitimately control memory, either via further requests / function calls, OOB writes and such. And it will always be extremely specific to the application vulnerable.

For example, I remember an exploit workshop around reuse of passwd entries. The vulnerable would validate a passwd entry for a non-root user, use it a bit, and later on free and zero it out for security purposes... except it then looked at the passwd entry again in some conditions. Suddenly, the uid was non-zero at first, and zero later on, so later decisions assumed the user was root.

In a more concurrent situation, a possible vulnerability was a shared cache of these passwd entries. It wouldn't zero them out anymore, but you could create a race condition of starting requests as user A, and then hammering requests as user B, so you'd end up mixing up the permission contexts of these users. Because the passwd entry that had been released back to the pool was overwritten, and then re-read with the value from another context.

The necessary line of thinking tends to be very different from thinking about program code regularly.

If the addressed person does not comply, you can also add "or else" in a threatening tone.

Such a funny movie.

And even with a mutual agreement - default LLM output tends to be very hard and inefficient to read. We've spent quite a bit of time at work to setup a few writing skills for Claude.

For example, mine is a technical writing skill based on the old book "The Art of Scientific Writing": Front load information as much as possible - the first paragraph of a document should be a summary, the first sentence of a paragraph should summarize. Short sentences building on each other. Always show evidence.

Someone else spent quite a while optimizing a standardized PR description template, with a section for intent, expected changes, risk, rollout coordination and such.

That made the slop a lot more tolerable.

Oh nice. Then I have to thank you for a possible non-horrible upgrade path. If you were close by, I'd invite you for some icecream or a round of pool :)

Good to know. Does the first invocation recompute and check the hash of the wheel locally afterwards to ensure integrity?

Rebind the keys for player one.

That being said, the one player campaign seems way faster and higher damage than I remember. But heck I love this blast from the past.

And strictly speaking you cannot trust the pip upgrade of pip with the vulnerable cert in the trust store due to certifi, which you also cannot upgrade safely with pip for the same reason. All of these are at one out of two compromises from being MITM'd during the upgrade.

So strictly we have to burn everything python to the ground and reinstall entirely.

They are also incentivized to find high severity vulnerabilities - and/or to announce found vulnerabilities as high severity.

After all, what would all that hardware and research be worth it, if it didn't find the most critical vulnerabilities around?

Well at least we know about it while or before the giant patch effort for everything else goes on. Just put it onto the pile.

Who turned on hard mode this week?

It's the attitude that riles me.

This demonstrates how hard we are messed up in a CA revocation. But no need to rub it in like that, is there?

> He added that global SSL/TLS is a small part of eMudhra’s business contributing to about 1% of the global revenue

Good that we are now investing thousands of engineering hours globally to fix this.

Several tech stacks require upgrades of their runtime, python is an ungodly mess with certifi, but yes. It's just 1% of your revenue.

Sorry, it's been a long week.

I think I'm too old for this industry

I want to go back to talks by bored defcon guys or gals calmly stating how they obtained private keys of a globally trusted CA with just a bit of math. Which, mind you, ate the other part of the teams time.

Now I know how much I hustled today likely due to that atrocity of a video. I think I will take a vacation day and sit in a forest near a river on friday.

Quite the strange communication. It was posted on the forum in May, and may have landed in developer notes afterwards, but the general mail to users went out less than 1 month before deadline. And now quite a few customers are mad.

It's also not the best business case. We've been tolerating infra-code in Bitbucket, because it would be a pain to migrate.

Now someone snidely remarked: Once we have done this migration in a hurry, don't we know all the places we have to touch to move out of Bitbucket - in order to avoid such short-term activity? It's difficult to answer no to that.

Curiously, that makes integration a trapdoor function and a possible cryptographic primitive. Not a very practical one, but...

I'm on the fence there.

To pace something is a fairly regular formulation in racing, running, cycling, most sports. You can "pace yourself to reach the festival by bike in about three hours to not gas out". This means to control your speed and time investment intentionally so you don't run out of energy or steam and run into leg cramps before your goal. We can "pace a rollout slowly to burn out risks", or "increase the pace of a rollout due to adverse factors".

But I have noted a point to simplify my vocabulary at work to optimize the audience capable of understanding. So I rather defer the delving into deep dark corners of the dictionary derived from devouring literature to a simple intro or outro, and people find it funny, especially if the rest is easy to read. Claude on the other hand does not do that.