cyberax (u/cyberax) - Readit News

cyberax commented on Closures as Win32 Window Procedures nullprogram.com/blog/2025... · Posted by u/ibobev

cyberax · 10 hours ago

This approach was used in the ATL/WTL (Active Template Library, Windows Template Library) in the early 2000-s. It was a bad idea, because you need to generate executable code, interfering with NX-bit memory protection.

Windows actually had a workaround in its NX-bit implementation that recognized the byte patterns of these trampolines from the fault handler: https://web.archive.org/web/20090123222148/http://support.mi...

cyberax commented on Go Proposal: Secret Mode antonz.org/accepted/runti... · Posted by u/enz

tptacek · 13 hours ago

This is just wrong. Not that you can't blow up from a data race; you certainly can. Simply that any of these properties admit to exploitable vulnerabilities, which is the point of the term as it is used today. When you expand the definition the way you are here, you impair the utility of the term.

Serious systems built in memory-unsafe languages yield continual streams of exploitable vulnerabilities; that remains true even when those systems are maintained by the best-resourced security teams in the world. Functionally no Go projects have this property. The empirics are hard to get around.

cyberax · 11 hours ago

There were CVEs caused by concurrent map access. Definitely denials of service, and I'm pretty sure it can be used for exploitation.

> Serious systems built in memory-unsafe languages yield continual streams of exploitable vulnerabilities

I'm not saying that Go is as unsafe as C. But it definitely is NOT completely safe. I've seen memory corruptions from improper data sync in my own code.

cyberax commented on Go Proposal: Secret Mode antonz.org/accepted/runti... · Posted by u/enz

afdbcreid · 14 hours ago

Rust is susceptible to segfaults when overflowing the stack. Is Rust not memory safe then?

Of course, Go allows more than that, with data races it's possible to reach use after free or other kinds of memory unsafety, but just segfaults don't mark a language memory unsafe.

cyberax · 13 hours ago

Go is most emphatically NOT memory-safe. It's trivially easy to corrupt memory in Go when using gorotuines. You don't even have to try hard.

This stems from the fact that Go uses fat pointers for interfaces, so they can't be atomically assigned. Built-in maps and slices are also not corruption-safe.

In contrast, Java does provide this guarantee. You can mutate structures across threads, and you will NOT get data corruption. It can result in null pointer exceptions, infinite loops, but not in corruption.

cyberax commented on Go Proposal: Secret Mode antonz.org/accepted/runti... · Posted by u/enz

robmccoll · 14 hours ago

This is interesting, but how do you bootstrap it? How does this little software enclave get key material in that doesn't transit untrusted memory? From a file? I guess the attacker this is guarding against can read parts of memory remotely but doesn't have RCE. Seems like a better approach would be an explicitly separate allocator and message passing boundaries. Maybe a new way to launch an isolated go routine with limited copying channels.

cyberax · 13 hours ago

> How does this little software enclave get key material in that doesn't transit untrusted memory?

Linux has memfd_secret ( https://man7.org/linux/man-pages/man2/memfd_secret.2.html ), that allow you to create a secure memory region that can't be directly mapped into regular RAM.

cyberax commented on Go is portable, until it isn't simpleobservability.com/b... · Posted by u/khazit

cyberax · a day ago

Cgo is terrible, but if you just want some simple C calls from a library, you can use https://github.com/ebitengine/purego to generate the bindings.

It is a bit cursed, but works pretty well. I'm using it in my hardware-backed KMIP server to interface with PKCS11.

cyberax commented on Capsudo: Rethinking sudo with object capabilities ariadne.space/2025/12/12/... · Posted by u/fanf2

charcircuit · a day ago

The root account shouldn't exist either. Having god accounts is a bad idea security wise. Instead everything should follow the principle of least privilege.

cyberax · a day ago

This sounds good in theory, but in practice it doesn't work. You always end up with an object that has all the privileges.

cyberax commented on Epic celebrates "the end of the Apple Tax" after court win in iOS payments case arstechnica.com/tech-poli... · Posted by u/nobody9999

lapcat · 2 days ago

A service to whom? Protecting users is a service to users, not to developers. This is a selling point of iPhone, and thus Apple receives money from users when they pay for the iPhone.

Think about it this way: totally free apps with no IAP get reviewed by Apple too, and there's no charge to the developer except the $99 Apple Developer Program membership fee, which Epic already pays too.

cyberax · 2 days ago

> Think about it this way: totally free apps with no IAP get reviewed by Apple too, and there's no charge to the developer except the $99 Apple Developer Program membership fee

Yearly fee. And about $500 a year in hardware depreciation, because you can reasonably develop for Apple _only_ on Apple hardware.

This is _way_ more than Microsoft has ever charged, btw.

cyberax commented on Epic celebrates "the end of the Apple Tax" after court win in iOS payments case arstechnica.com/tech-poli... · Posted by u/nobody9999

Someone · 2 days ago

> Speaking to reporters Thursday night, though, Epic founder and CEO Tim Sweeney said he believes those should be “super super minor fees,” on the order of “tens or hundreds of dollars” every time an iOS app update goes through Apple for review. That should be more than enough to compensate the employees reviewing the apps to make sure outside payment links are not scams

I would think making sure outside payment links aren’t scams will be more expensive than that because checking that once isn’t sufficient. Scammers will update the target of such links, so you can’t just check this at app submission time. You also will have to check from around the world, from different IP address ranges, outside California business hours, etc, because scammer are smart enough to use such info to decide whether to show their scammy page.

Also, even if it becomes ‘only’ hundreds of dollars, I guess only large companies will be able to afford providing an option for outside payments.

cyberax · 2 days ago

> I would think making sure outside payment links aren’t scams will be more expensive

On average, Apple spends less than a minute on app reviews for new versions.

cyberax commented on 10 Years of Let's Encrypt letsencrypt.org/2025/12/0... · Posted by u/SGran

tptacek · 2 days ago

Whatever thing you're talking about, it does not appear to be DANE stapling.

cyberax · 2 days ago

It does? The idea was to staple the DNSSEC chain to the TLS, so that clients wouldn't have needed to do the whole DNS pointer chasing themselves.

The problem is that the MITM-ing adversary can just strip the DNSSEC chain and then replace the certificate. Without having a DNSSEC-enabled resolver, the client can't detect that. So stapling doesn't provide any additional security over the self-signed certificates.

The only proposed fix was to pin the DNSSEC-enabled URLs, using TOFU (Trust On First Use). And nobody wanted that.

There was no real discussion about adding the stapling in _addition_ to CA-signed certificates. Because at that time there was no point in doing that, no CA wanted to provide free signing.

This is changed now. The self-signed certificates are no longer status quo.

cyberax commented on 10 Years of Let's Encrypt letsencrypt.org/2025/12/0... · Posted by u/SGran

tptacek · 3 days ago

No it doesn't? Why would it? I'm confused by what it is you think CAs have to do with DNSSEC stapling. CAs are absolutely not the reason DANE staples failed.

cyberax · 2 days ago

Staples failed because they couldn't work alone. They were considered a replacement for completely self-signed certificates.

That's why the committee tried to mandate the stillborn pinning idea.

The option to use stapling in addition to a CA-signed certificate was not really considered. After all, if you paid for a CA-signed cert then why would you bother with stapling?