Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Only sometimes - one easy attack is to trigger a web browser to download a .dll file, which doesn't let you overwrite existing files but does get new files on the load path of programs being run out of the download folder. (This was an easy attack on how many people run PuTTY, for instance.)


The million-and-one reason to change so that the browser always prompt you for where to download a file.

That must be one the most braindead defaults of the century. But I guess I'm the weird one as usual.

This is a huge issue for linux as well. Trigger a download and just wait until the OS or some file-exporer inspect the file and exploit the parser (which is typically ridden with security issues).


> The million-and-one reason to change so that the browser always prompt you for where to download a file.

It's only Chrome that doesn't, right? Do other browsers have this behaviour?


Firefox last time I installed it had that behavior. I suppose all other browsers based on Chrome also share that behavior.


That's definitely not default behaviour... you should see a "You have chosen to open x. What should Firefox do with this file?" prompt.


I was replying to the quote about the browser asking where to download the file. By default you get that prompt you mention but it won't let you choose where, if you choose to download it goes without asking to the downloads folder unless you've changed that setting in the options page to always ask where. Chrome is definitely a worse offender, it does not even ask you to confirm the download.


That's why you usually provide your programs in zip files (like nirsoft seems to do) so they decompress to their own folder.


Unfortunately the zip files don't have top level directories, so the default download, extract, run "happy path" would leave them loading any DLL sitting there in the downloads folder.

``` $ unzip -t processactivityview-x64.zip Archive: processactivityview-x64.zip testing: ProcessActivityView.exe OK testing: ProcessActivityView.chm OK testing: readme.txt OK No errors detected in compressed data of processactivityview-x64.zip. ```


The windows zip extract dialog gives the name of the zip file as the default target directory


I'm not sure which dialog you're talking about. Whenever I've extracted a zip file in Windows using Explorer, it's been using "Extract all" or "Extract here". I don't even see a way to get a dialog on my win 10 VM.

Those two options result in whatever's in the zip file being dumped into the same directory as the zip file itself. If the archive contains a top level directory, a directory appears. If it's just an exe and a chm and a readme, like the Nirsoft zips, then those files appear next to the zip archive.


There is only "Extract All", and that opens the dialog. Perhaps you also have 7-Zip installed which creates an "Extract Here" option that dumps the files in the current directory.


I do have 7-zip installed here. I could also be mixing memories across a few Windows versions. I know I've caused files to be extracted without a dialog in the past, which irritated me a great deal, on a vanilla system. But it's entirely possible that's a vista-era memory at this point.


That's not the reason for zip-based distros. Zip's are just easier to sneak past SmartScreen & Co.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: