gynvael

Hahaha thank you, if needed we have a few more options. For now I'm sticking to it since it's familiar territory for me.

That might be something at Google Cloud ingress then. We're not blocking on IP level (we have some other stuff, but it shouldn't interfere with Tor).

Wait, you're getting blocked trying to download Paged Out!? This most likely is a problem with your ISP, not with the zine's server. Check with them first.

Actually the title is what doesn't change, not the page number. I.e. the object manager has a mapping where a given object (article) is in memory (on what page, pun intended). So you have to go through the object manager to resolve the mapping each time you want to interact with the object... or at least that's how we have it implemented in the web viewer ;)

It should be available on lulu until the end of the week. We're running QA on it still.

What you've described is the printed version of Phrack!

Ahaha thank you for this comment, it's peak internet meme culture. Made my day :D

Actually, I do think I'm right ;)

There are two layers two this. On the formal, C and C++ standard lawyering layer, UB can have any result. I of course agree with this as per my previous comment.

However, the compilers are an actual implementation, and actual implementations do things in deterministic ways (even if randomness is involved, realistically it is limited to a certain set of outcomes). As such, in case of UBs it's not "anything can happen" - there is actually a limited set of things that can happen.

And I do believe you've missed the "especially on the offensive side" part of my comment. What you are saying about "if found in production is to rewrite it and fire or reeducate the author" is the defensive security perspective, not the offensive security one. From the offensive security perspective you aren't there to fix the code - you are there to exploit it and hack into the system / leak info / raise your privileges.

Haha this comment is spot on :)

Yeah, like left-to-right as in JS for example.

Hey! Author here :)

So let me start by saying that that blog post was written was 15 years ago and I don't even remember the details of it and what I've written there. But, I have a hot-take on this topic you've touched on!

From a programmer perspective, you are absolutely right. The behaviour is undefined, end of discussion. A programmer should never rely on what they observe as the effective behaviour of an UB. A programmer must avoid creating situations in code that could result in the execution flow venturing into the areas of UB. And - per C and C++ standards - results of UB can be anything (insert the old joke about UB formatting one's disk being a formally correct behaviour).

However, I'm a security researcher, and from the security point of view - especially on the offensive side - we need to know and understand the effective behaviours of UBs. This is because basically all "low-level" vulnerabilities in C/C++ are formally effects of UBs. As such, for the security crowd, it still makes sense to investigate, understand, and discuss the actual observed effects of UBs, especially why a compiler does this, what are the real-world actual variants of generated code (if any) for a given UB for this and other compilers, how can this be abused and exploited, and so on.

My point being - there are two sides to this coin.

This sounds like a Paged Out article ;)