It would be nice to have a python (?) script running all the cases mentioned in the issues as bugs.

The following line:

as well as this:

lack the class and user parts of the error message.

It's a quick PR to add them, and make error reporting better :)

$ verify-turnin ex1@zakkak
 You have not turned in ex1 for zakkak!
$ echo $?
0

while it should return a non-zero value.

The project shall be split into two branches, having a generic one and a CSD@UoC tailored one.

Is / really necessary for assignment names?
Currently one can invoke turnin(1) with the following arguments:

turnin lab1/assignment2@course report.pdf

but should this be possible?

Script uses invalid username when using su (checks the parent process owner).

The group of the files LOGFILE and SHA256 is the same as the user who first turned in homework.

There is a chance turnin can fail to get a UID/EUID and shutdown for the calling user. The following Python script demonstrates the issue:

#!/usr/bin/python
import os
os.system("echo aaaaaaaaaaaa | turnin assignment@class file.c")

The result on a Debian system is:

Cannot get user's login (uid XXXX)

The following code converts a UNIX timestamp into a formatted time:

According to the man page, localtime() can return NULL in case there's a problem. This would lead to the following line to dereference a NULL pointer, which can lead to crashes.

Moreover, the fields used are not guaranteed to exist, and may be overwritten at any point. I think the overwrite risk is minimal, given the limited lifetime and lack of concurrency, but it seems localtime_r() exists for that reason.

A couple if statements to check for NULL should do the trick here to remove the memory issue.

A malicious attacker can bypass the symlink recursive check as well as the relative path (contains ..) check by doing the following procedure:

1. Turn In a normal file, e.g. hello.c
2. While prompting for confirmation run the following commands:

mv hello.c h.c
ln -s /etc/passwd hello.c

1. Press y on the turnin binary to proceed.
2. The binary blindly trusts the user since all files have been checked previously.

It has been found that by turning in the same file using turnin(1) results in different SHA-256 hashes being produced. The problem is not with the code of turnin(1) calculating the hash, but with the tgz files being created. Running tar(1) with the same file always produces the same output file.

A user can include a file an infinite amount of times (unless limited by a maxfilesize) in his turnin by passing it as an argument multiple times.

Currently turnin fails badly when making a blank submission (tar subprocess crash). Since it's easily detectable, why not make it fail gracefully with a properly formatted error message?

Now that our web server uses the proper user, maybe we should consider implementing a turnin web front-end that whould work along with the command line version.

Later we could completely avoid setuid writing a python script accessing the web front-end from the command-line (this should be a new project however).

A basic installation of turnin fails to digest a tgz file with the following output:

turnin: Failed to open turned in file '/home/course/TURNIN/ask1/user-1.tgz' for sha-digest.
Please notify the Instructor or a TA.

This happens because there are no unix permissions for the user to read the tgz file.

In order to make the following function call:

to get the user name, turnin elevates privileges to root (for a brief period of time). Maybe this function call required the root access in the past, as it returned the user plaintext password, or their hash, but now that this moved to /etc/shadow and /etc/passwd is world-readable, perhaps it's no longer required, and we'd be able to get a response without becoming root.

We need to test the behavior of this function on the Debian 11 systems that are currently deployed, and if it works without elevated privileges, to remove the code (to become root, and then user) around it.

An ill-intentioned individual can bypass the "max turnin limit" check using the following trick:

1. When there's only 1 turnin left, open 2 copies of turnin with the same arguments (assignment, class, files)
2. Press y on both binaries acknowledging this is your last turnin available.
3. When both binaries ask you for file confirmation, press y on both. The second one will fail with an error that it can't write the file.
4. You can use turnin once more and overwrite the latest turnin. The LOGFILE will look as below:

turnin 1.9: username -  1 09/18/14 18:03   2
turnin 1.9: username -  2 09/18/14 18:03   2
turnin 1.9: username -  3 09/18/14 18:03   2
turnin 1.9: username -  4 09/18/14 18:04   2
turnin 1.9: username -  5 09/18/14 18:04   2
turnin 1.9: username -  6 09/18/14 18:04   2
turnin 1.9: username -  7 09/18/14 18:05   2
turnin 1.9: username -  8 09/18/14 18:05   2
turnin 1.9: username -  9 09/18/14 18:05   2
turnin 1.9: username - 10 09/18/14 18:06   2
turnin 1.9: username - 10 09/18/14 18:08   2

It is currently unknown whether this allows n+1 turnins or unlimited. Further tests will follow.

An attacker can use turnin(1) to turn in arbitrary files outside of an assignment folder. More specifically, by running:

turnin @course file.c

the binary will turnin the file to:

/home/course/TURNIN//.

which of course translates to:

/home/course/TURNIN/

A malicious user can cause turnin(1) to have undefined and unpredictable behaviour by issuing the following commands to a bash(1) shell:

mkdir TURNIN
mkdir TURNIN/undef
ln -s /dev/urandom TURNIN/undef/LIMITS
turnin undef@username file.c

where username is the user's username and file.c any valid and legal file.

A malicious attacker can exploit the recursive symlink algorithm within the turnin binary to cause a segmentation fault. The issue is caused upon entering the following commands into a bash shell:

ln -s a b
ln -s b a
turnin assignment@class a

It is not clear whether this flaw is exploitable by an attacker but heuristics (i.e. I am too bored to try) show it's not.

Under specific circumstances tar(1) can crash with flag 0xff00 if the binary turnin(1) has no permission to read the input file.
Additionally, turnin(1) can crash if it has no permission to read the files during isbinaryfile() called by addfile().
A (race condition triggering) bash(1) script to demo these vulnerabilities can be found here:

printf "y\ny" | turnin hw@course hello.c & sleep 0.001; chmod 000 hello.c

where 0.001 should probably be changed until you manage to reproduce both crashes. For minimum values that sleep(1) cannot perform, use an echo(1) and maybe an echo(1) to a file.

One can cause turnin to crash by turning in a proper file and upon requesting confirmation of the files remove the file or change its name. There will be further investigation because it is believed this can cause out of bounds read/write.

In the LIMITS file, a user is allowed to enter negative values in the fields maxfiles, maxkbytes, maxturnins, binary.

Currently, turnin(1) creates a symlink pointing to the latest turn in. Running tar -vxf user9999.tgz fails with errors that the file is not a valid tar file.
(Request from [email protected])

In the following part of the code, we get the username that is associated with a particular user ID:

The code correctly copies the string to a local variable, as according to the man page, there's no guarantee that this value will continue to live there long term (it's in the static section, and is overwritten by subsequent calls).

However, according to the man page, there's no guarantee that the struct fields that are pointers to char arrays will not be NULL. Although in practice this always worked, I think it's much safer to introduce a NULL check to avoid a dereference.

turnin is a homework submission platform. We can add support for automatic grading during submission.

If the AUTOGRADE file is present, turnin should refer to the LIMITS file and look for the following configuration value:

autograde ~/tests/ask1_test.py

• If this line is not discovered in the LIMITS file, turnin should continue normally.
• If the file does not exist, turnin should continue normally.
• If the file is not executable, turnin should continue normally.

If this line is discovered, turnin should execute, as the class account, the script at ~/tests/ask1_test.py.
It should pass as the first argument the full path of the submitted file, in the .tgz format. After the script execution finishes, the stdout will be presented to the user, while the stderr of the script will be sent to /dev/null or ignored.

This feature can be used to automate grading and let the students know, during the submission, of any incorrect things they did or things they should pay attention to. Optionally, this script can also return a grade estimation for the current submission.

Every time the script runs, it must log a new entry to the SHA256 file containing the SHA-256 hash of the script, marked appropriately so as to be distinguished from student submissions.

Edit: Add bullets @zakkak

A bypass for the maxturnins argument on LIMITS file has been found possible under certain conditions.
More specifically, a user that has initiated a turnin that is legal in terms of quota can finalise the submission even if the course changes the maxturnins during the process of submission.
Steps to reproduce:

1. Run turnin assignment@course file.c as user and finalise the turn in
2. Run turnin assignment@course file.c as user and wait before pressing the final y.
3. Run echo "maxturnins 1" > ~/TURNIN/assignment/LIMITSas course.
4. Press y as user on the second turnin.

Abuse of this race condition is detectable through the LOGFILE and SHA256 since it marks the submission sequentially, even if it's over the maximum allowed limit.

It has been observed that the binary turnin(1) and more specifically turnin v2.3.1-2 under unknown conditions consumes 100% of the CPU and the process hangs forever.

For each turn in, the binary keeps the group of the file set as the one of the user who turned in the file.

turnin ex1@cs999 myfile.c | yes results in an infinite loop, while it should just accept the first y and exit.

Due to the changes happening usually in the way we compress (and therefore decompress) files, I recommend turnin to create a bash(1) script that accepts one argument, the username and decompresses the file in the proper directory.
Example:
check user9999
And:

#!/bin/bash
mkdir $1 2> /dev/null > /dev/null
tar <args> $1 -C ./$1/
echo "Decompressed $1 to ./$1"

A bypass has been found that allows a malicious user to avoid checks for absolute paths in the files turned it..
Calling turnin with the following bash(1) command can result in bypass of the check:

turnin assign@class `printf "a\b/etc/passwd"`

When running turnin_extract, all files are decompressed into folders with default permissions (755 on most systems). Additionally, the files inside are (by default) deployed as 744. This can cause users to be able to read extracted assignments if the assignment and/or TURNIN folder have a weak permission set.
This may not be the expected behavior, so either warn the instructors / TAs or run the proper chmod(1)'s.

We could add support to turnin(1) for late submissions that will notify the student the assignment is due but he can still turn in with a small penalty on the final grade. For example, add file DUE when the assignment is due and from that point on alert all users turning in that n days have passed since that and there will be let's say n*10 % penalty on the final grade. The LOCK file shall close the turnin just as it does now.

Tests of turnin(1) under "heavy" load have been completed. More specifically, the following bash(1) command was issued to a debian computer:

while [ true ]; do printf "y\ny" | turnin assignment@course file.c & done

Although it is extremely unlikely that such a case will happen in a production environment, the whole purpose was to simulate race conditions, i.e. how turnin(1) handles submissions by users simultaneously.
Parts of the LOGFILE and the SHA256 files can be seen below:

LOGFILE

turnin 2.0: student -  1 09/21/14 15:07   1
turnin 2.0: student -  2 09/21/14 15:07   1
turnin 2.0: student -  2 09/21/14 15:07   1
turnin 2.0: student -  2 09/21/14 15:07   1
turnin 2.0: student -  2 09/21/14 15:07   1
turnin 2.0: student -  2 09/21/14 15:07   1
turnin 2.0: student -  2 09/21/14 15:07   1
turnin 2.0: student -  2 09/21/14 15:07   1
turnin 2.0: student -  2 09/21/14 15:07   1
turnin 2.0: student -  3 09/21/14 15:07   1
turnin 2.0: student -  4 09/21/14 15:07   1

turnin 2.0: student -  6 09/21/14 15:07   1
turnin 2.0: student -  6 09/21/14 15:07   1
turnin 2.0: student -  7 09/21/14 15:07   1
turnin 2.0: student -  6 09/21/14 15:07   1
turnin 2.0: student -  6 09/21/14 15:07   1

SHA256

4a28ddd1770703177a9e2dafd1e9a3aea3de53723e39d539de8358fff25d0afb  student-4.tgz
4a28ddd1770703177a9e2dafd1e9a3aea3de53723e39d539de8358fff25d0afb  student-5.tgz
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  student-6.tgz
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  student-18.tgz
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  student-18.tgz
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  student-6.tgz
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  student-18.tgz