f095a00c78
Summary:
Changelog: Fixed an issue where Flipper would crash when decoding large partial requests.
The current processing of partial requests assumes that the proviced base64 string is always an utf-8 string, which is incorrect as it might contain binary data as well. This causes `atob` build in to throw errors when trying to decode binary base64 strings with the following exception:
{F538782963}
However, what is worse, if those strings were larger than ~2 mb, it would completely crash Electron rather than on the JS level, with reports like:
```
Crashed Thread: 0 CrRendererMain Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [85268]
Thread 0 Crashed:: CrRendererMain Dispatch queue: com.apple.main-thread
0 com.github.Electron.framework 0x000000011155b16f v8::internal::SetupIsolateDelegate::SetupHeap(v8::internal::Heap*) + 22324575
1 com.github.Electron.framework 0x000000011155e811 v8::internal::SetupIsolateDelegate::SetupHeap(v8::internal::Heap*) + 22338561
2 com.github.Electron.framework 0x00000001117e2e62 v8::internal::SetupIsolateDelegate::SetupHeap(v8::internal::Heap*) + 24978002
3 com.github.Electron.framework 0x000000010fa32660 v8::internal::ClassScope::ResolvePrivateNamesPartially() + 14944
4 com.github.Electron.framework 0x000000010fa322b5 v8::internal::ClassScope::ResolvePrivateNamesPartially() + 14005
5 com.github.Electron.framework 0x000000010fa31933 v8::internal::ClassScope::ResolvePrivateNamesPartially() + 11571
6 com.github.Electron.framework 0x000000011007ef58 v8::internal::SetupIsolateDelegate::SetupHeap(v8::internal::Heap*) + 451400
```
Reproduced this JS issue by lowering the `MAX_BODY_SIZE_IN_BYTES` in `NetworkFlipperPlugin.java` to 10KB, which causes all requests to be processed as partials.
Reproducing the the Electron crash is a lot harder, as it requires a surface that makes large, binary requests (more than a few mb), that is still intercepted by the Network layer. The best example I could find is sending large pictures or videos through a messenger for android chat. In that case it is still hard to produce due to caching though.
Fun fact, you can crash your own flipper and get the above crash by running this command:
`btoa(require("fs").readFileSync("/Users/mweststrate/Desktop/Screen Recording 2021-03-24 at 16.08.27 crop.mov", "binary"))`, where the provided file must be a few mb's large (this one is 10).
A result of fixing this issue, is that images that were send as partials can now be correctly previewed in the Network plugin again.
Reviewed By: jknoxville
Differential Revision: D27302961
fbshipit-source-id: 1ac86840f7268062bb59c789f3904537df3c51fa
74 lines
2.2 KiB
TypeScript
74 lines
2.2 KiB
TypeScript
/**
|
|
* Copyright (c) Facebook, Inc. and its affiliates.
|
|
*
|
|
* This source code is licensed under the MIT license found in the
|
|
* LICENSE file in the root directory of this source tree.
|
|
*
|
|
* @format
|
|
*/
|
|
|
|
import type {PartialResponses, Response} from './types';
|
|
import {Atom} from 'flipper-plugin';
|
|
import {Base64} from 'js-base64';
|
|
|
|
export function assembleChunksIfResponseIsComplete(
|
|
partialResponses: Atom<PartialResponses>,
|
|
responses: Atom<Record<string, Response>>,
|
|
responseId: string,
|
|
) {
|
|
const partialResponseEntry = partialResponses.get()[responseId];
|
|
const numChunks = partialResponseEntry.initialResponse?.totalChunks;
|
|
if (
|
|
!partialResponseEntry.initialResponse ||
|
|
!numChunks ||
|
|
Object.keys(partialResponseEntry.followupChunks).length + 1 < numChunks
|
|
) {
|
|
// Partial response not yet complete, do nothing.
|
|
return;
|
|
}
|
|
|
|
// Partial response has all required chunks, convert it to a full Response.
|
|
const response: Response = partialResponseEntry.initialResponse;
|
|
const allChunks: string[] =
|
|
response.data != null
|
|
? [
|
|
response.data,
|
|
...Object.entries(partialResponseEntry.followupChunks)
|
|
// It's important to parseInt here or it sorts lexicographically
|
|
.sort((a, b) => parseInt(a[0], 10) - parseInt(b[0], 10))
|
|
.map(([_k, v]: [string, string]) => v),
|
|
]
|
|
: [];
|
|
const data = combineBase64Chunks(allChunks);
|
|
|
|
responses.update((draft) => {
|
|
draft[responseId] = {
|
|
...response,
|
|
// Currently data is always decoded at render time, so re-encode it to match the single response format.
|
|
data,
|
|
};
|
|
});
|
|
|
|
partialResponses.update((draft) => {
|
|
delete draft[responseId];
|
|
});
|
|
}
|
|
|
|
export function combineBase64Chunks(chunks: string[]): string {
|
|
const byteArray = chunks.map((b64Chunk) => {
|
|
return Base64.toUint8Array(b64Chunk);
|
|
});
|
|
const size = byteArray
|
|
.map((b) => b.byteLength)
|
|
.reduce((prev, curr) => prev + curr, 0);
|
|
|
|
const buffer = new Uint8Array(size);
|
|
let offset = 0;
|
|
for (let i = 0; i < byteArray.length; i++) {
|
|
buffer.set(byteArray[i], offset);
|
|
offset += byteArray[i].byteLength;
|
|
}
|
|
|
|
return Base64.fromUint8Array(buffer);
|
|
}
|