| Commit message (Collapse) | Author | Age | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
| |
the potential case where this is bypassable
Since snekbox does not run with a tty, stdout is technically raw bytes, and thus incomplete surrogate pairs can be printed without the client application erroring, and instead fail within _consume_stdout when we attempt to decode it to a str.
This commit sets the PYTHONIOENCODING environment variable to inform python to open the pipe in utf-8 mode.
However, clever use of execl and os.unsetenv() can unset this environment variable, so we add a safety check to _consume_stdout to fail out of parsing output if it contains invalid unicode. This should only happen in deliberate cases, or significant bugs in python or a c library where output is printed to stdout ignoring the python stdout encoding.
|
| |
|
|
| |
Test was relying on 137 which is SIGKILL, when instead it would receive 143, or SIGTERM.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
The logs clutter up the test output way too much.
|
| | |
|
| |
|
|
|
|
| |
I've added a test that checks if output exceeding the limit is
correctly truncated. To make the test more robust, I've defined a
constant for the read chunk size.
|
| |
|
|
|
|
|
| |
When you send a signal `N` to a subprocess using Popen, it will return
`-N` as its exit code. As the rest of the code returns signal exit codes
as `128 + N`, we convert those negative exit codes into the standard
form used by the rest of the code.
|
| |
|
|
|
|
| |
This new behavior matches how other limiters terminate the subprocess,
resulting in a more consistency in the front-end for the end users as
well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recently, we discovered that for some code inputs, snekbox would get
into an OOM event on the container level, seemingly bypassing the memory
restrictions laid on code execution by NSJail.
After investigating the issue, we identified the culprit to be the
STDOUT pipe we use to get output back from NSJail: As output is piped
out of the jailed process, it will be gathered outside of the NSJail in
the main container process instead. This meant that our initial attempts
of limiting the allowed filesize within the NSJail failed, as the OOM
happened outside of the jailed environment.
To mitigate the issue, I've written a loop that consumes the STDOUT pipe
in chunks of 100 characters. Once the size of the accrued output reaches
a certain limit (currently set to 1 MB), we send a SIGTERM signal to
NSJail to terminate itself. The output up to that point will be relayed
back to the caller.
A minimal code snippet to trigger the event and the mitigation:
```py
while True:
print(" ")
```
I've included a test for this vulnerability in `tests/test_nsjail.py`.
|
| | |
|
| |
|
|
|
| |
This is a test for #53, which fixed numpy failing to import due to
using multiple threads by default.
|
| | |
|
| |
|
|
| |
Co-authored-by: 0xf0f <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
| |
If memory swapping was enabled locally, the memory test would fail.
Explicitly disabling swapping also removes reliance on the assumption
that it'll be disabled in production.
* Add a constant for the maximum memory
* Simplify the timeout test; it'd otherwise first run out of memory now
|
| |
|
|
|
| |
* Add support for debug level to log regex
* Change type annotation of log_parse to Iterable
|
|
|
* Fix SIGSEGV test
* Add embedded null byte test
* Return None for stderr when there's a ValueError
|
Bast
Joe Banks
MarkKoz
Sebastiaan Zeeff