0

I am facing a strange problem over a fairly simple piece of code. The relevant portion of the code is given below:

void foo(int32 in_sd_id, int32 out_sd_id)
{
    int32 nsds;                     /* number of data sets in the file */
    int32 nattr;                    /* number of global attributes in the file */
    int32 attr_cnt;                 /* count of number of attribute */
    int32 attr_index;               /* attribute index */
    int32 attr_type, attr_size;     /* attribute type and size */
    char attr_name[40];  



    ret = SDfileinfo(in_sd_id, &nsds, &nattr);
    printf("nattr is %d\n", nattr);
    /* test to see if num_datasets and num_global_attr can be retrieved from in_sd_id */
    if (ret == -1)
        {
        fprintf(stdout, "cannot read information from input file \n");
        exit(EXIT_FAILURE);
        }
    else
        {
        /* loop through each global attributes */
        for (attr_index=0; attr_index<nattr; attr_index++)
        {
            printf("attr_index:nattr is %d:%d\n", attr_index, nattr);
            /* test to see if the file or dataset do indeed contain attributes */
            if (SDattrinfo(in_sd_id, attr_index, attr_name, &attr_type, &attr_cnt) == FAIL)
            fprintf(stdout, "Cannot read information for attribute %d\n", attr_index);
            else
            {
                DO SOMETHING 
            }
        }
    }
}

The problem is with the nattr variable. Say for example nattr should be 11, within the for loop when i print the value of nattr, I get it as 11 for sometime but then suddenly it blows up to a huger number like 1869501279. I am not doing anything else with this nattr variable in the rest of the code. I have double and tripe checked that. So I am not sure why its blowing up suddenly. The debug statement from one sample run is given below:

nattr is 11
attr_index:nattr is 0:11
attr_index:nattr is 1:11
attr_index:nattr is 2:11
attr_index:nattr is 3:11
attr_index:nattr is 4:11
attr_index:nattr is 5:11
attr_index:nattr is 6:11
attr_index:nattr is 7:11
attr_index:nattr is 8:1869501279
attr_index:nattr is 9:1850957672
attr_index:nattr is 10:1850957672
attr_index:nattr is 11:1850957672
Cannot read information for attribute 11
attr_index:nattr is 12:1850957672
Cannot read information for attribute 12
attr_index:nattr is 13:1850957672

Any help as to what may be going on here. Thanks

David C. Rankin
  • 81,885
  • 6
  • 58
  • 85
srsci
  • 239
  • 5
  • 10
  • 11
    You (very) probably have a buffer overflow. I'd bet you are trying to write to `attr_name` to indexes greater than 39. – pmg Aug 27 '14 at 14:28
  • Great!! awesome **Piotr S** and **pmg**. Setting the `attr_name` array to a higher size fixed it. Thanks learned something new. – srsci Aug 27 '14 at 14:31
  • The relevant portion of the code is insufficient. Add the `SDfileinfo` function, as well as the `DO SOMETHING` section to your post. – barak manos Aug 27 '14 at 14:32
  • 4
    It didn't fix it! **Your solution masked the problem!** Find where you were trying to write beyond the end of the array and correct that *(of course, the solution may be, in fact, increasing the size of the array)* – pmg Aug 27 '14 at 14:33
  • 1
    @pmg it appears the root of this is from a horridly documented (and I can only imagine equally implemented) library api, [**see here**](http://www.sv.vt.edu/classes/ESM4714/Gen_Prin/data_org/HDF/RM41r2b_HTML/RM_Section_II_SDLOP.fm.html). What fiend writes an API that takes a fixed buffer to fill *without* a limiting length paramter these days? (lemme guess, they used `gets()` for their example code). – WhozCraig Aug 27 '14 at 14:35
  • @pmg go ahead and write it up as the answer so that poster can select it. – David C. Rankin Aug 27 '14 at 14:35
  • Why the down vote? I thought this problem is very genuine one and specially someone who has some moderate experience like myself. Anyone care to explain please? – srsci Aug 27 '14 at 15:06
  • @srsci I don't understand either. Its a poor api, and though "make the buffer bigger" seems like an obvious work-around, it isn't until the api was investigated that it was exposed as really the *only* work-around (short of using a better library without such vulnerabilities). Have an up-tick. – WhozCraig Aug 27 '14 at 15:41

1 Answers1

5

You (very) probably have a buffer overflow. I'd bet you are trying to write to attr_name to indexes greater than 39.

But don't just increase the size of attr_name. You need to understand what you are doing in the // DO SOMETHING code.

pmg
  • 106,608
  • 13
  • 126
  • 198
  • I am not doing anything else with `attr_name` in the rest of the code in anyway that can possibly write to it beyond its limit. That call to `SDattrinfo` is the only place where it is being set. Also I have no other way of knowing a size so that I can set that `attr_name` dynamically other than just going by a pre-determined size. – srsci Aug 27 '14 at 14:47
  • Looks like increasing the size of the array is the usable solution. The page linked to by @WhozCraig has a timestamp of "Wednesday, July 29, 1998 20:31:40"; maybe you can find a more recent library :) – pmg Aug 27 '14 at 15:01
  • There is no other function API provided that can be used to get an idea of the size of the `attr_name` hence other than a fixed buffer I dont know what to do!! – srsci Aug 27 '14 at 15:04
  • @srsci that should be an indicator the API has potential security flaws and should be investigated for either updates or alternatives. For now, its what you have so this is likely your only alternative without said-updates/alternates. (+1 btw, pmg). – WhozCraig Aug 27 '14 at 15:42
  • +1 Agree about over-writing text data into `nattr`. Note: `1869501279` --> "_Sno" and `1850957672` --> "h_Sn" – chux - Reinstate Monica Aug 27 '14 at 17:45