fertleo.blogg.se

React 16 unpkg
React 16 unpkg










react 16 unpkg

Tar: exploit/link/oops.txt: Cannot open: Not a directory I figured there is no way this would work with any mature tar implementation, and sure enough this fails to extract on my laptop: It creates a symlink to /tmp called link, and then tries to extract a file to link/oops.txt. We can extract files into a folder, we can create symlinks… can we extract files into a directory pointed to by a symlink that’s already been extracted? I pulled out my hex editor and made a tar file that tries this.

react 16 unpkg

I went ahead and reported the symlink issue to the unpkg maintainer and went to sleep.īut then I started thinking more about tar files. Second exploit attemptĪt this point I was kind of bummed that I couldn’t figure out a way to take over this server. The reason the server returns Content-Length: 0 is because stat /proc/self/environ returns a size of 0, and that’s what unpkg uses to set that header. My guess is that some reasonably clever reverse proxy at Heroku sees the Content-Length: 0 and cuts out the body of the reply. When reading the /proc/self/environ, my local instance reported Content-Length: 0, but still returned the file in the response body. My guess is that this had to do with the incorrect HTTP Content-Length returned by the server. Unfortunately (fortunately?), something about Heroku’s environment made it so that I couldn’t read /proc/self/environ on the real unpkg server. In these environment variables is a Cloudflare API key which I was thinking an attacker could use to do nefarious DNS-related things with their API (this was an untested assumption – I don’t know if Cloudflare supports restricting the permissions on their API keys). On my local instance of unpkg, I was able to use this bug to read /proc/self/environ, which would spit out the environment variables of the webserver process.

#React 16 unpkg code

The second problem with this code is that even if headers.type did correctly check for symlink, the main attack below still worked due to issues with the tar library’s implementation of ignore functions. So right away this gives us arbitrary file reads on the server by creating a symlink to / and browsing through the directory with the web interface. With this tar library, the header.type for a symlink entry is symlink, not link. The first problem with this code is that it doesn’t actually ignore symlinks like it says it does. To serve react’s package.json file, for example, you can just visit Or, to get a directory listing of the whole package, you can visit a snippet of what unpkg used to extract the tar file when it pulled a package: function ignoreSymlinks ( file, headers ) Unpkg lets you read any file out of a package once it’s extracted. If it doesn’t, it pulls the corresponding tar file from npm. When you request a URL like unpkg checks if it already has the package downloaded and extracted at /tmp/unpkg-react-16.3.2/. Don’t trust a third-party CDN – use subresource integrity and pin hashes! Vulnerability If exploited, this bug would have allowed an attacker to execute malicious Javascript on thousands of websites, including the homepages of PNC Bank, React.js, and the state of Nebraska. I found a vulnerability in a tar implementation that allowed me to write arbitrary files onto the unpkg server, including into other packages. Tl dr is a pretty popular CDN for serving up assets from npm packages.












React 16 unpkg