Remote root hole in Samba [LWN.net]

Remote root hole in Samba

Posted Apr 11, 2012 10:59 UTC (Wed) by jond (subscriber, #37669) [Link]

So we only need to patch vulnerabilities in the VM, instead?

Remote root hole in Samba

Posted Apr 11, 2012 11:06 UTC (Wed) by kleptog (subscriber, #1183) [Link]

Indeed. IIRC, because the protocol is such a pain the samba have a compiler to convert a protocol description to code to avoid stupid errors. In this case it looks like a subtle bug in the compiler (aka abstraction level).

In which case there are probably related problems, but if you squish the bug in the compiler you squish them everywhere.

Interesting that no fuzzers ran into this, must have been subtle indeed.

Remote root hole in Samba

Posted Apr 11, 2012 13:59 UTC (Wed) by dgm (subscriber, #49227) [Link]

Not "only". Programs written in managed languages just have different kinds of vulnerabilities. And, by the way, do you think they have proven more secure? I, for one, don't. In fact, it could be argued that adding the code of the VM to yours increases the probability of bugs, and not the other way around.

Remote root hole in Samba

Posted Apr 11, 2012 15:59 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, they did. When was the last vulnerability in Erlang interpreter discovered?

And then there is research into formalized correctness proofs down to assembly language level ( http://en.wikipedia.org/wiki/Typed_assembly_language )

Remote root hole in Samba

Posted Apr 11, 2012 16:47 UTC (Wed) by khim (subscriber, #9252) [Link]

Yes, they did. When was the last vulnerability in Erlang interpreter discovered?

Interpreter is the key part. It does not matter of your language is managed (see Java and Erlang) or unmanaged (see Ada and C), if it's low-level (see C++) or high-level (see PHP). What does matter is the complexity of the whole scheme. And managed languages tend to increase the complexity because simple, naive implementation is usually slower and so code is added to make it faster (JIT compilers, etc)... often the end result is the system with more code in trusted VM then the in whole unmanaged system!

IOW: managed languages may be useful sometimes, but their usefulness is dramatically overblown and when they are presented as some kind of ultimate solution you know it's snake oil.

Remote root hole in Samba

Posted Apr 11, 2012 17:22 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

That's because in reality almost no VMs are written with security as their main concern.

However, it's theoretically possible to build completely safe systems using only provably safe components from bottom to the top.

Remote root hole in Samba

Posted Apr 11, 2012 17:38 UTC (Wed) by khim (subscriber, #9252) [Link]

Sure, but you don't need managed languages for that. Safe languages like Ada should work just fine.

Remote root hole in Samba

Posted Apr 11, 2012 23:59 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

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

Remote root hole in Samba

Posted Apr 12, 2012 13:57 UTC (Thu) by cesarb (subscriber, #6266) [Link]

> 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

Posted Apr 12, 2012 14:41 UTC (Thu) by khim (subscriber, #9252) [Link]

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

Posted Apr 12, 2012 9:00 UTC (Thu) by job (guest, #670) [Link]

When was the last vulnerability in the PHP interpreter discovered?

Oh ... wait..

Remote root hole in Samba

Posted Apr 11, 2012 11:15 UTC (Wed) by epa (subscriber, #39769) [Link]

A 'safe' language doesn't have to be a 'managed' one in the Java/C# sense. Simple bounds checking of array accesses would have stopped this hole, while still compiling to native code.

It's a mystery to me why compilers don't compile code with array bounds checking by default, with a simple way to turn it off for performance-critical code sections (or for crusty older code that relies on out-of-bounds access to modify adjacent objects in memory).

A managed language would be a further step, and is appropriate for some applications, but there's really quite a lot you can do to stay safe while still programming at a fairly low level.

Safety

Posted Apr 11, 2012 12:07 UTC (Wed) by eru (subscriber, #2753) [Link]

array bounds checking by default

This helps in Pascal-style languages, where pointers are restricted to heap-allocated objects and cannot be modified arithmetically (ignoring common extensions...), but in C it is not so terribly useful, because of how programmers commonly use pointers to march around buffers. Checking tools exist that try to verify that each pointer access points to something legal, but their performance impact is too large to use in production.

Being old enough to learn programming on Pascal, C was a liberation. But I have long wondered if Pascal could be fixed to be both safe and convenient for systems programming? Most of the pain in Pascal programming came from its origin as an intentionally restricted teaching language. Wirth left out all kinds of features most real programs need, because they are system dependent, or not needed for his educational purposes, or he just considered them harmful, so every later implementer added them in an incompatible way, and Pascal programs were hard to port. Another major reason for its demise. Maybe it was also verboseness, {...} is faster to write than begin...end ...

Safety

Posted Apr 11, 2012 12:16 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

But I have long wondered if Pascal could be fixed to be both safe and convenient for systems programming?

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

Safety

Posted Apr 11, 2012 16:52 UTC (Wed) by khim (subscriber, #9252) [Link]

Yup. And then Operon and Oberon-2.

This is when, again, supposedly “intelligent” people ignored value of backward compatibility.

The end result, as usual, is nice exhibit for Computer History Museum, nothing more.

Safety

Posted Apr 11, 2012 22:51 UTC (Wed) by Kluge (guest, #2881) [Link]

>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.

Safety

Posted Apr 12, 2012 10:33 UTC (Thu) by epa (subscriber, #39769) [Link]

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

Posted Apr 11, 2012 14:06 UTC (Wed) by dgm (subscriber, #49227) [Link]

> Simple bounds checking of array accesses would have stopped this hole

Maybe. Or maybe not. If the language included bounds checking the code in fact could have been completely different, probably to avoid the penalty of the bounds checking.

Remote root hole in Samba

Posted Apr 11, 2012 14:55 UTC (Wed) by lopgok (guest, #43164) [Link]

Bounds checking can usually be optimized out at compile time.

I am a fan of pascal. In general, there is no reason to have wild pointer arithmetic. Sure samba needs to deal with a protocol over a wire and to transform the protocol into somethign strongly typed. This part generally does need raw pointers. However, I suspect that 99% of samba doesn't need this kind of pointer access.

Buffer overflow bugs are really quite common in C/C++ code. In addition, poorly managed memory bugs such as double free's and the like are really quite common. Any decent bounds checked language will get rid of almost all the buffer overflow bugs. Any decent automatic memory managed language will get rid of almost all the memory managed bugs.

Personally, I write most of my code in Python now, and small parts in C/C++ when performance is really critical. Memory management isn't a new idea. There are other languages besides Java and C# that do memory management, though they are popular lanugages that do memory management.

There is in general, no excuse to write complete programs in C/C++ or other languages where buffer overflows are trivial.

Remote root hole in Samba

Posted Apr 11, 2012 15:12 UTC (Wed) by jreiser (subscriber, #11027) [Link]

There is in general, no excuse to write complete programs in C/C++ or other languages where buffer overflows are trivial.

Not only are there valid excuses, there are good reasons. Programming is an economic art with differing valuation functions, some of which are time-varying. You may promote the valuations you prefer, but others may promote theirs.

Remote root hole in Samba

Posted Apr 11, 2012 17:06 UTC (Wed) by lopgok (guest, #43164) [Link]

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++.

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

Remote root hole in Samba

Posted Apr 11, 2012 18:13 UTC (Wed) by khim (subscriber, #9252) [Link]

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).

Remote root hole in Samba

Posted Apr 11, 2012 21:20 UTC (Wed) by lopgok (guest, #43164) [Link]

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

Posted Apr 11, 2012 22:36 UTC (Wed) by khim (subscriber, #9252) [Link]

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

Posted Apr 12, 2012 10:42 UTC (Thu) by epa (subscriber, #39769) [Link]

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

Posted Apr 12, 2012 18:34 UTC (Thu) by endecotp (guest, #36428) [Link]

> [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

Posted Apr 12, 2012 20:16 UTC (Thu) by khim (subscriber, #9252) [Link]

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

Posted Apr 12, 2012 20:27 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

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

Posted Apr 12, 2012 20:39 UTC (Thu) by khim (subscriber, #9252) [Link]

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

Posted Apr 12, 2012 21:46 UTC (Thu) by endecotp (guest, #36428) [Link]

> 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

Posted Apr 12, 2012 22:51 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

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

Posted Apr 12, 2012 22:59 UTC (Thu) by khim (subscriber, #9252) [Link]

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

Posted Apr 12, 2012 23:53 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

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

Posted Apr 12, 2012 22:52 UTC (Thu) by khim (subscriber, #9252) [Link]

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

Posted Apr 13, 2012 2:29 UTC (Fri) by mmorrow (subscriber, #83845) [Link]

>> 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

Posted Apr 13, 2012 4:18 UTC (Fri) by khim (subscriber, #9252) [Link]

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

Posted Apr 13, 2012 22:42 UTC (Fri) by mmorrow (subscriber, #83845) [Link]

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

Posted Apr 13, 2012 22:49 UTC (Fri) by mmorrow (subscriber, #83845) [Link]

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

Remote root hole in Samba

Posted Apr 14, 2012 12:17 UTC (Sat) by khim (subscriber, #9252) [Link]

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

Posted Apr 14, 2012 14:20 UTC (Sat) by mmorrow (subscriber, #83845) [Link]

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

Posted Apr 12, 2012 10:38 UTC (Thu) by epa (subscriber, #39769) [Link]

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.

Remote root hole in Samba

Posted Apr 12, 2012 11:42 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

>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

Posted Apr 12, 2012 12:39 UTC (Thu) by epa (subscriber, #39769) [Link]

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

Posted Apr 12, 2012 16:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

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

Posted Apr 12, 2012 16:56 UTC (Thu) by khim (subscriber, #9252) [Link]

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

Posted Apr 13, 2012 12:57 UTC (Fri) by nix (subscriber, #2304) [Link]

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

Posted Apr 12, 2012 12:09 UTC (Thu) by jelmer (subscriber, #40812) [Link]

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

Posted Apr 12, 2012 12:40 UTC (Thu) by epa (subscriber, #39769) [Link]

Interesting, thanks.

Remote root hole in Samba

Posted Apr 11, 2012 12:11 UTC (Wed) by euske (subscriber, #9300) [Link]

OpenSSH people try to contain this kind of bugs by outsourcing a complex part to a chroot jail, though I'm not sure if the same technique can apply to this case here.

Remote root hole in Samba

Posted Apr 11, 2012 15:45 UTC (Wed) by raven667 (subscriber, #5198) [Link]

Samba has a similar separation, there is a root daemon but each authenticated user gets their own fork of the process running as their own user ID. A security issue in that part would only allow them to access their own account. It also allows samba to use the host systems permission infrastructure natively since the OS knows who the file access is for, different than say Apache which has to maintain its own internal idea of users and permissions above the OS.

Clearly there is still a significant amount of SMB which needs to be run as root though.

Remote root hole in Samba

Posted Apr 11, 2012 16:00 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

chroot jails are leaky and insecure, even in OpenBSD. If you manage to start arbitrary code in a chroot jail then you practically own the machine anyway.

Remote root hole in Samba

Posted Apr 11, 2012 16:15 UTC (Wed) by cmccabe (guest, #60281) [Link]

> chroot jails are leaky and insecure, even in OpenBSD. If
> you manage to start arbitrary code in a chroot jail then
> you practically own the machine anyway.

I've never heard anyone say this before. What makes you think that chroot jails are insecure in OpenBSD? Especially when the process being jailed does not run as root.

Remote root hole in Samba

Posted Apr 11, 2012 16:20 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

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

It's just that nobody really cares about OpenBSD a lot to search for vulnerabilities there.

Remote root hole in Samba

Posted Apr 11, 2012 16:49 UTC (Wed) by drag (subscriber, #31333) [Link]

> Programs in OpenBSD chroot have access to all the syscalls.

You'd have to use systrace in conjunction with chroot in OpenBSD to properly sandbox applications. That way you can restrict what type of syscalls can be used.

Remote root hole in Samba

Posted Apr 11, 2012 17:17 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Systrace (as all other generic syscall wrappers) is vulnerable to concurrent attacks.

Remote root hole in Samba

Posted Apr 14, 2012 20:37 UTC (Sat) by andres (guest, #83358) [Link]

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

Posted Apr 11, 2012 23:42 UTC (Wed) by cmccabe (guest, #60281) [Link]

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.

Remote root hole in Samba

Posted Apr 12, 2012 0:03 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

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

Posted Apr 15, 2012 17:23 UTC (Sun) by cmccabe (guest, #60281) [Link]

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

Posted Apr 15, 2012 20:58 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

>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

Posted Apr 15, 2012 23:48 UTC (Sun) by spender (subscriber, #23067) [Link]

Don't forget perf_counter() ;)

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

Remote root hole in Samba

Posted Apr 19, 2012 20:46 UTC (Thu) by cmccabe (guest, #60281) [Link]

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

Posted Apr 11, 2012 16:42 UTC (Wed) by drag (subscriber, #31333) [Link]

> I've never heard anyone say this before. What makes you think that chroot jails are insecure in OpenBSD? Especially when the process being jailed does not run as root.

I don't think that using chroot adds any insecurity over just running the process as a user, but it's important to keep in mind that chroot was never intended or designed to be a security mechanism.

Saying that chroot in OpenBSD is insecure is a bit like saying that home made cardboard gas tanks for cars have inadequate protections against leaks and fires. Sure both statements are absolutely true, but that is only because they are being used in ways never intended to by their original designers.

This is why we have BSDJails, Solaris containers, and LXC to do things properly.