Backup tool?

[John]

Daniel Robitaille wrote:
>>I took a look at Mondo a couple of years ago when I was looking fora
>>general purpose backup tool.
>>
>>Its specs are terrific, and I like the fact it uses afio (also a greate
>>little archiver).
>>
>>However, the code back then was full of security holes, it regularly
>>uses the system() function without checking the input.
>>
> 
> 
> Mondo is currently both in Ubuntu's universe and in Debian.  On purely
> theoretical point of view, if a package was so bad from a security
> point of view, and if the upstream author(s) wasn't interested in
> their resolution, could it lead the package to be totally dropped from
> Debian/Ubuntu simply due to it's unsafe condition.
> 
> Personally I'm only an end-user and I don't have the technical
> knowledge to read the C source code of a package like this one, and
> judge for myself if it's still good or bad now compared to John's
> experience a few years back. So I depend on knowledgable people who
> will do (have done?) the auditing exercise and make sure the current
> package that I can very easily install from Ubuntu's universe is safe,
> or at least safer than before.
> 


I've taken some time to download and inspect 2.03.1 on Sarge.

I learned my programming many years ago, on IBM mainframs and (briefly 
before that CDC mainframes).

I used to be able to program in Fortran (I discovered in 1990 that I'd 
forgotten it), COBOL and I can probably pass myself off as a PL/1 
programmer even now.

I learned Fortran and COBOL (and COMPASS) before C was invented.

I was also a pretty handy S/370 assembler programmer, taught (and used 
and demonstrated) Natural. Natural is the HLL companion to Adabas which 
was very popular in Canberra in the 80s.

I mention these so you will know I'm no PFY talking through his 
back-to-front baseball cap.

Amongst other things, I've learned that code should be written to be 
understood by people. A program that doesn't work is of limited value, 
and if the code is easy to understand then bugs are less likely, and 
more easily fixed.

A good general-purpose programming language helps the programmer write 
good programs by checking that they're not doing something silly. It 
provides constructs to do things safely. For example, PL/1, Pascal and 
even COBOL explicitly recongise string datatypes and provide sensible 
constructs to handle them.

C doesn't do those things, and so I'm not interested in becoming 
particularly proficient in it.

The inventors of lint recognised its deficiencies and so developed a 
bandaid to cover them over:-)

If you think I've gone bananas, before you put that in writing, read this:
http://www.dwheeler.com/secure-programs/

David has researched the matter, I merely am doubtful, suspcious, even 
paranoid. But I'm no expert in this stuff. David is.

I'm looking at mondo-2.03.1/mondo/mondoarchive/main.c


I'm numbering statements with the cat command for any who want to check 
my assertions.

This is right at the start of the code:
    241  /* Make sure I'm root; abort if not */
    242    if (getuid () != 0)
    243      {
    244        fprintf (stderr, "Please run as root.\r\n");
    245        exit (127);
    246      }

Gotta be root. All the better to stuff things up.

This before it even reports --version.





I can't say that the code in Mondo even now is clearly right. Take this:
    448        if (res<0)
    449          {
    450            sprintf(tmp, "%d difference%c found.", -res, (-res != 
1) ? 's' : ' ');
    451            strcat(say_at_end, tmp);
    452            log_to_screen(tmp);
    453            res=0;
    454          }

strcat is one of those functions that lead to buffer overruns so 
readily, causing SEGV errors and worse. There is a companion function, 
strncat(), which does a built-in length check.

the code is not clearly correct, not even especially easy to check that 
it is in fact safe.

Here is an excellent description of why buffer overruns are bad:
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/buffer-overflow.html




I'm not going to spend much time on this. here are som common C 
functions I believe inherently unsafe because they rely on strings not 
being too long, and which are used in mondo:
strcat()
strstr()
sprintf()
strcpy()
strchr()

I'm not looking at mondo-2.03.1/mondo/mondoarchive/mondo-cli.c


I think this is where I found the segv those years ago. It's not so 
clear to me now as it was then that this code can be made to segv, but 
it might. It uses strcpy() and sprintf() without, as far as I can see, 
checking lengths.


Tell me I'm wrong:
    970            else
    971              {
    972                flag_set[opt] = TRUE;
    973                if (optarg)
    974                  {
    975                    len = strlen(optarg);
    976                    if (optarg[0] != '/' && optarg[len-1] == '/')
    977                      {
    978                        optarg[--len] = '\0';
    979                        log_to_screen("Warning - param '%s' 
should not have trailing slash!", optarg);
    980                      }
    981                    if (opt=='d')
    982                      {
    983                        if (strchr(flag_val[opt], '/') && 
flag_val[opt][0]!='/')
    984                          {
    985                            sprintf(tmp, "-%c flag --- must be 
absolute path --- '%s' isn't absolute", opt, flag_val[opt]);
    986                            log_to_screen(tmp);
    987                            bad_switches = TRUE;
    988                          }
    989                      }
    990                    strcpy(flag_val[opt], optarg);
    991                  }


Aren't those references to flag_val[opt] on lines 983 & 985 wrong?

Enough already. I won't be installing this.
rm -rf mondo*


Whoops, too soon. It uses temporary files insecurely. Look for 
/tmp/changes.list.

It creates work files in /root (where there might not be enough space)


I think this would be an excellent exercise for some college students. 
Read David's book at http://www.dwheeler.com/secure-programs/ so as to 
know what you're doing, then go over the code picking all the faults you 
can find and fixing them. Or if not fixing them, see whi can report most 
bugs to the Ubuntu bugzilla:-)



Me, I'll use something else. I don't trust that code.