Make CPython segfault in 5 lines of code • Hacker News Board

Re: Make CPython segfault in 5 lines of code

#11

Post by Thaxll » Thu, Dec 19, 2019, 4:20 AM UTC

danielheath wrote: post #9

lpghatguy wrote: post #7

Segfaults in scripting languages are remarkably common, especially if arbitrary bytecode can be loaded into the VM. One I ran into in the wild recently is that in older versions of Lua, exceptions in GC finalizers (the `__gc` metamethod) can trigger a segfault. In those same versions of Lua, the bytecode format is notoriously dangerous to load. I wonder whether this will be a large component of newer scripting langua…

IMO the biggest reason to adopt the WebAssembly format is that a segfault inside the runtime doesn't affect the host process at all. It's a plausible approach to a fully-safe, near-native-speed plugin architecture.

Segfault inside the runtime, What does it means exactly? A segfault is by definition at the OS level.

WebAssembly koolaid is strong on HN, let's wait the first exploits that escapes the runtime to assess the "fully-safe" architecture.

Re: Make CPython segfault in 5 lines of code

#12

Post by paulddraper » Thu, Dec 19, 2019, 4:25 AM UTC

If # of lines are important, this problem can actually be demonstrated in 1 line:

    for x, x.__new__ in [(__import__('queue').Full, print)]: __import__('glob').iglob(0).throw(x)

Re: Make CPython segfault in 5 lines of code

#13

Post by chubot » Thu, Dec 19, 2019, 4:28 AM UTC

danielheath wrote: post #9

lpghatguy wrote: post #7

Segfaults in scripting languages are remarkably common, especially if arbitrary bytecode can be loaded into the VM. One I ran into in the wild recently is that in older versions of Lua, exceptions in GC finalizers (the `__gc` metamethod) can trigger a segfault. In those same versions of Lua, the bytecode format is notoriously dangerous to load. I wonder whether this will be a large component of newer scripting langua…

IMO the biggest reason to adopt the WebAssembly format is that a segfault inside the runtime doesn't affect the host process at all. It's a plausible approach to a fully-safe, near-native-speed plugin architecture.

Seg faults are "safe" in the programming language sense:

A program fragment is safe if it does not cause untrapped errors to occur. Languages where all program fragments are safe are called safe languages. Therefore, safe languages rule out the most insidious form of execution errors: the ones that may go unnoticed.

...

It is useful to distinguish between two kinds of execution errors: the ones that cause the computation to stop immediately, and the ones that go unnoticed (for a while) and later cause arbitrary behavior. The former are called trapped errors, whereas the latter are untrapped errors.

Type Systems, Luca Cardelli

https://scholar.google.com/scholar?cluster=90442457768317510...

And practically speaking seg faults are easy to debug and fix.

I see a lot of abuse of the terms "safe" and "safe language" lately.

Re: Make CPython segfault in 5 lines of code

#14

Post by gizmo686 » Thu, Dec 19, 2019, 4:44 AM UTC

chubot wrote: post #13

danielheath wrote: post #9

Earlier quoted context omitted.

IMO the biggest reason to adopt the WebAssembly format is that a segfault inside the runtime doesn't affect the host process at all. It's a plausible approach to a fully-safe, near-native-speed plugin architecture.

Seg faults are "safe" in the programming language sense: A program fragment is safe if it does not cause untrapped errors to occur. Languages where all program fragments are safe are called safe languages. Therefore, safe languages rule out the most insidious form of execution errors: the ones that may go unnoticed. ... It is useful to distinguish between two kinds of execution errors: the ones that cause the computa…

The problem is that segfaults are frequently the latter type of problem. You do some unsafe thing and corrupt your state, but keep on going without obvious issue. Then at some point in the future, your corrupted state causes an otherwise bug-free portion of you program to segfault.

Re: Make CPython segfault in 5 lines of code

#15

Post by chubot » Thu, Dec 19, 2019, 5:15 AM UTC

gizmo686 wrote: post #14

chubot wrote: post #13

Earlier quoted context omitted.

Seg faults are "safe" in the programming language sense: A program fragment is safe if it does not cause untrapped errors to occur. Languages where all program fragments are safe are called safe languages. Therefore, safe languages rule out the most insidious form of execution errors: the ones that may go unnoticed. ... It is useful to distinguish between two kinds of execution errors: the ones that cause the computa…

The problem is that segfaults are frequently the latter type of problem. You do some unsafe thing and corrupt your state, but keep on going without obvious issue. Then at some point in the future, your corrupted state causes an otherwise bug-free portion of you program to segfault.

The problem isn't the segfault -- it's the earlier unsafe behavior. That is, the untrapped error that eventually caused the segfault.

If the language only has trapped errors, which are indicated by seg faults, it's a safe language.

Every language has such errors. What does divide by zero do?

What does blowing the stack / infinite recursion do in Rust? It seg faults.

The seg fault is the safe behavior. If the stack overflow overwrote heap data structures or global data structures and the program kept running, that would be unsafe.

Re: Make CPython segfault in 5 lines of code

#16

Post by dependenttypes » Thu, Dec 19, 2019, 5:18 AM UTC

This would not have happened in a language with a proper type system as the type checker would have rejected the program at compile time.

Re: Make CPython segfault in 5 lines of code

#17

Post by tus88 » Thu, Dec 19, 2019, 5:26 AM UTC

lpghatguy wrote: post #7

Segfaults in scripting languages are remarkably common, especially if arbitrary bytecode can be loaded into the VM. One I ran into in the wild recently is that in older versions of Lua, exceptions in GC finalizers (the `__gc` metamethod) can trigger a segfault. In those same versions of Lua, the bytecode format is notoriously dangerous to load. I wonder whether this will be a large component of newer scripting langua…

> Segfaults in scripting languages are remarkably common

What about Javascript running on V8?

Re: Make CPython segfault in 5 lines of code

#18

Post by schoen » Thu, Dec 19, 2019, 5:41 AM UTC

lpghatguy wrote: post #7

Segfaults in scripting languages are remarkably common, especially if arbitrary bytecode can be loaded into the VM. One I ran into in the wild recently is that in older versions of Lua, exceptions in GC finalizers (the `__gc` metamethod) can trigger a segfault. In those same versions of Lua, the bytecode format is notoriously dangerous to load. I wonder whether this will be a large component of newer scripting langua…

Is anybody fuzzing Python bytecodes? This sounds like a super-great application for afl.

Re: Make CPython segfault in 5 lines of code

#19

Post by xapata » Thu, Dec 19, 2019, 5:51 AM UTC

schoen wrote: post #18

lpghatguy wrote: post #7

Segfaults in scripting languages are remarkably common, especially if arbitrary bytecode can be loaded into the VM. One I ran into in the wild recently is that in older versions of Lua, exceptions in GC finalizers (the `__gc` metamethod) can trigger a segfault. In those same versions of Lua, the bytecode format is notoriously dangerous to load. I wonder whether this will be a large component of newer scripting langua…

Is anybody fuzzing Python bytecodes? This sounds like a super-great application for afl.

I think people have, but it's not clear that searching for bugs by perverse input is a great use of time. Maybe better to focus on solving currently known issues.

Re: Make CPython segfault in 5 lines of code

#20

Post by deathanatos » Thu, Dec 19, 2019, 5:53 AM UTC

chubot wrote: post #15

gizmo686 wrote: post #14

Earlier quoted context omitted.

The problem is that segfaults are frequently the latter type of problem. You do some unsafe thing and corrupt your state, but keep on going without obvious issue. Then at some point in the future, your corrupted state causes an otherwise bug-free portion of you program to segfault.

The problem isn't the segfault -- it's the earlier unsafe behavior. That is, the untrapped error that eventually caused the segfault. If the language only has trapped errors, which are indicated by seg faults, it's a safe language. Every language has such errors. What does divide by zero do? What does blowing the stack / infinite recursion do in Rust? It seg faults. The seg fault is the safe behavior. If the stack ov…

> What does divide by zero do?

Returns a value, of course! (And that said, JavaScript does have some trapped errors, such as (1/0).foo.foo (and yes you need the second .foo…))

IMO, the execution "error" here (in this thread) is accessing memory illegally. Sometimes the runtime traps it, but sometimes it does not, and "sometimes" isn't always, so its effectively untrapped as we cannot depend on the trap. (Especially in adversarial circumstances.)

And further, the original quote talks about languages — the behavior of a language like C is that memory access is not necessarily trapped; the behavior is not well defined. Given the lack of a requirement in the C language for a trap, I think it is fair to call C "unsafe" given the above definition of safe/unsafe.

> What does blowing the stack / infinite recursion do in Rust? It seg faults.

Somewhat interestingly, it detects it and SIGABRTs, which technically isn't a segfault. And that's now some black magic that I'm curious about as I really thought it would have segfaulted.