LWN.net News from the source
| From: | Karolin Seeger <kseeger-AT-samba.org> | |
| To: | samba-announce-AT-samba.org, samba-AT-samba.org, samba-technical-AT-samba.org | |
| Subject: | [Announce] Samba 3.6.4, 3.5.14 and 3.4.16 Security Releases Available | |
| Date: | Tue, 10 Apr 2012 17:21:19 +0200 | |
| Message-ID: | <E1SHcsi-000w5A-87@intern.SerNet.DE> | |
| Archive-link: | Article |
Release Announcements
=====================
Samba 3.6.4, 3.5.14 and 3.4.16 are security releases in order to
address CVE-2012-1182.
o CVE-2012-1182:
Samba 3.0.x to 3.6.3 are affected by a
vulnerability that allows remote code
execution as the "root" user.
Changes:
--------
o Stefan Metzmacher <metze@samba.org>
*BUG 8815: PIDL based autogenerated code allows overwriting beyond of
allocated array (CVE-2012-1182).
######################################################################
Reporting bugs & Development Discussion
#######################################
Please discuss this release on the samba-technical mailing list or by
joining the #samba-technical IRC channel on irc.freenode.net.
If you do report problems then please try to send high quality
feedback. If you don't provide vital information to help us track down
the problem then you will probably be ignored. All bug reports should
be filed under the Samba corresponding product in the project's Bugzilla
database (https://bugzilla.samba.org/).
======================================================================
== Our Code, Our Bugs, Our Responsibility.
== The Samba Team
======================================================================
================
Download Details
================
The uncompressed tarballs and patch files have been signed
using GnuPG (ID 6568B7EA). The source code can be downloaded
from:
http://download.samba.org/samba/ftp/
The release notes are available online at:
http://www.samba.org/samba/ftp/history/samba-3.6.4.html
http://www.samba.org/samba/ftp/history/samba-3.5.14.html
http://www.samba.org/samba/ftp/history/samba-3.4.16.html
Binary packages will be made available on a volunteer basis from
http://download.samba.org/samba/ftp/Binary_Packages/
Our Code, Our Bugs, Our Responsibility.
(https://bugzilla.samba.org/)
--Enjoy
The Samba Team
Remote root hole in Samba
Posted Apr 10, 2012 19:51 UTC (Tue) by lutchann (subscriber, #8872) [Link]
Remote root hole in Samba
Posted Apr 10, 2012 20:13 UTC (Tue) by ken (subscriber, #625) [Link]
And it probably was known as the error was in the RPC code and that would
be one of the primary places people would go and look for a problem.
unless it was very tricky to exploit this is definitely one of the more nasty bugs in resent time.
Remote root hole in Samba
Posted Apr 11, 2012 9:32 UTC (Wed) by eru (subscriber, #2753) [Link]
Some black hats is probably crying right now when they lost this backdoor.They stop that when they realize it takes time for all the myriad Samba installations to be fixed, and some might never be. For example, I wonder about all those inexpensive consumer network storage boxes. Many of them run Linux, and to provide Windows network shares they probably use Samba (is there even any other alternative?). Only the most enlightened users will attempt to update them.
Remote root hole in Samba
Posted Apr 11, 2012 9:07 UTC (Wed) by jelmer (subscriber, #40812) [Link]
Remote root hole in Samba
Posted Apr 10, 2012 21:48 UTC (Tue) by dowdle (subscriber, #659) [Link]
Remote root hole in Samba
Posted Apr 10, 2012 22:07 UTC (Tue) by dowdle (subscriber, #659) [Link]
Remote root hole in Samba
Posted Apr 11, 2012 10:11 UTC (Wed) by loftsy (guest, #75160) [Link]
Remote root hole in Samba
Posted Apr 11, 2012 10:59 UTC (Wed) by jond (subscriber, #37669) [Link]
Remote root hole in Samba
Posted Apr 11, 2012 11:06 UTC (Wed) by kleptog (subscriber, #1183) [Link]
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]
Remote root hole in Samba
Posted Apr 11, 2012 15:59 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
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]
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]
Remote root hole in Samba
Posted Apr 12, 2012 13:57 UTC (Thu) by cesarb (subscriber, #6266) [Link]
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]
Oh ... wait..
Remote root hole in Samba
Posted Apr 11, 2012 11:15 UTC (Wed) by epa (subscriber, #39769) [Link]
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 defaultThis 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 (subscriber, #2881) [Link]
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]
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]
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]
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]
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]
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]
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]
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.int some_array[10]; int some; int permissions[3]; some_array[12]=0xFFFF;
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]
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]
> 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]
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. achar*to anintptr_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 (guest, #83845) [Link]
> 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 (guest, #83845) [Link]
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 (guest, #83845) [Link]
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 (guest, #83845) [Link]
Remote root hole in Samba
Posted Apr 12, 2012 10:38 UTC (Thu) by epa (subscriber, #39769) [Link]
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]
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]
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]
(*(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]
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]
Remote root hole in Samba
Posted Apr 11, 2012 12:11 UTC (Wed) by euske (subscriber, #9300) [Link]
Remote root hole in Samba
Posted Apr 11, 2012 15:45 UTC (Wed) by raven667 (subscriber, #5198) [Link]
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]
Remote root hole in Samba
Posted Apr 11, 2012 16:15 UTC (Wed) by cmccabe (guest, #60281) [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.
Remote root hole in Samba
Posted Apr 11, 2012 16:20 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
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 (guest, #31333) [Link]
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]
Remote root hole in Samba
Posted Apr 14, 2012 20:37 UTC (Sat) by andres (guest, #83358) [Link]
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]
Remote root hole in Samba
Posted Apr 12, 2012 0:03 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Remote root hole in Samba
Posted Apr 15, 2012 17:23 UTC (Sun) by cmccabe (guest, #60281) [Link]
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]
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]
Remote root hole in Samba
Posted Apr 19, 2012 20:46 UTC (Thu) by cmccabe (guest, #60281) [Link]
> 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 (guest, #31333) [Link]
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.
Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds