View Issue Details

IDProjectCategoryView StatusLast Update
0002743GNUnetfile-sharing servicepublic2013-02-05 20:42
ReporterLRN Assigned ToChristian Grothoff Due Date
PrioritylowSeveritytweakReproducibilityN/A
Status closedResolutionfixed 
Product VersionGit master 
Target Version0.9.5aFixed in Version0.9.5a 
Summary0002743: Possible buffer overflow in GNUNET_FS_publish_sks
DescriptionGNUNET_FS_publish_sks() does this:
  slen = strlen (uris) + 1;
  idlen = strlen (identifier);
  if (NULL != update)
    nidlen = strlen (update) + 1;
  else
    nidlen = 1;
  mdsize = GNUNET_CONTAINER_meta_data_get_serialized_size (mmeta);
  size = sizeof (struct SBlock) + slen + nidlen + mdsize;
  if (size > MAX_SBLOCK_SIZE)
  {
    size = MAX_SBLOCK_SIZE;
    mdsize = size - (sizeof (struct SBlock) + slen + nidlen);
  }
  sb = GNUNET_malloc (sizeof (struct SBlock) + size);
  dest = (char *) &sb[1];
  if (update != NULL)
    memcpy (dest, update, nidlen);
  else
    memset (dest, 0, 1);

If size > MAX_SBLOCK_SIZE, mdsize is recalculated to occupy the space it can get after update identifier is stored in the block.
The code then allocates the block, then copies update identifier into it.
The code never checks that update identifier fits into the block.

Should we put a limit on update identifier's length?
Should we allow an SBlock with 0-length metadata (the rest is occupied by the update identifier) to be published?
TagsNo tags attached.

Activities

Christian Grothoff

2013-01-24 10:53

manager   ~0006792

No, we should not limit identifiers IMO, but we do need to check for the buffer overflow (even though fortunately I see no way to exploit this, as the user can only provoke this on his own system, within processes he starts himself). Fixed in SVN 25874.

Issue History

Date ModifiedUsernameFieldChange
2013-01-23 19:31LRNNew Issue
2013-01-24 10:52Christian GrothoffAssigned To => Christian Grothoff
2013-01-24 10:52Christian GrothoffStatusnew => assigned
2013-01-24 10:53Christian GrothoffNote Added: 0006792
2013-01-24 10:53Christian GrothoffStatusassigned => resolved
2013-01-24 10:53Christian GrothoffFixed in Version => 0.10.0
2013-01-24 10:53Christian GrothoffResolutionopen => fixed
2013-01-24 10:53Christian GrothoffProduct Version => Git master
2013-01-24 10:53Christian GrothoffTarget Version => 0.10.0
2013-02-05 20:40Christian GrothoffFixed in Version0.10.0 => 0.9.5a
2013-02-05 20:40Christian GrothoffTarget Version0.10.0 => 0.9.5a
2013-02-05 20:42Christian GrothoffStatusresolved => closed