Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Copy Fail

copy.fail

Post reply on HN
Print view View original

541–545 of 545 posts

Re: Copy Fail

#541

Post by Orygin »

psifertex wrote: post #510
Orygin wrote: post #403

Earlier quoted context omitted.

Considering they kinda botched the disclosure to Linux distros, I guess they wanted something most sensational to sell more licenses.

They did not, in fact, botch anything. They notified the responsible party and followed a practice that is pretty much the accepted norm (and for good reason). How recursive should their notifications be? Just the tip three distros? The top dozen? Every embedded Linux router company? How about every hosting provider? They did what they're supposed to without being paid for it. The only other good source of funding fo…

But they most probably did get paid for it, they have ads for their shit all over the website.

Re: Copy Fail

#542

Post by hansvm »

amluto wrote: post #523
asveikau wrote: post #305

Earlier quoted context omitted.

I feel like it should be possible to fulfill these advantages with a minimal, not very complex API. I.e. the grandparent's comment about IPsec implementation details doesn't make the cut, but a hardware accelerated cipher implementation does.

A hardware accelerated DMA-capable cipher implementation is an odd thing, and it’s generally not useful on its own. You might want to set up a whole chain of operations (encrypt, checksum, send to network, for example), but I’ve never encountered a case where you actually want to ask an accelerator to asynchronously encrypt application data and return the encrypted data to the application.

Unless you're pushing a ton of extra work into a network-capable accelerator, that sounds exactly like what you'd want for, e.g., an encrypted S3 implementation. You have encryption, RS encoding, striped checksumming, sending fragments to multiple hosts, some sort of potentially interesting partial failure handling, etc.

You could push that all down to the accelerator, but if there are even a few such use cases you might want a dedicated DMA-capable implementation instead.

Re: Copy Fail

#543

Post by rcxdude »

still_grokking wrote: post #253
ebiggers wrote: post #232

As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. Th…

As I did not know what AF_ALG is in the first place I've searched for it and found this here: https://www.chronox.de/libkcapi/html/ch01s02.html It states the following: > There are several reasons for AF_ALG: > * The first and most important item is the access to hardware accelerators and hardware devices whose technical interface can only be accessed from the kernel mode / supervisor state of the processor. Such sup…

This suggests that it is useful in some niche embedded use- cases, but should probably not be enabled by default on most desktop/server kennels

Re: Copy Fail

#544

Post by eqvinox »

ebiggers wrote: post #232

As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. Th…

Yeah, so, as we just learned (dirty.frag) the issue isn't algif_aead, it's authencesn and you can exploit it through plain network sockets rather than AF_ALG.
Post reply on HN