MS-DOS device names are identified as readable_real
Special MS-DOS filenames return true from a call to File.readable_real? and File.file?. This exposes certain popular projects to a denial of service on the Windows platform.
Modifying File.file? and File.readable_real? to return false for MS-DOS device names will allow standard tests for static files to avoid MS-DOS names. The regular express below can be used to match against known MS-DOS names and should be inclusive, however a second set of eyes would be great.
If you need information on the specific projects affected by this bug, please contact me via email
#1 Updated by caleb clausen over 6 years ago
I'm not certain that the above list is complete. Among other things, windows allows programs to define their own ms-dos device names using DefineDosDevice. It might be better (at least on windows) to query the system for the list of currently defined device names.
It appears that windows ce allows device names which begin with \$device\ or \$bus.
Also, I'm puzzled by the fact that you require a / at the beginning of the device name, and allow . or / at the end. Microsoft's documentation only mentions allowing a : at the end.
I think this might be a better regexp to use (wince devices still not checked here, tho):
relevant pages on MSDN:
INFO: Understanding Device Names and Symbolic Links
Defining an MS-DOS Device Name
Device File Names (for windows ce)
QueryDosDevice Function (can return a list of known devices???)
#2 Updated by Yusuke Endoh over 6 years ago
- Assignee set to Usaku NAKAMURA
- Priority changed from Normal to 3
- Target version set to 2.0.0
According to Usaku, it is difficult to fix this issue.
According to Usaku, QueryDosDevice cannot be used. It determines
some device files (such as CON) as normal file.
At least, we won't fix this issue in 1.9.2 release.
I change the target to 1.9.x and priority to Low.
Yusuke Endoh email@example.com
#3 Updated by HD Moore over 6 years ago
Responding to Caleb: the regex is being used to monkeypatch an application server, the leading / is because the regex is matching an incoming request, not the raw filename, and I should have clarified in the initial report.
It does seem a sticky problem to solve, but it may be possible to combine the known-bad blacklist with QueryDosDevice (.ex: CON will always be a console). I am not sure how frequently DefineDosDevice is actually used, so just filtering a known blacklist may go a long way in the short term.