unmunge not failing on an altered credential

[cvizino]

If a munge credential is altered in any way, shouldn't the decode fail?

munge(7) says:

The integrity of the credential is ensured by a message authentication code (MAC).

However, with this reproducer it's easy to see where this is not always the case.

$ cat test_unmunge_fail.sh
#!/bin/bash
#
# unmunge failure test
#

for i in {1..3000}; do
        # generate munge credential string
        m_cred=$(echo ""|munge)

        # alter the 3rd char from end
        len=${#m_cred}
        target_offset=$(expr $len - 3)
        target_offset_char=${m_cred:$target_offset:1}
        prefix=${m_cred:0:$target_offset}
        suffix=${m_cred:$(($target_offset+1))}
        if [ $target_offset_char = A ]; then
                new_char=B
        else
                new_char=A
        fi
        new_m_cred=${prefix}${new_char}${suffix}

        # try to unmunge the altered string
        unmunge_out=$(echo $new_m_cred|unmunge 2>&1)

        # if unmunge does not fail there is a problem
        if [ $? -eq 0 ]; then
                echo Failure in iteration $i -- unmunge should not have succeeded
                echo Altered char at offset $target_offset: old $target_offset_char new $new_char
                echo Original credential string: $m_cred
                echo Altered  credential string: $new_m_cred
                echo unmunge returned: $unmunge_out
                break
        fi
done

Here's the run:

> $ unmunge --version
> munge-0.5.14 (2020-01-14)
> $ ./test_unmunge_fail.sh
> Failure in iteration 22 -- unmunge should not have succeeded
> Altered char at offset 140: old A new B
> Original credential string: MUNGE:AwQFAAC8WZx6neJTmxOsCQwe7FK7tmYlqs2+LwqzxENijZgJeHLVT0ruA78o6Bvc6GHCXg0blzSoqdY6c6N9OHkoYeUHZBF+PlmeFK9ymhjsGjmuww3uyDfcqDkLl6Qgt9RTFUA=:
> Altered credential string: MUNGE:AwQFAAC8WZx6neJTmxOsCQwe7FK7tmYlqs2+LwqzxENijZgJeHLVT0ruA78o6Bvc6GHCXg0blzSoqdY6c6N9OHkoYeUHZBF+PlmeFK9ymhjsGjmuww3uyDfcqDkLl6Qgt9RTFUB=:
> unmunge returned: STATUS: Success (0) ...

Offset 140 is probably in the payload section of the credential but it still seems wrong that the decode should succeed when the credential has been altered.

[dun]

Thanks for the reproducer! I'll try to take a close look at this next week.

[cvizino]

No need to look into this--it's a side effect of the base64 encoding. For certain base64 encodings, there can actually be four ways to represent the same binary data. This is due to the base64 encoding not aligning perfectly to the input buffer. Changing the base64 string does not alter or affect the underlying datastructures at all. So, what I raised is a non-issue and certainly not a security one.