LWN: Comments on "Remote root hole in Samba"

Remote root hole in Samba

cmccabe — Thu, 19 Apr 2012 20:46:58 +0000

Let's look at the orignial post that started this thread.

> Programs in OpenBSD chroot have access to all the syscalls.
> Probably at least several of them are vulnerable.

Now we've digressed into looking at a bunch of Linux (NOT OpenBSD) security flaws. How does this help you prove that OpenBSD is insecure?

Secondly, privilege separation, BSD jails, SELinux, ASLR, etc are still useful technologies even if they don't block 100% of exploits. I think most system administrators would consider being vulnerable to one exploit per year a VERY good record, for any of the major three platforms.

Remote root hole in Samba

spender — Sun, 15 Apr 2012 23:48:56 +0000

Don't forget perf_counter() ;)

http://www.youtube.com/watch?v=KvREwhfQmbc

Remote root hole in Samba

Cyberax — Sun, 15 Apr 2012 20:58:23 +0000

>First of all, we were talking about OpenBSD, not Linux. Secondly, if you're so sure that "some of them are buggy", you should find out which ones. I'm sure that the reward will be a lot greater than $1000.

I'm absolutely sure that Linux right now has multiple exploitable local vulnerabilities.

>However, most of those privilege escalations didn't involve insecure system calls. In fact there's only one that I can think of which did (maybe others can think of more).

Whut?

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0029
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3301
http://xorl.wordpress.com/2011/04/25/cve-2011-1593-linux-...
...

It's like a clockwork! At least one local exploit a year.

Remote root hole in Samba

cmccabe — Sun, 15 Apr 2012 17:23:46 +0000

First of all, we were talking about OpenBSD, not Linux. Secondly, if you're so sure that "some of them are buggy", you should find out which ones. I'm sure that the reward will be a lot greater than $1000.

I think what may be confusing you is the fact that there have been a lot of privilege escalations in Linux over the years (although not in OpenBSD, which is what we were talking about-- remember?). However, most of those privilege escalations didn't involve insecure system calls. In fact there's only one that I can think of which did (maybe others can think of more).

Remote root hole in Samba

andres — Sat, 14 Apr 2012 20:37:28 +0000

Your last two posts in this thread clearly show you have no idea what you're talking about.

systrace is only "vunerable" to TOCTOU/TOATOU if your policy involves checking pointer arguments.

systrace policies such as ssh's block entire syscalls outright; they don't check arguments. As such, those policies are not vulnerable.

Remote root hole in Samba

mmorrow — Sat, 14 Apr 2012 14:20:03 +0000

Ah true, fat-pointers to zero-width memory blocks do appear to give a way to map "int" into "(void*)" in a controlled way.

Remote root hole in Samba

khim — Sat, 14 Apr 2012 12:17:06 +0000

It seems to me that a in conforming implementation which uses fat-pointers, the only possible way the above could be implemented is to implement all such (void*)(int) casts as resulting in NULL.

Not necessarily. 0 must be converted to NULL, but it's quite Ok to produce different pointers for different numbers. The simple way will be to just store given integer in the “address” part of pointer and store zero in “width” part of pointer. This will give you different yet equally unusable pointers.

Remote root hole in Samba

mmorrow — Fri, 13 Apr 2012 22:49:05 +0000

(or replace "p==NULL" with "undefined behaviour", but the question remains "Is this permissible?")

Remote root hole in Samba

mmorrow — Fri, 13 Apr 2012 22:42:27 +0000

True, supporting {,u}intptr_t is optional. Though, (void*)(int) is still allowed. Consider:

int x;
void *p;
x = ..;
assert(x);
p = (void*)x;
assert(p==NULL); /*only possibility for a fat-pointer implem?*/

It seems to me that a in conforming implementation which uses fat-pointers, the only possible way the above could be implemented is to implement all such (void*)(int) casts as resulting in NULL. Whether this is permissible I'm not certain.

Remote root hole in Samba

nix — Fri, 13 Apr 2012 12:57:14 +0000

That's trivially implementable with fat pointers, because one turns into

(*(p+(5)))

while the other turns into

(*((5)+p))

and addition is commutative: the type of the entire expression is typeof(p) in both cases by the C type conversion rules, so the 5 is multiplied by sizeof(*p) in both cases.

So this is perfectly expressible without requiring either flat memory or any form of out-of-object or untyped addressing.

Remote root hole in Samba

khim — Fri, 13 Apr 2012 04:18:34 +0000

This is not forbidden by ISO C11.

[7.20.1.4.1] states:
"[intptr_t] designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer[.]"

You are correct, of course. My bad. If intptr_t exist in a given implementation then you must be able to do such conversion - but it's clearly optional as noted in the very same 7.20.1.4.1 paragraph.

Remote root hole in Samba

mmorrow — Fri, 13 Apr 2012 02:29:44 +0000

>> My recollection is that you're permitted to cast e.g. a char* to an intptr_t

> Yes.

>> and back again

> No. This is forbidden. There is one exception: you can assign null pointer constant...to pointer.
> ...C11 ...
> Other integers can not be assigned. Or rather: they can but the result is undefined behavior (as usual in C).

This is not forbidden by ISO C11.

[7.20.1.4.1] states:

"[intptr_t] designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer[.]"

It seems that you are taking [6.5.16.1] (second to last item):

"the left operand is [a]...pointer, and the right is a null pointer constant..."

to mean that this is the *only* way that a pointer can be assigned an integral value (constant or otherwise). However, consider [6.5.4.3] (emphasis added):

"Conversions that involve pointers, *other that where permitted by the constraints of 6.5.16.1*, shall be specified by means of an explicit cast."

So, the null pointer constant is just the only integral value you can assign to a pointer *without an explicit cast*.

(By pure coincidence the C11 spec happens to be on my desk at arms length ;)

Remote root hole in Samba

nybble41 — Thu, 12 Apr 2012 23:53:45 +0000

There is a footnote in the C99 draft standard to the effect that the intent was for the conversions to reflect the underlying machine architecture. Not a requirement, of course--just a suggestion.

It's an application of the "principle of least surprise". On a machine with uniform, byte-addressable memory (unlike the iAPX 432), the least surprising integer representation of a pointer is the object's byte address, which can easily be converted in both directions without any loss of information.

The standard does specify that you can convert any pointer to a char* and access the object one byte at a time. I'm not sure how one would reconcile that with a type-checked architecture like the iAPX 432.

Remote root hole in Samba

khim — Thu, 12 Apr 2012 22:59:04 +0000

While that seems to be the intent

This was never the intent. Remember the first C standard (ANSI C 89 or ISO 90) was developed when things like iAPX 432 were supposed to be the future. Sure, this direction died off and we've got IA-32 and PPC instead, but language was defined to be usable on such architectures and in such systems. I suspect this is important for things like Alchemy today.

Remote root hole in Samba

khim — Thu, 12 Apr 2012 22:52:04 +0000

My recollection is that you're permitted to cast e.g. a char* to an intptr_t

Yes.

and back again

No. This is forbidden. There is one exception: you can assign null pointer constant (which is an integer constant expression with the value 0, or such an expression cast to type void *) to pointer. Yes, zero is special even in C11, not just in C++11! Other integers can not be assigned. Or rather: they can but the result is undefined behavior (as usual in C).

This may be surprising to you but C does not require flat memory model and it does not guarantee the ability to create pointer from just some random sequence of bits.

Remote root hole in Samba

nybble41 — Thu, 12 Apr 2012 22:51:33 +0000

While that seems to be the intent, and the most common implementation, all I could find on the subject in the C99 draft standard is this:

> An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

> Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type.

So integer-pointer conversions either way are implementation-defined, and pointer-to-integer conversions invoke undefined behavior if the pointer cannot be represented as an integer, which would probably be the case for an implementation with large, bound-checked pointers.

Remote root hole in Samba

endecotp — Thu, 12 Apr 2012 21:46:49 +0000

> All such casts conveniently trigger undefined behavior
> thus are not guaranteed to work

My recollection is that you're permitted to cast e.g. a char* to an intptr_t and back again, and expect to get the same pointer that you started with.

Remote root hole in Samba

khim — Thu, 12 Apr 2012 20:39:14 +0000

As I understand, MCST guys have NOT made a safe hardware.

Yes, they did.

It's all legal - we're not writing into uninitialized RAM and we're not casting pointers to ints.

No, it's illegal. They've used fat pointers thus some_array pointer is pointer with some base address and limit equal to 10. It's illegal to access 12th element using it.

The whole OS was supposed to live in one huge flat address space thus it was important not only to distinguish pointers from non-pointers but also to distinguish “your pointers” from “someone else's pointers”. This is impossible to do without boundary checking.

Besides, E2k is vaporware anyway.

Well, YMMV. The last time they visited our office they had chip but no chipset. Motherboard with tiny cheap CPU and three huge expensive FPGAs (with chipset) is not exactly something you can sell, but it's real in some sense.

Remote root hole in Samba

Cyberax — Thu, 12 Apr 2012 20:27:02 +0000

As I understand, MCST guys have NOT made a safe hardware. They've just implemented pointer tagging. It's more than possible to have unsafe operations there.

For example:

int some_array[10];
int some;
int permissions[3];

some_array[12]=0xFFFF;

It's all legal - we're not writing into uninitialized RAM and we're not casting pointers to ints.

Besides, E2k is vaporware anyway.

Remote root hole in Samba

khim — Thu, 12 Apr 2012 20:16:27 +0000

You can't add bounds checking in f() because it doesn't know the size of the array that ptr points to.

Well, with the existing ABI it does not know, but you can change the ABI. As I've said: it was done before. Actually guys from MCST had hardware support, but it can be done entirely programmatically, too - just with bigger overhead.

You might get quite a long way with that approach, but eventually you'll hit something like casting to/from integers that breaks it.

All such casts conveniently trigger undefined behavior thus are not guaranteed to work. Unions are especially nasty (this is where MCST guys needed hardware support to keep everything working safely and speedily), but yes, you can write entirely safe ISO C language if you want. Of course it's free(3) will probably be noop (or, alternatively malloc(3) can always return NULL) because you'll need to track all allocations, but it's doable.

Remote root hole in Samba

endecotp — Thu, 12 Apr 2012 18:34:34 +0000

> [bounds checking] can be added by the compiler when compiling
> C or C++ code while remaining entirely faithful to the language
> standards for those languages.

No it can't; consider this:

int f(const int* ptr, size_t offset)
{
return ptr[offset];
}

in another translation unit:

int g()
{
int a[100];
return f(a,100);
}

You can't add bounds checking in f() because it doesn't know the size of the array that ptr points to. You can't add bounds checking in g() because it doesn't know that 100 is being used as an array index.

You can try to carry around the valid bounds of every pointer by making each pointer actually 3 addresses. You might get quite a long way with that approach, but eventually you'll hit something like casting to/from integers that breaks it.

Remote root hole in Samba

khim — Thu, 12 Apr 2012 16:56:09 +0000

It's possible to implement the full C standard using fat pointers (including 5[p] == p[5], of course). People from MCST did that with E2k. What they found out immediately after is the fact that real programs are not C-standard compliant. For example they sometimes want to convert pointer to suitably-sized int (which is allowed) and then back (which is not allowed).

Remote root hole in Samba

Cyberax — Thu, 12 Apr 2012 16:39:26 +0000

kcc probably doesn't implement all the C standard.

For example, there's no way one can do: "5[p] == p[5]" with fat pointers.

Remote root hole in Samba

khim — Thu, 12 Apr 2012 14:41:30 +0000

You don't need GC. The things which you can not include are free(3) and realloc(3): without tracing pointers you can not say if it's safe to decallocate memory or not if you trace pointers anyway then why will you need free(3) or realloc(3)?

Usually the safe alternative is some kind of GC (refcounting GC works fine and often presents the best practical compromise), but other schemes are possible (for example you can allocate memory statically or use arenas which can be freed in safe way).

Remote root hole in Samba

cesarb — Thu, 12 Apr 2012 13:57:08 +0000

> Sure. You need mandatory GC and range checks. If your language has them then it can be made safe.

Why do you need GC to make a safe language?

Remote root hole in Samba

epa — Thu, 12 Apr 2012 12:40:51 +0000

Interesting, thanks.

Remote root hole in Samba

epa — Thu, 12 Apr 2012 12:39:28 +0000

Bounds checking requires ALL pointers to carry the size of the block of RAM they're pointing to. C standard does not allow this.

Technically, this is not correct - for example kcc is a compiler which conforms to the C standard and also checks all pointer accesses. But the code runs very slowly. In practice, you are right that it is not possible to check *all* pointer accesses without cumbersome runtime machinery.

However I wasn't suggesting that; only checking of array bounds in something like a[i]. If you wanted to defeat the bounds checking it would be easy to say *(&a[0] + 500) but we are not trying to make a managed language like Java in which raw memory access is impossible - only to convert a good chunk of bugs from remote-root holes into mere denial-of-service attacks.

Again, to be clear, I am not saying that C should change into a language where every pointer has to carry type information or where raw pointer access is forbidden. (Even though that would in theory be possible while still implementing the C standard, as the link above shows.) I am only saying that array accesses should have simple bounds checking that the offset is between 0 and (length-1), that this bounds checking be inserted by the compiler in cases where it adds only a small runtime overhead, and that there be an easy way to turn it off again if the programmer needs every drop of performance.

I have to admit that I have not examined the code mentioned in this advisory and that when it talks about 'array' access being out of bounds, it could in fact be some complex pointer manipulation. It might not be possible for a compiler to add bounds checking to that without adding runtime type information, as you say. In which case simple bounds checking would not have stopped this particular root exploit.

Remote root hole in Samba

jelmer — Thu, 12 Apr 2012 12:09:27 +0000

Samba uses a domain-specific language (IDL) to describe the various DCE/RPC calls. Our IDL compiler (pidl) is then used to generate the pack/unpack code in C.

This security issue was caused by a bug in the IDL compiler's generation of the bounds checking code for some arrays.

Remote root hole in Samba

Cyberax — Thu, 12 Apr 2012 11:42:36 +0000

>I am not really saying that the 'language' should include bounds checking. The semantics of C do not need to change. As far as I know, an out-of-bounds array access is already an operation with undefined behaviour, so the compiler is free to add bounds checking to the generated code while remaining a correct C compiler.

Nope. Bounds checking requires ALL pointers to carry the size of the block of RAM they're pointing to. C standard does not allow this.

Cyclone ( http://en.wikipedia.org/wiki/Cyclone_%28programming_langu... ) does this by having each pointer carry its length in a separate variable.

In Java/C#/Go/... pointers are forbidden entirely and only references to objects of statically known size are allowed.

Remote root hole in Samba

epa — Thu, 12 Apr 2012 10:42:18 +0000

Well, whatever the arguments about using C or C++ for new projects (and I don't want to get into a language war) there is certainly a lot of existing code in these languages.

My point is that bounds checking is not something which requires changing your programming language. It can be added by the compiler when compiling C or C++ code while remaining entirely faithful to the language standards for those languages.

Remote root hole in Samba

epa — Thu, 12 Apr 2012 10:38:10 +0000

I am not really saying that the 'language' should include bounds checking. The semantics of C do not need to change. As far as I know, an out-of-bounds array access is already an operation with undefined behaviour, so the compiler is free to add bounds checking to the generated code while remaining a correct C compiler.

It would however make sense to provide a simple pragma to turn off bounds checking for performance-critical code. I would expect that the developers of a program like Samba would choose not to use that pragma in a part of the code that parses untrusted user requests. It's not that the developers deliberately chose to write their program in an unsafe style in order to squeeze out an extra one per cent of performance. Rather, the available tools made it hard for them to make it safe.

Make it easy to be safe - make bounds checking on by default - and provide a simple way for programmers to choose the riskier option if they choose to.

Safety

epa — Thu, 12 Apr 2012 10:33:17 +0000

I know that array bounds checking does not catch all memory trampling bugs, particularly in programs that use lots of pointers. My point is that it does catch a lot of them, and from the sound of the bug report it appears it would have caught this particular one.

As with all security measures (or indeed anything), the fact that it would not eliminate the problem entirely is not a reason to take a reasonable step to reduce the problem.

Remote root hole in Samba

job — Thu, 12 Apr 2012 09:00:14 +0000

When was the last vulnerability in the PHP interpreter discovered?

Oh ... wait..

Remote root hole in Samba

Cyberax — Thu, 12 Apr 2012 00:03:54 +0000

I'm absolutely sure that at least some of them are buggy. I can bet you $1000 that there'll be new local Linux kernel exploits within 2 years.

Remote root hole in Samba

Cyberax — Wed, 11 Apr 2012 23:59:56 +0000

Sure. You need mandatory GC and range checks. If your language has them then it can be made safe.

Remote root hole in Samba

cmccabe — Wed, 11 Apr 2012 23:42:42 +0000

If you have proof that any of the system calls in OpenBSD (or Linux, for that matter) are vulnerable, then you should post it. If not, I'm afraid this is starting to sound like FUD.

Safety

Kluge — Wed, 11 Apr 2012 22:51:44 +0000

>Wasn't that the idea behind Modula-2 (and subsequently Modula-3)?

And also Delphi and Free Pascal, GNU Pascal, etc?

AFAIK (speaking as occasional programmer; not an authority), those systems provide good, modern development environments. Not sure how safe they are compared to the C family.

Remote root hole in Samba

khim — Wed, 11 Apr 2012 22:36:43 +0000

So what percentage of google is written in C/C++ ?

A lot. I'm not sure I can disclose the precise numbers, but most performance-critical pieces (such as search or ads where every saved millisecond can be translated directly to revenue) are written in C++.

I have heard it is mostly java, python, and C/C++ in third place.

Nope. Python was never used for anything “heavy”. It think the heaviest python-based application is still Mondrian. Python is used for monitoring, for creation of reports, that kind of stuff.

When Google was startup it created plethora of languages (things like Sawzall), and new DSLs are introduced from time to time, but the main pillars are still C++ and Java.

I don't think that google is a startup anymore.

Yup. That's why it uses industry-standard languages now.

According to you, they should write everything in C/C++ because it is easier to find people who already know it.

Bingo! They do! Of course Java is even more popular thus less performance-critical pieces are written in Java.

I believe that gmail is all python...

Well, the last time I've worked with GMail codebase was about three years ago and it was C++ backend and Java (and obviously JavaScript) in frontend. I know they did extensive redesign after that time so I'm not fully sure about the current split between Java and C++, but no, python was never under consideration. Beyond monitoring and report tools, that is.

Remote root hole in Samba

lopgok — Wed, 11 Apr 2012 21:20:48 +0000

So what percentage of google is written in C/C++ ?
I have heard it is mostly java, python, and C/C++ in third place.
Notice that java and python have
1) bounds checked arrays
2) memory management

I don't think that google is a startup anymore.

According to you, they should write everything in C/C++ because it is easier to find people who already know it.

I believe that gmail is all python...

Remote root hole in Samba

khim — Wed, 11 Apr 2012 18:13:09 +0000

In terms of economics there is no justification for writing an entire program in C. Time to develop, difficulity to maintain, lines of code, and security all point away from using C/C++.

This depends on your needs, really. How many OS kernel you can name written in Haskel? How many modern Web Browsers afre out there written in Lisp or even Java?

Perhaps you should read Paul Graham about writing a web app for shopping carts. http://www.paulgraham.com/avg.html

Yeah. That's good article. But you don't really need the whole behemoth. Single first footnote is more then enough:

Viaweb at first had two parts: the editor, written in Lisp, which people used to build their sites, and the ordering system, written in C, which handled orders. The first version was mostly Lisp, because the ordering system was small. Later we added two more modules, an image generator written in C, and a back-office manager written mostly in Perl.

In January 2003, Yahoo released a new version of the editor written in C++ and Perl. It's hard to say whether the program is no longer written in Lisp, though, because to translate this program into C++ they literally had to write a Lisp interpreter: the source files of all the page-generating templates are still, as far as I know, Lisp code. (See Greenspun's Tenth Rule.)

Erlang, Hakell, Lisp and other exotic languages work just fine for a startup (indeed they may be more effective then C/C++ depending on the task), but they don't scale. The very simple fact that you need someone with exotic skillset to develop such a thing means that when you grow beyond the startup phase you need to redo the thing in some other language… and you often lose so much in transition that sometimes your initial lead is not enough to survive.

And if you are not a startup then it's easier to use language familiar to the people in your company rather then to try to find or train someone to use Scheme or something similar… which means C/C++ is often pretty damn good choice (if not the best one).