New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adhere to the least privilege principle #2093

Open
zoidbergthepopularone opened this Issue Dec 22, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@zoidbergthepopularone
Copy link

zoidbergthepopularone commented Dec 22, 2018

I would very much appreciate if X64dbg adhered to the least privilege principle. Specifically, it seems that I need to grant a full write/delete access to the debugger's directory to the user running it, because if I don't, then e.g. breakpoints get forgotten at app reset (CTRL+F2), I get complaints when exiting the debugger, and various other nasty things happen. But giving a full access to the directory is dangerous - anyone can replace the executables there! Would it be possible to move all config, temp, database etc. files to a designated subdirectory (e.g. specified in x64dbg.ini) so that they would be separate from the executables? Then it would be perfectly fine to give a full access to this directory...

@zoidbergthepopularone

This comment has been minimized.

Copy link

zoidbergthepopularone commented Dec 22, 2018

Well, damn. Forgot to delete the rest of the issue and now I can't delete it :(
Sorry!

@torusrxxx

This comment has been minimized.

Copy link
Member

torusrxxx commented Dec 23, 2018

@zoidbergthepopularone

This comment has been minimized.

Copy link

zoidbergthepopularone commented Dec 24, 2018

But that doesn't solve anything at all! The read-only flag can be overcome very easily. I could use the DENY ACLs to somewhat limit the danger, but 1) these would make it quite difficult to upgrade X64dbg, and 2) they still don't protect against all modifications (e.g. delete an .exe and create a new one). Also, I rather hate the idea of getting an insecure system and then trying to secure it, prefering to do it the other way around - start with the secure system and if necessary, release the rules a little.

@torusrxxx

This comment has been minimized.

Copy link
Member

torusrxxx commented Dec 24, 2018

If the malware actually removes the readonly flag and infects your x64dbg installations, then your documents, browser, email, operating system and everything else might already be infected and you will need to clean up the system anyway. x64dbg itself doesn't need to be secured. The biggest usecase I see for a separate db folder and install folder is to allow x64dbg be run from a shared (read-only) network location and allow database files be cleaned very easily. This is a useful usecase although nobody is working on it. It should be easy to add such an option.

@mrexodia

This comment has been minimized.

Copy link
Member

mrexodia commented Dec 28, 2018

In my opinion it is not needed to deal with this. The only useful thing I can think of is to run x64dbg as admin from a folder that only admins can write to and then create the debuggee process without elevation. This would also prevent the child from getting a handle to the parent process iirc.

A separate db folder might be useful in some minor cases, but it is a headache for portable use.

@mrexodia mrexodia added the feature label Dec 28, 2018

@zoidbergthepopularone

This comment has been minimized.

Copy link

zoidbergthepopularone commented Dec 28, 2018

Honestly, I find it awful that even now, security is considered "not needed". Especially when the solution is very simple - just move all the data to a subdirectory, that doesn't break anything but allows for a secure installation. Oh well.

@mrexodia

This comment has been minimized.

Copy link
Member

mrexodia commented Dec 28, 2018

You are welcome to modify x64dbg to fit your use case better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment