https://sourceware.org/bugzilla/show_bug.cgi?id=31250
--- Comment #8 from Amyspark <amy at amyspark dot me> --- (In reply to Nick Clifton from comment #6) > > Actually that is a very interesting point. Does MSVC require that the path > inside the lib point to an object that already exists or one that could > exist, should the element be extract from the library ? For example suppose > that a library contains an element with the path "E:/foo.obj". Is it > required that E:/foo.obj also exists outside the library ? I've just tested this with MSVS 17.9.0 Preview 3.0. No, it is not required to exist outside of the library -- only that there's a folder called "E:" in the root of the .lib, and then "foo.obj" a file inside it. This can be easily verified with the library I supplied earlier and the command > lib.exe > /EXTRACT:"E:\cerbero\build\sources\msvc_x86_64\gst-plugins-rs-0.12.0-alpha.1\_builddir\x86_64-pc-windows-msvc\release\build\ring-2e670d6be8d51b3f\out\crypto\constant_time_test.o" > /OUT:x.o .\gstrswebrtc.lib This should yield a 12KB .o with SHA256 e377eb539cd0fca2a11c0c19920a86832bef6317dbb03b238415d26e2c8146d0. > Is the library > invalid if the external version of E:/foo.obj is different from the internal > version ? Is the library invalid if the host does not have an E: drive ? As per the earlier comment, no, it's not invalid -- I also tested the extraction after clearing the Cerbero build directory. It seems that Rust's archival logic plucks the full path of the object and replicates it inside the .lib, and MSVC's linker does not seem to complain about it, as long as it's listed in the manifest file (1.txt). > What if the library contained an element with the path > "C:/windows/system32/<something>" - surely such a library would be a huge > security risk ? That risk would exist only if an extractor used the path verbatim. I believe it should be treated as untrusted input and sanitized as appropriate (e.g. banish colons on Win32). Another issue, though outside of the scope of binutils, is why would someone be storing object files in C:/Windows/System32. -- You are receiving this mail because: You are on the CC list for the bug.
