Re: [w3ctag/design-reviews] JPEG XL decoding (#633)

> > I cannot find any information of what kind of attacks would be possible due to mime type sniffing on images in a Spectre-based world. Could you elaborate more on this?
> 
> See https://github.com/annevk/orb/
> 
> > Could you give an example of how a potential attack could look like that is possible when the jxl magic gets added to the mimesniff spec and not possible when it does not get added there?
> 
> Consider a data file which is not JXL, but gets sniffed as it. It has its content type set to something like `application/vnd.bank.data`, not `image/jxl`.
> 
> By doing `<img src="https://bank.example/sensitive-user-data.bin">` on an attacker's site, `sensitive-user-data.bin` is brought into the attacker's process. They can then use Spectre to read that data.
> 
> If instead the browser required that `sensitive-user-data.bin` had `image/jxl` before it tried to decode the image, then it would not be brough into the attacker's process.
> 

I understand the argument, but in today's world, you can still sniff other mime types, so the start of the data would still end up being brought in the attacker's process (to perform mime sniffing - unless that happens in a separate process, I'm not familiar with the implementation details here), and would end up being brought in the attacker's process if it corresponds to the mime type of another image format.

Most image decoders are able to discard invalid images rather early, so if the concern is about the increased likelyhood of mis-detection, then it's probably not something to be too concerned about (if mime sniffing happens in a separate process, this can be made more secure by performing this initial validation in the separate process - the likelyhood of misdetection can then be made sufficiently small to be likely comparable to errors from cosmic rays).

If the concern is about the attacker being able to control the first few bytes of the private data, then adding `image/jxl` does not open any new attack avenues.

In both cases, it seems to me that pushing for servers to, by default, include a `X-Content-Type-Options           = "nosniff" ;` would be a better solution to this problem.

To be clear, I understand that the objective is having a safer web for everyone, but I disagree that not having Mime Sniffing for new formats that are not executable is a way to get there (I agree it is a good idea for executable ones).

> This is fairly fundamental modern security hygeine, so I'm a bit surprised that you all haven't encountered it before. It's been encoded into the guidelines, which are there for a reason. It's a bit tiring having to educate folks about this; the point of the guidelines is to make it clear how the web is intended to work going forward. I hope you can accept that they were added for good reason, and follow them.

I have personal problems accepting arguments of the form "we have reasons to do this" that don't explain what those reasons are, and I don't believe it is good engineering practice to do so. If having to educate people about the motivations behind a decision is tiring, I suggest documenting these reasons explicitly in a place that is accessible from the decision, and not using an opaque "due to security implications" as a reason for something ;)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/633#issuecomment-840702711