Bugzilla

On second look, we have volume with versions prior to 141, even for the startup crash variation for which the first reports are around . And it's not *only* Avast, although Avast is the biggest correlation. The offending code is the following:

```

  // Reserve a full 64k memory range in the child process.
  HANDLE child = child_->Process();
  BYTE* thunk_base = reinterpret_cast<BYTE*>(::VirtualAllocEx(
      child, nullptr, kAllocGranularity, MEM_RESERVE, PAGE_NOACCESS));

  // Find an aligned, random location within the reserved range.
  size_t thunk_bytes =
      interceptions_.size() * sizeof(ThunkData) + sizeof(DllInterceptionData);
  size_t thunk_offset = internal::GetGranularAlignedRandomOffset(thunk_bytes);

  // Split the base and offset along page boundaries.
  thunk_base += thunk_offset & ~(kPageSize - 1);
  thunk_offset &= kPageSize - 1;

  // Make an aligned, padded allocation, and move the pointer to our chunk.
  size_t thunk_bytes_padded = base::bits::AlignUp(thunk_bytes, kPageSize);
  thunk_base = reinterpret_cast<BYTE*>(
      ::VirtualAllocEx(child, thunk_base, thunk_bytes_padded, MEM_COMMIT,
                       PAGE_EXECUTE_READWRITE));
  CHECK(thunk_base);  // If this fails we'd crash anyway on an invalid access.
```

It could be that Avast (and other AV products) has heuristics that block remote RWX allocations. We could try using a file mapping mapped RW in the parent and RX in the child and see if that fixes the issue.

So far I haven't been able to reproduce with the free version of Avast without official starting the trial (i.e. I have not entered credit card info yet), maybe I don't have all features enabled although injection does happen.

On second look, we have volume with versions prior to 141, even for the startup crash variation, the volume just seems to have exploded around the release of 141. And it's not *only* Avast, although Avast is the biggest correlation. The offending code is the following:

```

  // Reserve a full 64k memory range in the child process.
  HANDLE child = child_->Process();
  BYTE* thunk_base = reinterpret_cast<BYTE*>(::VirtualAllocEx(
      child, nullptr, kAllocGranularity, MEM_RESERVE, PAGE_NOACCESS));

  // Find an aligned, random location within the reserved range.
  size_t thunk_bytes =
      interceptions_.size() * sizeof(ThunkData) + sizeof(DllInterceptionData);
  size_t thunk_offset = internal::GetGranularAlignedRandomOffset(thunk_bytes);

  // Split the base and offset along page boundaries.
  thunk_base += thunk_offset & ~(kPageSize - 1);
  thunk_offset &= kPageSize - 1;

  // Make an aligned, padded allocation, and move the pointer to our chunk.
  size_t thunk_bytes_padded = base::bits::AlignUp(thunk_bytes, kPageSize);
  thunk_base = reinterpret_cast<BYTE*>(
      ::VirtualAllocEx(child, thunk_base, thunk_bytes_padded, MEM_COMMIT,
                       PAGE_EXECUTE_READWRITE));
  CHECK(thunk_base);  // If this fails we'd crash anyway on an invalid access.
```

It could be that Avast (and other AV products) has heuristics that block remote RWX allocations. We could try using a file mapping mapped RW in the parent and RX in the child and see if that fixes the issue.

So far I haven't been able to reproduce with the free version of Avast without official starting the trial (i.e. I have not entered credit card info yet), maybe I don't have all features enabled although injection does happen.

On second look, we have volume with versions prior to 141, even for the startup crash variation, the volume just seems to have exploded around the release of 141. And it's not *only* Avast, although Avast is the biggest correlation. The offending code is the following in `security/sandbox/chromium/sandbox/win/src/interception.cc`:

```c++
  // Reserve a full 64k memory range in the child process.
  HANDLE child = child_->Process();
  BYTE* thunk_base = reinterpret_cast<BYTE*>(::VirtualAllocEx(
      child, nullptr, kAllocGranularity, MEM_RESERVE, PAGE_NOACCESS));

  // Find an aligned, random location within the reserved range.
  size_t thunk_bytes =
      interceptions_.size() * sizeof(ThunkData) + sizeof(DllInterceptionData);
  size_t thunk_offset = internal::GetGranularAlignedRandomOffset(thunk_bytes);

  // Split the base and offset along page boundaries.
  thunk_base += thunk_offset & ~(kPageSize - 1);
  thunk_offset &= kPageSize - 1;

  // Make an aligned, padded allocation, and move the pointer to our chunk.
  size_t thunk_bytes_padded = base::bits::AlignUp(thunk_bytes, kPageSize);
  thunk_base = reinterpret_cast<BYTE*>(
      ::VirtualAllocEx(child, thunk_base, thunk_bytes_padded, MEM_COMMIT,
                       PAGE_EXECUTE_READWRITE));
  CHECK(thunk_base);  // If this fails we'd crash anyway on an invalid access.
```

It could be that Avast (and other AV products) has heuristics that block remote RWX allocations. We could try using a file mapping mapped RW in the parent and RX in the child and see if that fixes the issue.

So far I haven't been able to reproduce with the free version of Avast without official starting the trial (i.e. I have not entered credit card info yet), maybe I don't have all features enabled although injection does happen.

On second look, we have volume with versions prior to 141, even for the startup crash variation, the volume just seems to have exploded around the release of 141. And it's not *only* Avast, although Avast is the biggest correlation. The offending code is the `CHECK` in `security/sandbox/chromium/sandbox/win/src/interception.cc`:

```c++
  // Reserve a full 64k memory range in the child process.
  HANDLE child = child_->Process();
  BYTE* thunk_base = reinterpret_cast<BYTE*>(::VirtualAllocEx(
      child, nullptr, kAllocGranularity, MEM_RESERVE, PAGE_NOACCESS));

  // Find an aligned, random location within the reserved range.
  size_t thunk_bytes =
      interceptions_.size() * sizeof(ThunkData) + sizeof(DllInterceptionData);
  size_t thunk_offset = internal::GetGranularAlignedRandomOffset(thunk_bytes);

  // Split the base and offset along page boundaries.
  thunk_base += thunk_offset & ~(kPageSize - 1);
  thunk_offset &= kPageSize - 1;

  // Make an aligned, padded allocation, and move the pointer to our chunk.
  size_t thunk_bytes_padded = base::bits::AlignUp(thunk_bytes, kPageSize);
  thunk_base = reinterpret_cast<BYTE*>(
      ::VirtualAllocEx(child, thunk_base, thunk_bytes_padded, MEM_COMMIT,
                       PAGE_EXECUTE_READWRITE));
  CHECK(thunk_base);  // If this fails we'd crash anyway on an invalid access.
```

It could be that Avast (and other AV products) has heuristics that block remote RWX allocations. We could try using a file mapping mapped RW in the parent and RX in the child and see if that fixes the issue.

So far I haven't been able to reproduce with the free version of Avast without official starting the trial (i.e. I have not entered credit card info yet), maybe I don't have all features enabled although injection does happen.

On second look, we have volume with versions prior to 141, even for the startup crash variation, the volume just seems to have exploded around the release of 141. And it's not *only* Avast, although Avast is the biggest correlation. The offending code is the `CHECK` in `security/sandbox/chromium/sandbox/win/src/interception.cc`:

```c++
  // Reserve a full 64k memory range in the child process.
  HANDLE child = child_->Process();
  BYTE* thunk_base = reinterpret_cast<BYTE*>(::VirtualAllocEx(
      child, nullptr, kAllocGranularity, MEM_RESERVE, PAGE_NOACCESS));

  // Find an aligned, random location within the reserved range.
  size_t thunk_bytes =
      interceptions_.size() * sizeof(ThunkData) + sizeof(DllInterceptionData);
  size_t thunk_offset = internal::GetGranularAlignedRandomOffset(thunk_bytes);

  // Split the base and offset along page boundaries.
  thunk_base += thunk_offset & ~(kPageSize - 1);
  thunk_offset &= kPageSize - 1;

  // Make an aligned, padded allocation, and move the pointer to our chunk.
  size_t thunk_bytes_padded = base::bits::AlignUp(thunk_bytes, kPageSize);
  thunk_base = reinterpret_cast<BYTE*>(
      ::VirtualAllocEx(child, thunk_base, thunk_bytes_padded, MEM_COMMIT,
                       PAGE_EXECUTE_READWRITE));
  CHECK(thunk_base);  // If this fails we'd crash anyway on an invalid access.
```

It could be that Avast (and other AV products) has heuristics that block remote RWX allocations. We could try using a file mapping mapped RW in the parent and RX in the child and see if that fixes the issue.

So far I haven't been able to reproduce with the free version of Avast but I haven't officially started the trial (i.e. I have not entered credit card info yet), so maybe I don't have all features enabled although injection does happen.