Opening Applications
Two things:
1- system() is BAD, I get that. How could I open wordpad without:
system("notepad.exe salesReport.dat");
2- Can I open wordpad in a read-only mode so that the .dat file cannot be edited?
1- system() is BAD, I get that. How could I open wordpad without:
system("notepad.exe salesReport.dat");
2- Can I open wordpad in a read-only mode so that the .dat file cannot be edited?
Alternatives to start external programs are ShellExecute or CreateProcess();
I think there is no way the open the file in read-only mode. An option is the make the file read-only before you start Nodepad.
I think there is no way the open the file in read-only mode. An option is the make the file read-only before you start Nodepad.
Well, it is what
OTOH, if you don't care about that or (hopefully) you actually want an interface to the shell, then it's fine to use. There's plenty of software which provides that functionality.
I guess it's important to not rely on the effects of a call to system(), though there's nothing inherently wrong with it when it's used as intended.
system() is for, but it makes assumptions about the shell and the software it's targeting, which is a humongous security hole. Couple that with the fact that the binary could likely contain the command string in cleartext, you've got a monstrosity if you care at all about security. OTOH, if you don't care about that or (hopefully) you actually want an interface to the shell, then it's fine to use. There's plenty of software which provides that functionality.
I guess it's important to not rely on the effects of a call to system(), though there's nothing inherently wrong with it when it's used as intended.
@mbozzi,
I don't understand the security issue. Any program could mess up my system - if I use system("abc.exe") or if I execute it from the desktop or command line.
I don't understand the security issue. Any program could mess up my system - if I use system("abc.exe") or if I execute it from the desktop or command line.
It's not a security hole when used in the proper context.
On Windows systems, Notepad may be a targeted process, but you have no reason to believe that it would present a security issue that doesn't extend far beyond the execution of a user program.
Alternate options:
1) Create a utility that lives in the same directory as your executable that simply displays a text file (read only), and system() that. (Most secure.)
2) Use CreateProcess() (as indicated above) to start Notepad. (Avoids the shell, but this method is no more secure than calling system().)
If you wish, use getenv()/setenv() to observe/constrain the PATH before calling system().
On Windows systems, Notepad may be a targeted process, but you have no reason to believe that it would present a security issue that doesn't extend far beyond the execution of a user program.
Alternate options:
1) Create a utility that lives in the same directory as your executable that simply displays a text file (read only), and system() that. (Most secure.)
2) Use CreateProcess() (as indicated above) to start Notepad. (Avoids the shell, but this method is no more secure than calling system().)
If you wish, use getenv()/setenv() to observe/constrain the PATH before calling system().
@Thomas1965
Sorry for the late reply!
The fundamental issue is that the caller can not always guarantee the behavior of the call, which makes it a potential security problem. For example, if a user calls something like
If you've ever used a Unix-like system, this sort of interaction is used all the time, and it's pretty great -- all my tools launch my preferred editor, use my preferred pager, all my software's installed according to my preferences, and in general all my apps use the defaults provided by the environment. But the assumption is that the environment is trustworthy. If you can't make that assumption then system() is maybe a bad choice.
Take a look at the CERT page: https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=2130132
Sorry for the late reply!
The fundamental issue is that the caller can not always guarantee the behavior of the call, which makes it a potential security problem. For example, if a user calls something like
std:: system ("foo"), but "foo" has been replaced with a shell script that runs rm -rf $HOME, then there might be trouble. If you've ever used a Unix-like system, this sort of interaction is used all the time, and it's pretty great -- all my tools launch my preferred editor, use my preferred pager, all my software's installed according to my preferences, and in general all my apps use the defaults provided by the environment. But the assumption is that the environment is trustworthy. If you can't make that assumption then system() is maybe a bad choice.
Take a look at the CERT page: https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=2130132
Topic archived. No new replies allowed.