Buffer Overflow: Format String

[doug_ferrin]

Could someone please tell me why I get a Fortify SCA Buffer Overflow error on the following c code?

Abstract:

The format string argument to fscanf() at test_cfg.c line 25 does not properly limit the

amount of data the function can write, which allows the program to write outside the

bounds of allocated memory. This behavior could corrupt data, crash the program, or

lead to the execution of malicious code

main()

{

int n;
char path[1024];
int64_t start = 0;
int64_t length = 0;
FILE *fp=NULL;

        fp = fopen("test.aux", "rb");
        if(fp == NULL) exit(1);

        n = fscanf(fp,"%s %lld %lld", path, &start, &length); <======== BUffer Overflow Error
        printf("n = %d path = %s start = %lld length = %lld\n",n,path, start, length);
        fclose(fp);

}

I'm running SCA 4.40 on a Solaris Sparc station.

If anyone has any ideas I'm all ears.

Thank You!

Doug

[mfeferman]

Hi Doug -

Why don't you limit the size of the amount of data that can be read into the path variable.

Something like:

n = fscanf(fp,"%1023s %lld %lld", path, &start, &length);

I ran both through SCA (v16.10) and my fix removed the issue being found.

[doug_ferrin]

Hi Mark,

ok that did eliminate it in my test code. I'll try it in the main code base.

Thanks much!

Doug

[doug_ferrin]

However the exact same change, just adding the %1023s, in the main code base raised it from a high to a critical issue. In my test code it was eliminated.

So I'm worse off than before. I'm running 4.4 by the by.

I'll have to reverse the change and live with a "high" issue for now.

Doug

[mfeferman]

Going from High to Critical makes no sense, especially given the sample code fix.  Is the vulnerability message the same?  Assuming it is, I'm guessing the confidence level went up.  I'll think about possibilities and get back to this thread.

[doug_ferrin]

It really doesn't make much sense. Unless Fortify didn't like something in the path leading up to it.

Fortify is not fun to wrestle with.

Let me know if you have any ideas.

Thanks Mark!

[mfeferman]

Doug -

I'm sorry, I replied to the main thread.  I asked if that 'printf' statement was actually used in the real code?  If so, maybe that's an issue.  If you'd like and you're able, I'm happy to look at a little bigger chunk of the code.

Regards,

Mark

[doug_ferrin]

The printf is not in there. I'm going to try and eliminate the %lld 's . There is no reason for them to be using 64 bit longwords.

Thanks Mark!

[doug_ferrin]

One other question I had was how to successfully create a "whitelist". We have a configuration file that the program reads and acts on. It maybe directory names, or values to control operation. I have yet to figure out what Fortify is looking for. I made a whitelist with only and only one directory in it and then matched it in the configuration file. And Fortify still flagged it as a Path Manipulation Error.

So I'm not sure what Fortify is looking for.

Thanks again!

Doug

[mfeferman]

Regarding this 'whitelist' you are using, I think Fortify is flagging it as a possible place to exploit, if someone can modify that external file, but in actuality, it very well could be a false positive.   Sorry for my delayed response.