我试图弄清楚这是否会以某种方式溢出答案

【问题标题】：I'm trying to figure out if this could somehow be overflowed我试图弄清楚这是否会以某种方式溢出
【发布时间】：2021-03-08 13:42:07
【问题描述】：

希望您有愉快的一天；所以我有以下代码，我想知道它是否会在某些时候以某种方式溢出::

static void * myalloc(size_t len) {
    void * p = malloc(len);
    if (p == NULL) {
        fprintf(stderr, "end of memory\n");
        exit(1);
    }
    return p;
}

static void * copy_buf(void * buf, uint32_t count, uint32_t be) {
    uint32_t * p = NULL;
    if (buf != NULL) {
        p = myalloc(count * 4);
        memcpy(p, buf, count * 4);
     }  
// more code
  return p;
}

如果它没有溢出，是否会有其他原因导致它溢出，我的意思是如果变量发生了变化。或者参数改变了（当然不是数据类型，而是它们的值）这个问题看起来像memcpy overflow boundary exploit? (smashing the stack) 所以我希望它得到同样的反应:)

感谢您的帮助，完整的源代码要大得多（超过一个文件，每个文件超过 2000 行代码），但这是我关心的部分之一......

祝你有美好的一天。

【问题讨论】：

@Bodo 什么值会导致这种情况......我不是一个优秀的 c 程序员，还没有进入安全编程领域，这是我的第一个大学项目，遗憾的是他们没有想要里面有错误！

标签： c overflow buffer-overflow integer-overflow

【解决方案1】：

copy_buf(buf, count, be) 假定count 是buf 指向的uint32_t 的编号。在这种情况下，下面会更好。

// static void * copy_buf(void * buf, uint32_t count, uint32_t be)
static void * copy_buf(uint32_t * buf, uint32_t count, uint32_t be)

如果 OP 使用count 作为buf 指向的对象的大小，那么代码缩放 4 是错误的，可能会导致“溢出”。

另请参阅@Bodo，了解阅读过多。

至少在 2 种情况下可能出现“溢出”。由于都处理极端值，我不认为查看 OP 代码的这一小部分是 OP 的困境，但这里有一些“溢出”发生的方式：

size_t 比 uint32_t 窄

产品count * 4（uint32_t）到size_t 的转换可能不适合size_t 范围并导致错误的大小分配。

size_t 与uint32_t 相同或更大的范围

产品count * 4 超出uint32_t 范围并在分配给size_t 之前溢出。

显示改进的代码：

使用常见的尺寸类型。

OP 的copy_buf(buf, 0, 123) 不是溢出问题，但可能导致代码退出，即使内存充足。测试 0。

static void *myalloc(size_t len) {
  void * p = malloc(len);
  if (p == NULL && len > 0) {
    fprintf(stderr, "end of memory\n");
    exit(1);
  }
  return p;
}

static void *copy_buf(const void * buf, size_t count) {
  uint32_t * p = NULL;
  if (buf != NULL) {
    if (count > SIZEMAX/sizeof *p) {
      fprintf(stderr, "count too big\n");
      exit(1);
    }
    p = myalloc(sizeof *p * count);
    memcpy(p, buf, sizeof *p * count);
  }  
  // more code
  return p;
}

【讨论】：

感谢您的详细解释……但正如我所说，我不擅长安全编程之类的事情，而且我的代码在运行时没有导致溢出，我很好奇，因为我知道内存操作（复制......）是造成一些大错误的原因......我实际上并没有理解你发布的所有内容（尽管我真的很感激）但是攻击者可以利用我的代码吗？怎么样！？
@muhammadAli 漏洞利用：1) 使用count == 0 强制exit()。 2) 使用count > SIZEMAX/4 分配不足而没有溢出检测。 3) 使用buf == NULL 可能会导致// more code 出现问题。
恕我直言，我不 git 它，我需要知道我的代码是否容易受到缓冲区溢出的影响
@muhammadAli 是的，它容易受到缓冲区溢出的影响。对不起，如果我的解释不够清楚。
不，我太愚蠢了，无法理解，感谢您的帮助...如果此代码易受攻击，那么我肯定会遇到另一个易受攻击的代码...但是因为我不能在这篇文章之后发布 3 天，我会等待?

【解决方案2】：

当你在代码中传播的几个4s 是真的4s 时它不会溢出。让我解释一下自己：

问题在于您假设某些数据类型是 4 个字节宽，这是无法假设的。一个更好的选择应该是把它写成sizeof (SOME_TYPE)，或者更好的写成sizeof SOME_VARIABLE。在最后一种情况下，如果您更改数组的类型或元素数量，则没有问题，因为 sizeof 运算符会处理它。但是正如您刚刚写的4，代码不仅无法理解，而且无法阅读。指定您经常使用的 4 是什么，然后您将拥有干净、可读且不会溢出的危险代码。

可能的解决方法：将4 更改为sizeof (uint32_t)，或者更好的是，将其更改为sizeof *p，这是您要乘以count 的值的对象的大小.

【讨论】：