A (Potentially) Serious Script Issue

[Rat]

Last Friday I was playing around with the ChunkVNC AutoIt scripts trying to get a good handle on how they actually worked and tarting up the InstantSupport dialog GUI when I inadvertently installed the server installation script into the root of my main Data drive RAID stack. When it generated the "scratch.bat" self delete batch file it then proceeded to recursively delete every file on the disk starting from 'A'. I realised what was happening when it got to the 'D's... (about 100,000 files) and pulled the plug on the workstation literally. My PC has since spent the past 3 days in the electronic equivalent of surgery while I restored all the deleted files, firstly from the disk itself using "Handy Recovery" and later from a full-disk image taken 3 months ago.

I would like to suggest that the functions "_SelfDelete" and "_DeleteTemp" be modified so that they can't delete any files other than those that should exist there, ie:

"cad.exe"
"logo.jpg"
"InstantSupportVNC.exe"
"ChunkVNC.exe"
"schook.dll"
"rc4.key"
"MSRC4Plugin.dsm"
"ultravnc.ini"
"chunkvnc.ini"

... and only delete the "$TempPath" folder if it is subsequently empty.

[Rat]

Here is a simple example of what I have in mind:

(Note: there were 2 bugs in the original batch file, (a) There should have been a space before 127.0.0.1 and (b) When deleting the batch file the full path should have been surrounded by double quotes.)

[ps. I'm now doing all my script debugging in a VirtualBox machine ]


Func _DeleteTemp( $iDelay = 0 )
Local $sCmdFile
FileDelete( @TempDir & "\scratch.bat" )
$sCmdFile = 'PING -n ' & $iDelay & ' 127.0.0.1 > nul' & @CRLF _
& 'DEL /F /Q "' & $TempPath & '\cad.exe"' & @CRLF _
& 'DEL /F /Q "' & $TempPath & '\logo.jpg"' & @CRLF _
& 'DEL /F /Q "' & $TempPath & '\InstantSupportVNC.exe"' & @CRLF _
& 'DEL /F /Q "' & $TempPath & '\ChunkVNC.exe"' & @CRLF _
& 'DEL /F /Q "' & $TempPath & '\schook.dll"' & @CRLF _
& 'DEL /F /Q "' & $TempPath & '\rc4.key"' & @CRLF _
& 'DEL /F /Q "' & $TempPath & '\MSRC4Plugin.dsm"' & @CRLF _
& 'DEL /F /Q "' & $TempPath & '\ultravnc.ini"' & @CRLF _
& 'DEL /F /Q "' & $TempPath & '\chunkvnc.ini"' & @CRLF _
& 'RMDIR /Q "' & $TempPath & '"' & @CRLF _
& 'DEL "' & @TempDir & '\scratch.bat"'
FileWrite( @TempDir & "\scratch.bat", $sCmdFile )
Run( @TempDir & "\scratch.bat", @TempDir, @SW_HIDE )
EndFunc



Func _SelfDelete( $iDelay = 0 )
Local $sCmdFile
FileDelete( @TempDir & "\scratch.bat" )
$sCmdFile = 'PING -n ' & $iDelay & ' 127.0.0.1 > nul' & @CRLF _
& 'DEL /F /Q "' & @ScriptDir & '\cad.exe"' & @CRLF _
& 'DEL /F /Q "' & @ScriptDir & '\logo.jpg"' & @CRLF _
& 'DEL /F /Q "' & @ScriptDir & '\InstantSupportVNC.exe"' & @CRLF _
& 'DEL /F /Q "' & @ScriptDir & '\ChunkVNC.exe"' & @CRLF _
& 'DEL /F /Q "' & @ScriptDir & '\schook.dll"' & @CRLF _
& 'DEL /F /Q "' & @ScriptDir & '\rc4.key"' & @CRLF _
& 'DEL /F /Q "' & @ScriptDir & '\MSRC4Plugin.dsm"' & @CRLF _
& 'DEL /F /Q "' & @ScriptDir & '\ultravnc.ini"' & @CRLF _
& 'DEL /F /Q "' & @ScriptDir & '\chunkvnc.ini"' & @CRLF _
& 'RMDIR /Q "' & @ScriptDir & '"' & @CRLF _
& 'DEL "' & @TempDir & '\scratch.bat"'
FileWrite( @TempDir & "\scratch.bat", $sCmdFile )
Run( @TempDir & "\scratch.bat", @TempDir, @SW_HIDE )
EndFunc

[supercoe]

Holy crap!

Before people get scared, please keep in mind that this only happend because the sources were modified to install into the root of the drive.


I'll make the change to only delete certain files instead of the program directory.

Testing in a VM is always a good idea

Sorry about the problem you had and thanks for providing a fix.

[supercoe]

This issue has been confirmed by another user that running ChunkVNC_3_1\SRC\InstantSupport_Files\ChunkVNC.exe by itself will install to the root of the drive.

This will make the uninstaller think that the root of the hard drive is the path to delete the program!

I apologize that this has caused a few headaches, I wasn't expecting people to just open up the source directory and start running any executable they find. Silly me

This issue has been corrected for the next release.
Once again, if the installation instructions are followed, this is not an issue.

[microbolt]

Not sure exactly the steps I did but I was bitten by this bug. I wasn't fortunate enough to be running in an VM. Was on my production machine :( I know I just finished compiling the Instant Support and had it like I wanted then I went to see if I could change the program icon.

I executed ChunkVNC_3_1\SRC\InstantSupport_Files\ChunkVNC.exe and it launched and put an icon on my desktop that was worded something like "ChunkVNC Service Uninstall".

I then clicked the Uninstall on the desktop. I noticed a few icons came up missing on the desktop. Rebooted thinking it was just a glitch as wasn't refreshing and logged back in with same problem.

Everything on the drive was deleted starting at the root of the drive (c:\). Everything in my profile (including My Docs, Pictures etc) All the folders in c:\program files. It didn't delete some files and I'm just assuming maybe they were in-use or I rebooted before they had a chance to delete.

Is it possible to implement the script like Rat posted that just looks for targeted files to keep this from happening? Luckly I'm one of the few who actually backs up files so didn't loose too terribly much (except for the for day in resetting up OS and programs, lol, and a few invoices in Quickbooks that I didn't have backed up, and all the work I did customizing it :( )

[supercoe]

Sorry about your troubles but honestly what is possessing people to just randomly run executables??!???

[rant] Nowhere in the instructions does it state to do anything like this and the source code is available to READ what ChunkVNC.exe does instead of just blindly running it.... [/rant]

phew.... sorry....

As long as you haven't written anything to the drive use a program such as Active File Recovery to get your data back.

Feel free to implement Rat's changes yourself into the source code, wait for 4.0 where the issue is fixed or stop blindly running executables.

Once again, if the installation instructions are followed, this is not an issue.

[microbolt]

Not sure why I deserved that. I'm not here to complain or rant or anything else. I commend you on your work on this and I find it a very useful solution. I was just confirming a potentially big (and dangerous) bug.

The reason I ran that executable is I was looking into creating my own 7zip executable package. I would of never in a million years thought running a single app called ChunkVNC would delete my entire hdd. I didn't have any reason to be weary of it... That's not a typical action a software takes.

Like I said in the other post my data loss was limited as I had a recent backup. I'm not worried about what I lost and was just trying to help by sharing my results so that someone else didn't end up with the same outcome as me.

I'm sorry if I offended you by bringing this up as it was not my intention. I just thought that if you knew that another person had confirmed that this was an issue that it might just warrant a minor release to prevent someone else from losing information.

[supercoe]

Microbolt,

Sorry I came off strong, it was not my intention to put you down and I apologize for that.

Please understand my confusion as it amazes me that this situation would even occur.
To assume "That's not a typical action a software takes." about an executable that is buried inside a program just seems ridiculous to me.

I'm new to creating programs that are open to the public and this has been an eye opener for me in terms of my program design.

At this point in time I'm not planning on releasing a minor update as this issue doesn't exist under normal program execution.

Sorry again if I made you feel uncomfortable, I'll try to explain myself with different words from now on.

[microbolt]

No hard feelings from me ;) I was just trying to help keep someone else from losing data.

[guinness]

An idea is to have a fail safe, for example ChunkVNC can only be executed with a commandline parameter, therefore if the average user were to click on it then it would fail with a welcoming MsgBox()

[supercoe]

guinness,

The ChunkVNC.exe file is gone now, InstantSupport.exe handles command line parameters to install and uninstall the service (while only removing specific files).

[guinness]

Ah ... didn't pay attention! Sorry

[B]

In defense of Microbolt and others bitten by this, it's not as if we aren't already required to navigate the directory structure and run particular executables, specifically in order to start the repeater.

In addition, in order to make some of the tweaks you've suggested we need to alter some files in the SRC directory too.

Finally, of course, the recursive deletion was always a bad idea, as I think you've acknowledged.

Anyway, I thought this was all in the past, so I just want to make sure -- I grabbed a fresh copy of ChunkVNC_3_1.zip and there's an executable for "winvnc.exe" there (in ChunkVNC_3_1.zip\ChunkVNC_3_1\SRC\InstantSupport_Files )

Do I correctly assume that that's just a stock UltraVNC server copy and not subject to the "serious script issue", and that Microbolt must have been using an older version of ChunkVNC?

[supercoe]

In defense of Microbolt and others bitten by this, it's not as if we aren't already required to navigate the directory structure and run particular executables, specifically in order to start the repeater.

One can assume that when following the installation guide everything will work as planned.


In addition, in order to make some of the tweaks you've suggested we need to alter some files in the SRC directory too.

Which is why I think it's odd that people will run ChunkVNC.exe just to "see what it does" instead of looking at it's source code.
I'm not trying to make an excuse for the poor design, it honestly never occurred to me that ChunkVNC.exe would be run outside of the directory InstantSupport extracted it to.


Finally, of course, the recursive deletion was always a bad idea, as I think you've acknowledged.

It was a bad idea but was easy to implement at the time since it's the included AutoIt self delete function.


Anyway, I thought this was all in the past, so I just want to make sure -- I grabbed a fresh copy of ChunkVNC_3_1.zip and there's an executable for "winvnc.exe" there (in ChunkVNC_3_1.zip\ChunkVNC_3_1\SRC\InstantSupport_Files )

Do I correctly assume that that's just a stock UltraVNC server copy and not subject to the "serious script issue", and that Microbolt must have been using an older version of ChunkVNC?

One can see by the digital signature that this executable is from pgmoney (Avantig), it is the UltraVNC server.


The sole purpose of ChunkVNC.exe is to install or uninstall InstantSupport as a service.
The (poor) design of the script doesn't account for a user compiling InstantSupport, navigating to \SRC\InstantSupport_Files and then running ChunkVNC.exe by itself.
In the event that this happens ChunkVNC.exe thinks that it's installed at c:\ and tries to delete that directory during uninstall.


I don't mean to sound harsh and I'm sorry about the troubles that this issue has caused.

[B]

Thanks.... Oh, I was looking at the ZIP contents when I should have been looking at my working / compiled Chunk directory. So there's still a ChunkVNC.exe produced in there after compilation, and we STILL need to be careful to avoid making this mistake until the next version of ChunkVNC is released. Is that right? Sorry, I'm just trying to grasp the situation; I'm not trying to bitch here.

[supercoe]

B,

Correct, this issue still exists in the current release (3.1) everyone should be careful not to run the ChunkVNC.exe file that exists in the SRC\InstantSupport_Files after compiling.

The issue has been resolved for the next release by removing the need for ChunkVNC.exe all together.

[guinness]

If you play fire expect to get burnt!

[mrreload]

Crud, I got bit by this last night. I was hoping to find this was a known issue and what may have caused it. Funny, but I don't remember running ChunkVNC.exe seperately last night although I did a few days ago. My tests will only be done in VMs from now on.
I really think this project is the greatest thing since sliced cheese. I applaud supercoe and others for their efforts here.
I took a look at the 4.0 source and that is going to be a real treat for all I think. When, oh when, can we expect it to be released? By you a beer, fat donation, what will it take?

[supercoe]

Thanks for the props, sorry you were bit by the bug.
4.0 is on the "when it's done" plan at the moment.

[B]

But the bribes wouldn't hurt I would guess.

mmreload, I'm sorry, I almost feel responsible. I saw you exploring the file system at [post=70695][/post] and was actually afraid that might happen.

supercoe, I think you really should patch that current distribution, relative to this bug, in advance of 4.x. (I keep thinking you already did. )

[mrreload]

the bribe/donation will come with my next paycheck:)
I keep coming here, lurking, reading, maybe 4.0 will get released as I traverse the posts.
Spending way tooo much time here.

[B]

Tell me about it, man! Just a few months ago my post count was "0".