I think I've found the reason for this.
When a web server encounters an error, it normally serves a document (usually an HTML document describing the error) to the browser, indicating the error condition using the HTTP status code.
According to this bug report, Firefox originally always displayed the returned document; normally this is what you want. However, a user found an issue with a misconfigured AOL server: when requesting a nonexistent EXE file, the server would serve the 404 page, but with an incorrect Content-Type. That caused Firefox to offer to download the HTML document with a .exe extension, which was confusing since there was no indication that any error occurred. They changed the behavior with a simple hack (not warranting the effort of writing a new error message page, since it's an uncommon case, instead reusing the "not found" page, which makes sense in the specific example given by the bug's reporter).
From the bug report that @m4573r found, it sounds like the current behavior when Firefox receives a response with an HTTP code signaling an error, and the response's Content-Type is something other than HTML, then Firefox displays a "File not found" error page.
The vast majority of web servers are configured to serve an HTML document on error, which is why you don't normally see this. But in this corner case, the error message doesn't make sense.
wget -d http://www.ssa.gov/framework/images/icons/png/ confirms what's going on here:
---response begin---
HTTP/1.1 500 Server Error
Server: Generic Web Server 1.0
Date: Thu, 20 Feb 2014 23:29:57 GMT
Cache-control: public
Content-type: magnus-internal/directory
Transfer-encoding: chunked
---response end---
It's serving the error page with the bogus Content-type of magnus-internal/directory, triggering the behavior in Firefox.
Evidently Google thought that this behavior made sense and implemented it similarly in Chromium.