Re: Serious security hole in Samba
Hi,
At 07:29 PM 9/29/97 +0200, you wrote:
>Please, note that David Engel (the author of ld.so) adviced us that
>this is _not_ true.
>
>Doing the above _may_ seem to work, but it may very well result in
>misterious segfaults in the resulting package. For example, say
>libpam defines a function
>
> foopass (uid_t uid, char *user, gid_t gid, char *group );
>
>Then, if samba (libc6 compiled) calls that function, uid_t and gid_t
>will be 4 bytes long each (new in libc6), but libpam expects those
>variables to be 2 bytes long each (libc5). Needless to say, things
>may go wrong.
I see. This must explain why smbd was seg. faulting in libpam: I was able
to compile and link against libc6 but was getting seg. faults when smbd
tried to verify the password provided by the user (the fault was in
libpam). I got rid of the fault by linking with libcrypt. Probably by doing
this libpam is not being used at all and this is completely wrong.
Right now I haven't seen any seg. faults in my Samba libc6 package and it's
been running in production in two different servers for weeks.
>OK, apparently in your case gcc was able to link the final binary.
>On my system, gcc wasn't able to do so, and probably rightly so.
Why it is right to have a failed link in you system and a succesful one in
mine? I don't want to be rude, I just want to know.
>I don't know what it was, but I suspect it had to do with my system
>being very recent-unstable. On a pure bo system, I was able to create
>a libc5 binary, but on my system I couldn't create the libc5 binary
>eighter.
I don't think things are stable enough these days to do both libc5 and
libc6 development in the same machine. I might be wrong, of course.
>Note that you _do_ have "hidden" libc5 dependencies, as libpam depends
>on libc5. Only not explicit, so ldd doesn't notice (and ld.so doesn't
>notice, you only may notice after a while with segfaults or whatever).
Sounds reasonable.
>Yeah, a lot of programmes appear to run fine this way. But that realy
>must be just luck, and I also know programmes that fail in very
>misterious ways. I wouldn't want debian's security fix-release of
>samba to be one of those.
What is worse: a program that "might" seg. fault or a program with a
security whole that allows any user to gain full root access? I choose the
program that might seg. fault.
The facts I see are: 1) building a Samba libc5 package is trivial, 2) a new
Samba package that takes care of the security whole is mandatory and 3) a
Samba libc6 package may not be stable. My questions is: what should be
uploaded to hamm? This libc5 version (an exception has to be made)? Or
perhaps the possibly broken libc6 version?
>... This must be because my libc5/libc6
>libraries are somewhat more recent than yours, and have more explicid
>libc dependancies. (I upgraded my unstable system only last friday).
I have just checked on ftp.debian.org for newest versions of libc5 and
libc6. I have the latest versions installed in my system. Same for -dev.
Is there anything else I should check?
>But the mixed libc5/libc6 samba you have really cannot be thought
>of as "truely" stable (OK, it appears to work, but given that there
>is such a big opportunity for segfaults, I wouldn't think it's any
>safer than what we had before).
OK that's fine but if a package compiled against libc6 is not released how
you are going to find out if it is broken or what is broken? I think the
package should be released so users can test it and provide feedback.
Anyway, what seems to be missing for a complete libc6 Samba package is a
libc6 libpam package. Do you know if the maintainer of this package is
releasing a libc6 version soon?
Regards,
E.-
--
Eloy A. Paris
Information Technology Department
Rockwell Automation de Venezuela
Telephone: +58-2-9432311 Fax: +58-2-9431645 Cel.: +58-16-234700
"Where does this path lead?" said Alice
"Depends on where you want to go." Said the cat
("Alice in Wonderland", by Lewis Carroll.)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: