2

Scenario:
I am running on an embedded linux distro with a C++ application on it. I need to simply compress a directory and place the zipped output at a certain location. Thats it.

I know that we can tar compress a directory using the following command on a command line interface.

tar cvzf directory.tar.gz /path/to/directory

I see that I have an option to run system commands in C++. Following is a example ot it.

void CompressDirectory() {
    std::system("tar cvzf directory.tar.gz /path/to/directory");
}

Environment:
Embedded Linux

Question:
I wish to know the pros and cons of making a system call to tar a directory vs using a library like zlib, zipios etc.

TheWaterProgrammer
  • 7,055
  • 12
  • 70
  • 159
  • 2
    Related : [Why should the system() function be avoided in C and C++?](https://stackoverflow.com/questions/19913446/why-should-the-system-function-be-avoided-in-c-and-c) – François Andrieux Jan 11 '19 at 15:03
  • I comment instead of answering because I'm only expressing my opinion. You'd rather use a library (libtar) than making a system call. You have much, much, much better grasp on what's happening between the library and your code than between the environment you're program is running on and your code. – YSC Jan 11 '19 at 15:03
  • @YSC It depends on how much resources you can afford to spend on this task. Using `system` is easy, using a library you can spend days understanding how to use the API and introduce errors while using it. And then your boss asks why it took you days to just archive a directory and why there is so much code to do so. – Maxim Egorushkin Jan 11 '19 at 15:07
  • On a RaspberryPi or low-importance PC on your home network behind a firewall that only you and your family/friends use, go for `system()` every time. Other than that, you'll have to weigh up the risks - but how likely is it that someone who has permission to replace `/usr/bin/tar` would do that - because if they could, they could more simply remove all your files themself if that was their aim. – Mark Setchell Jan 11 '19 at 17:24
  • I am working on a system into which someone breaks in is able to replace a program like `/usr/bin/tar` then there is a bigger issue. The whole system is compromised. That is a situation which has bigger issues than just my compressing logic failing. I was interested in more non security related hassles like how weak is the logic if done through a system command and so on. – TheWaterProgrammer Jan 11 '19 at 17:44

2 Answers2

1

system() is generally frowned upon because of the potential security risks associated with it. In your specific circumstances where everything is explicitly stated, you'd be OK.

You CAN code it in the program to be handled and processed programmatically and not shelling it out and that's the proper way to do it.

So long as your tarball name and directory are both hard coded, I can't think of any security issues, but I'd be careful that you're sure you're not overwriting anything or something similar.

Do not use system() if anybody other than yourself is even able to touch your server.

UtahJarhead
  • 2,091
  • 1
  • 14
  • 21
  • 1
    Someone could provide a malicious replacement for `tar` in a place that would be found before the real `tar` and have it run with the user's privileges. It's an entirely external vulnerability you can't easily protect against. – François Andrieux Jan 11 '19 at 15:06
  • 1
    I am in full control of the environment I am running on. The embedded linix distro I am running my app on is prepared by my own teammates. And my app is not running in a cross platform environment in production. If this is the case then do you still see security threats in the system call based approach? – TheWaterProgrammer Jan 11 '19 at 15:07
  • 1
    @FrançoisAndrieux You can hardcore that path `/usr/bin/tar`. If a malicious user replaced that executable that means they already pwned you. – Maxim Egorushkin Jan 11 '19 at 15:08
  • 1
    @Game_Of_Threads I mean, you can assume you are in full control of the environment but this is still a vulnerability that can facilitate escalation of privileges *in case someone gets into your system*. There's no point in discussing security vulnerability if you start with the hypothesis that nobody can get into your system anyway. – François Andrieux Jan 11 '19 at 15:09
  • 1
    Security issues are not caused by user data, they are caused by its bad usage or bad escaping by programmer. And if `tar` is replaced, the sistem is already compromized. – Qwertiy Jan 11 '19 at 15:13
  • 1
    Interesting that replacing a zip file by malicious program is a concern. That could happen even when using a library API based approach. Isnt it? How does it matter? The output of whether library based approach or system based is always a tar ! – TheWaterProgrammer Jan 11 '19 at 15:19
  • 2
    @Game_Of_Threads `tar` in this discussion means the binary that is executed when you use the shell command `tar` not a compressed archive file. My comments are specifically addressing *"I can't think of any security issues"* by proposing other potential security issues. – François Andrieux Jan 11 '19 at 15:20
  • 1
    @FrançoisAndrieux Ah I understand. Thanks for clarifying – TheWaterProgrammer Jan 11 '19 at 15:22
  • 2
    @Game_Of_Threads If I placed a `tar` binary that wiped your home directory in the same directory your program resides or wherever your platform would find it you would be in for a surprise. Though as Maxim points out you can get around that by hard coding the entire path to tar. But this goes to show that it's easy to let subtle mistakes introduce security vulnerabilities. And it's not because you can't think of other issues that they aren't there. `std::system` is very powerful and as such presents a unique risk. It's possible to use it safely, but it's also possible to easily make mistakes. – François Andrieux Jan 11 '19 at 15:25
  • 2
    @Game_Of_Threads "I am in full control of the environment I am running on" - said everyone until they weren't... – UKMonkey Jan 11 '19 at 15:28
  • Modified my post to reflect the consensus. Forgive me father for i have sinned. – UtahJarhead Jan 11 '19 at 17:13
1
  1. At least you don't check the result in the current code. You don't know if compressing fails.
    You have to check exit code at least.
  2. In general case tar can be not available in command line (on windows, for example).
    It's not your case, so you can ignore this point.
  3. Custom library should give more flexible compressing. Like pause, select files, unlimited number of files and so on.
Qwertiy
  • 19,681
  • 15
  • 61
  • 128