Notices by Falcon Darkstar (falcon@mastodon.falconk.rocks)

@ryanc you have to do the whole context switch and all the marshalling just to do one round of a cipher, which for example, to compute one block's key stream in AES-CTR on a modern x86 processor is one instruction.

@ryanc in CBC mode, can't be done. In XTS, CTR, CCM (decryption key only) or GCM, it's O(1) to do it yourself and the syscall overhead would be wild.

@ryanc this one is perhaps different from the usual (data breach for which there are no real consequences) in that it exposed how risky their product is, but also possibly mitigated by the fact that this doesn't say anything negative about whether it can do what it says it does.

@eff yup. Same story brewing with other security vendors. Tenable could soon take down the financial world with one similar bad update to their agent.

@inthehands @dekk I have built a portfolio that specifically excludes AI hype stocks for this exact reason, even to the point of avoiding index funds.

Though to be fair, I put my IRA in over a hundred individual stocks instead of index funds some time ago initially because the index funds would put me in defense contractors, Tesla, surveillance crap, tobacco, and oil, and zero commission trading makes this feasible.

Read this as advocacy for taking first-order account of the interests of stakeholders other than investors.

That probably looks like tax revenue funding open source, for example, without it being about defense or some objective beyond just making industry more efficient. Like any other project about maintaining the commons.

This isn't even so radical as expropriation. It's just recognition that the digital age made new types of public infrastructure.

Capital is dumping its resources into AI because it believes it will advance capital's interests of further accumulation of labour's products. It does not matter in the short term that capital is sorely mistaken. Much like a bad king, capital's misallocation reduces output available to labour too (by preferentially allocating resources to those who participate in the squander). We will suffer this for so long as we permit capital to make macro allocative decisions.

The current all hands on deck for AI approach of capital is like if a 20th century property developer were able to allocate substantially all road building, electrification, and water piping resources to a new subdivision. Which they are sure people want to live in, but actually smells bad and is mostly built atop a landfill.

@GossiTheDog I wonder why they cited, of all things, a King County Superior Court civil case here?

@hllizi It is broadly that, but I also disagree with the zealots shouting at people who find C is the right choice for their project, and I think (for specific reasons) that the people pushing to rewrite large amounts of code in e.g. Rust are pushing to waste a lot of time. It is more pressing, though much harder, to improve and better specify what that code is to do.

Sure, many new technologies have changed the world. But it's a high bar. Many also didn't. And many made it a lot worse. And until your favourite one starts to clearly make things better, I'm going with the presumption that it is in the far more common category of those that won't.

@dalias @andreasdotorg @ariadne and yet Chromium is among the most broadly impactful code that exists. To me this signals that "the problem" lies elsewhere, probably in the things us LangSec people have been on about for over a decade.

@andreasdotorg @lanodan @ariadne All I'm really saying here is, the memory corruption RCE vulns tend to be in things that are heinously complex and hard to implement correctly (or even define correctness for), and meanwhile my professional experience and that of my colleagues is dominated by things like logic bugs in managed code that just give up all the sensitive data for fun, and nobody keeps track of those bugs, and I see no work on systematic mitigations for them.

@andreasdotorg @lanodan @ariadne people constantly miss the forest for the trees in exactly this way. The asset to defend is usually /not/ the execution environment. So if you spend all your scarce resources rewriting things to be able to defend one part of one layer of one of the execution environments that impacts on the asset to defend, you've misallocated. Especially where effective compensating controls already exist.

@andreasdotorg @ariadne do you not suppose that, possibly, the plethora of memory corruption issues in a web browser stem from its being asked to place extreme priority on speed while processing a cacophony of ill-defined languages that run up to unrestricted grammatical complexity?

@andreasdotorg there are dozens of things, each urgently needed, competing for scarce resources. Sitting where I do a lot of the time in cloud, memory corruption vulnerabilities are extremely unusual, but remote code execution is sadly not. Privesc and authorization bypass issues are dramatically more common than code execution across every platform I have worked with, and the consequences are equally dire, and mitigations for the entire class also exist.

For greater clarity, the problem is not that you as a developer are lazy. It is that you as a developer likely spend time doing things that do not help make code secure, and things that actively make security harder, because you are part of a software development culture that continuously reinforces that certain things (high levels of abstraction, generated code, hidden functionality, pedanticness) are in fact good.

To make it a primary concern to use a memory-safe language repeats the mistakes of 4PLs, Java, and so forth. No programming language can save you from confusing, obscure code that nobody owns, or from a lack of comprehensible requirements, or from a platform where you have to remember to consistently do a bunch of specific logical operations.

The problem is not unchecked native code, it's (probably) you! And the way you were taught to code, and the values you hold about what makes code good!

What I take from this:
- Developers must take ownership of code, understand it, and document it
- Platforms must rely on developers to do the right thing less frequently and remind developers (with warnings) more frequently
- Requirements analysis is an ongoing process
- We should build simpler code that is more easily understood, which also means making code more concrete and platforms more explicit

Notice how none of this is about which language to write in.

Experience being my guide, where there is vulnerable code, there is nearly always one of these conditions in the developer team:
- Cannot explain the code's intent in the vulnerable case
- Does not know why legacy code exists or who owns it
- Is unaware of requirements imposed by the platform
- Did not intentionally incorporate the vulnerable functionality
- Is unaware the vulnerable case is implemented

By the way, memory safety is not even slightly the focus of these things.