The definitive question about cybersecurity

As a third year student of Computer Engineering at a known University in Madrid and an information secuirty enthusiast, I can’t help but panic when the subject is taught incorrectly or misleadingly.

Needless to say, progress has been made in the last years. We have a course specifically designed to teach computer networks security. The university does not prosecute you if you find vulnerabilities in their systems, they know about responsive disclosure and acknowledge you instead. And so on.

But when it comes to the average student of CS… can we say the whole degree makes them security-aware? What about secure programming?

mytar Laboratory 1: study case

New academic year. I enroll in the Operating Systems subject. First laboratory practice. Here’s the statement:

In this assignment the student must create a command line tool called “mytar”, this tool must be able to create a tarball archive containing several files, or to extract the files from a previously created tarball.

After a couple of days I finish the task and submit it.

During the development of the tool I remembered how difficult it is to program in C: memory management, buffer overflow, among others. Most of my mates’ code have these problems from time to time. No surprise, we have just been introduced to C. First vulnerability found, the classic memory management vulnerabilities no-one teaches you about in the degree.

Nonetheless, if you happen to be a CTF player, you may have thought about vulnerabilities of a different nature.

Does a name like Zip Slip hit home?

Our program has a vulnerability that has been among us for almost 30 years. And that’s simply because the specification of the .tar format in our Lab script, even simplified to an extrem, still does not take safety into account.

Here’s an snippet from my code, and a hint. Our mytar program does not check nor sanitize the path of the file it is going to extract. Can you spot the problem?

//Open the file to extract
FILE *subfile = fopen(descriptorList[i].name,"wb");

//Extract the contents to the file
copynFile(tarfile, subfile, descriptorList[i].size);

//Close the file
fclose(subfile);

In the first line we use the filename or path, that is found on the .tar file, to create the extracted file in the system.

What would occur if our .tar file is malicious and contains the following path to extract?

../../../../var/www/index.html

Let’s tear down this path string. Firstly we have the following:

../../../../

Which when working with filesystems, in essence moves to the parent directory. In this case, 4 times.

/var/www/index.html

Next, the file is writen to the give directory, but starting from the root directory / if we have gone upwards in the filesystem tree. We’d be executing something like the following:

fopen("../../../../var/www/index.html","wb");

Linux servers, specially web servers, usually have the data of the web server in the /var/www/ path. Uncompressing the malicious .tar would overwrite the index.html in the filesystem, with the malicious file provided by the attacker (which could then deface the web, execute javascript in the users’ browsers, etc).

Malformed .tar file.

More concerning in this particular case is that some professors often compile and execute the student’s code in their computers with a series of tests to check the expected behaviour of the submissions. As you can see, the attack surface is just huge.

Conclusions + References

A plain Google search shows that this laboratory practice has been in use for several years at the faculty. It has been reviewed by a plethora of professors too, but this specification design problem has not been addressed.

In addition, .tar format is not the only compression format affected, as .zip files’ specification is equally flawed. It is old and wasn’t created with security as a necessity.

If you want to know more about the history of these errors and exploits, which exist since 1991, check out the following video. Also covers other vulns like the ones with symlinks: