Absent Member.
Absent Member.
5289 views

Buffer Overflow: Format String

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

0 Likes
9 Replies
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

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.

0 Likes
Absent Member.
Absent Member.

Hi Mark,

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

Thanks much!

Doug

0 Likes
Absent Member.
Absent Member.

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

0 Likes
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

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.

0 Likes
Absent Member.
Absent Member.

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!

0 Likes
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

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

0 Likes
Absent Member.
Absent Member.

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!

0 Likes
Absent Member.
Absent Member.

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

0 Likes
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

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.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.