(Windows desktop) Are there any obvious security holes in the practise of one exe calling another one, passing-in parameters that you wouldn't want anyone to easily snoop?
(Windows desktop) Are there any obvious security holes in the practise of one exe calling another one, passing-in parameters that you wouldn't want anyone to easily snoop?
I have foo.exe, and at a certain point I want it to also launch bar.exe with command line parameters that include a username and a password, or possibly a connection string and login credentials; is there any easy way for someone to 'intercept' those values?
Both are Delphi executables, FWIW.
I have foo.exe, and at a certain point I want it to also launch bar.exe with command line parameters that include a username and a password, or possibly a connection string and login credentials; is there any easy way for someone to 'intercept' those values?
Both are Delphi executables, FWIW.
Any process manager, including Windows' Task Manager, is able to get the command line parameters of a running executable (Delphi or not).
ReplyDeleteSo this is not a secure way of passing sensitive information.
I am not a security expert but a (Named) Pipe might be a better way to go (but take that with a grain of salt).
I could easily replace bar.exe by a self written proxy application that passes all command line arguments and pipe contents to the origin bar.exe and back to foo.exe. This proxy could write all contents into a log file including usernames and passwords.
ReplyDeleteYou should consider encrypted communication between both applications.
EDIT: The Windows TaskManager gives you the option to display the command line arguments for each running application.
Totally agree with Christopher Wosinski, in that the communication should be encrypted
ReplyDeleteThanks Nicholas Ring , Christopher Wosinski - that's cool. It didn't seem like a very good way of passing data :-)
ReplyDeleteNamed pipe. Encrypt with a GUID as key. Job done.
ReplyDeleteAndrea Raimondi guids are not random. http://security.stackexchange.com/questions/890/are-guids-safe-for-one-time-tokens
ReplyDeleteOh, I know that :) but I think this is not a problem for many reasons:
ReplyDelete1) They are locally unpredictable. You can never tell which one the next will be,
because they can be generated for a variety of reasons.
2) My understanding is that the information is "transient", i.e. when you close the
pipe you can kiss it goodbye
3) Since you're using a pipe, getting to the information means that you have to
know that and you have to get a hold of it. It is possible but not easy.
4) If you add a bit of Public/Private key, you can scale this across an intranet (I do not
advise to use auto-generated keys across the internet)
5) The information size is in the order of a few bytes, a frequency analysis is extremely
difficult unless you know what kind of information is being transferred
6) If you change the GUID often, you have most of the advantages of an OTP without its
costs.
A
Do not reinvent the encryption wheel yourself. Reuse existing wheels and keep them up to date. The parties maintaining the existing wheels are often having a hard time keeping them secure, but rolling your own is orders of magnitude more complex, time consuming and risky. Communication encryption should usually be at the transport layer (hence TLS), nowhere else. At the message level is possible but a lot harder.
ReplyDeletehttp://security.stackexchange.com/questions/5089/when-should-i-use-message-layer-encryption-vs-transport-layer-encryption
Jeroen Wiert Pluimers I contend the notion of "rolling your own" when we are talking about established algorithms :) As long as you do not roll your own implementations (which I agree is a stupid idea), just using established and secure algorithms and principles in a creative way isn't detrimental to security. Plus, we are not talking about Fort Knox here, this guy needs a simple way to make peeping some connection data much harder. Security is also context, you can't use a tank to cross the road to your grocer. From what Rob Uttley says, this is not something that needs super-high security. If/when the conditions change, then my answer is going to change as well.
ReplyDeleteThe only real thing here is: is he underestimating the risk? Is his data that attractive? If he is then the onus is on him to re-evaluate his risks and flag them appropriately.
Up to then, something simple such as my suggestion - in my opinion - is the way to go.
A
note that the security hole in encryption software most often has to do with the parts where there's a fallback to older implementations/algorithms. as long as you disallow fallbacks and only enable/uses the lastest algorithms you should be good. take for instance https. There is nothing wrong with TLS 3 (aka 1.2) it's the fallback to SSL where the problems are.
ReplyDeleteFurther note that it's trivial to install a hook into any exported function in any dll that your program uses. Which means that none of the WinAPI is safe from eavesdropping.
ReplyDeleteBottom line is any machine to which a person has access can be compromised. The best two strategies are:
ReplyDelete1. Limit access to only authorized personnel
2. Make it as difficult as possible for a would be intruder to inspect an executable.
1 is fairly straight forward. 2 usually requires sacrificing performance with each additional layer of security.
+Johan Once you've let malicious software onto your machine, it's game over. The fact that hooks can be installed is neither here nor there. I can't install a hook on your desktop because I don't have access to it. Once I've got access to it, you've lost the game.
ReplyDeleteIn other words, it's not a secuity hole if a user who has access to your machine can do what the owner of the machine can do normally.
Parameters bad for all of the above unless the parameter is useless for a second execution and is meaningless in ago senses of the word. So encrypted and sequence dependent. Using https is neat reuse but may give you firewall issues. I'd you own both exes and the idea is to stop prying eyes or surrogate invocation then I would say symmetric encryption with a clock based window would be fine. It is a pain to groundhog day a machine just to run one bit of sw. In this way a command line, windows message, dropper file, com, or whatever would be fine. Which did you select?
ReplyDeleteHey, hi Jason Chapman , hope you're well. In the end we decided we would take the opportunity to make the project a single exe rather than a couple of exes, so the problem ceased to be (though obviously we created new ones in it's place).
ReplyDeleteInteresting idea about the encryption and time-based window, it would be cool to find a bit of time to play with that as an idea/approach in it's own right, for some possible future use.
Hope to catch up with you soon!
V sensible. Hoping to be able to catch up soon.
ReplyDelete