- In the issue comments the Gitlab employee says "Sorry, I cannot go into details right now. I will link the issue here once it goes public, is it ok?"
It could maybe potentially be exploited in a very interestingly crafted email, where there's link to download something (e.g. the source tarball, or a build artifact) with an URL containing the username, or being otherwise close by, so that the downloaded file would be interpreted differently. But I'm not creative enough at this hour to suggest a working exploit.
Maybe it's something to do with a MIME sniffing attack. The user profile URL may be detected as a different MIME type by the browser based on the extension: https://gitlab.com/myname.js
AFAIK in MIME sniffing IE guessed file type based on its content [1], not URL. And given that IE is rarely used nowadays not sure if it still relevant.
I've played with this before. A correctly implemented mail library should handle e.g., subject lines that contain SMTP control characters. I developed a lengthy repro for an email parsing issue in an ancient version of some java email library that contained a truely horrendous parser, only to find out that the library had been updated internally recently :-)
Even webserver returns a mime, browser may sometimes still ignore it and guess it themselves, because server may be wrong. Unless the server ask them `absolutely don't do it` via the header. a.k.a. `X-Content-Type-Options: nosniff`
But even there is a header for that, there will still be situations that clients don't care and guess it themselves (probably because software is too old or other reason).
Correct. You want to set Content-Type and X-Content-Type-Options.
The story is that in some cases, Internet Explorer could be tricked to ignore the Content-Type header. Instead of fixing the core bug, Microsoft decided to add a header (presumably, they didn’t want to break existing websites). A decade later, people discovered two ways to bypass X-Content-Type-Options. This time, Microsoft fixed the core issue instead of adding X-Content-Type-Options-For-Reals.
Actually when I reported security issues with XCTO:nosniff to Microsoft the answer was something like "well... we don't care, but you can hope that with Edge going to chromium engine things will change". Firefox fixed it eventually.
I think even browser nowadays still do it. A file in <script src="" /> will be treated as script even mime is wrong. A file ended with .mp4 will be play as video even it says it is a text/plain file. Browser guess mime from contents at many places, just you may not notice it.
There is not much ruby magic in that code. This is just a naive use of data from another module.
Somewhere in the Gitlab code base there is a MIME_TYPES map with common extensions as the map key. No idea what it is used for but that module is very likely the target of a recent security issue.
The first fix to combat the "publicly unknown" vulnerability was to prevent usernames ending with any of the keys in the MIME_TYPES map using a simple "ends_with" strings check. Of course the map keys did not have periods so the ends_with would also match "Asimov" with the "mov" suffix.
The second fix in this PR is to extend the ends_with check to add an extra dot.
The actual vulnerability is still unknown but I suspect it's something like an intermediate component that performs special handling based on interpreting URLs and that could bypass security/ACL checks.
Thanks for the link -- you solved a nagging mystery for me[0]. In the '90s, I worked for a tech guy from Texas who referred to the clippers that we used to cut the ends of zip ties off as dikes.
Of course, being a teenager, the term often came with a raised eyebrow from me since it was commonly used as a slur for lesbians. He was the only person I've encountered in my life who used that term in that manner and over the years I just assumed it was some bit of obscurity related to where he started working in systems. I guess not!
[0] I'm sure the right Gooble query would have gotten me an answer but it teetered on the edge of "I don't care enough to bother" until the answer was presented.
That's what actual MIME types are for. You can serve a .jpg as a .txt file and still have the browser display it correctly as an image if you use image/jpeg. Same for the other way around or any other combination of file and MIME types.
You're not wrong, but I bet there are lots of things that will assume based on url (rightly or wrongly). e.g. I've seen a lot of nginx reverse proxy setups implement different caching policies based on url suffix (again rightly or wrongly).
Yeah, if you for example use the 1001th hip electron based browser (with some hand-crafted curl workers and custom fetchers with an express based proxy-backend included in the background mangled together with some weird mix of 20% javascript and 80% typescript and a combination of at least 400 different npm packages over a commit history of two weekends) to browse the web ... of course, that assumption might break. :^)
Do you remember when MSIE would ignore the MIME type the server sent, and sniffed the contents of the beginning of the file downloaded and overrode what the server sent?
