[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #DOY-885966]: [PATCH] Vulnerability & fix in nc_inq_attname(), nc_inq_dimname() and nc_inq_varname(), and in nccopy.c/dumplib.c

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [netCDF #DOY-885966]: [PATCH] Vulnerability & fix in nc_inq_attname(), nc_inq_dimname() and nc_inq_varname(), and in nccopy.c/dumplib.c
  • Date: Fri, 04 Dec 2015 14:46:03 -0700
Hi Evan,

Thanks for the bug/issue report and the patch, and my apologies for the delay 
in responding to you.  We are a small development team and we have been busy 
preparing for upcoming conferences as well as other bug fixes.  

I'll review this as soon as I can, although it might not be until after the AGU 
conference being held the week after next.  For your reference, please feel 
free to submit patches/etc through pull requests on GitHub, if you like in the 
future.  We do not coordinate with any of the binary releases that we do not 
directly create, e.g. the Windows C library releases.

Thanks again, and once again my apologies for the delayed response!

-Ward


> Le lundi 30 novembre 2015 00:31:40, Even Rouault a écrit :
> > Hi,
> >
> > This one is in the denial of service category. It can cause excessive &
> > slow memory allocation, and eventually assert()ion. Can be tested on the
> > attached file where the string length has been set to 2147483647.
> 
> Hi
> 
> Let me know if/how you follow up with those reports.
> 
> Best regards,
> 
> Even
> 
> >
> > Best regards,
> >
> > Even
> >
> > > Hi,
> > >
> > > The commit messages in the attached patches (against latest master)
> > > should tell everything. This issue affects as far as I can see all
> > > netCDF releases. I've also attached a file crafted to trigger the issue.
> > > I just compiled a version of netCDF with #define NC_MAX_NAME (256*2+1)
> > > to generate it with ncgen on the attached test.nc.txt
> > >
> > > On a unmodified version, ncdump will segfault on it due to the buffer
> > > overflow.
> > >
> > > With the changes, it will error out cleanly:
> > > $ install/bin/ncdump /home/even/gdal/svn/trunk/gdal/test.nc
> > > netcdf test {
> > > dimensions:
> > > NetCDF: NC_MAX_NAME exceeded
> > > Location: file /home/even/tmp/netcdf-c/ncdump/ncdump.c; line 1532
> > >
> > > I prefered dealing with this through email rather than a public pull
> > > request in case you want to coordinate with binary distributions, etc...
> > >
> > > Best regards,
> > >
> > > Even
> 
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> 
> 


Ticket Details
===================
Ticket ID: DOY-885966
Department: Support netCDF
Priority: Normal
Status: Closed