Bug 170

Created attachment 33 [details]
Partial trace output of tusc for failing "sudo"

Do you see the same behavior if you compile sudo yourself on the machine in question?

I don't have the resources to compile the version myself at the moment, but I
had installed the older version 1.6.6 from backup tape. That version runs fine
on a comparable hardware and OS, but on that particular machine it gets a
"Memory Fault" just at the same location at 1.6.8 does. The bug seems to be
related to NIS somehow. I'll try a HP-supported version (Sudo A.03.00-1.6.7p5)
next...

It is possible that the same underlying buffer is being used for both the normal password lookup and the 
shadow password lookup; I have a patch that addressed this and can build you an HP-UX 11.11 binary to 
test.  Is your sudoers file /etc/sudoers or do you use a different path to sudoers?

We had "patch day" on friday, and even with the latest recommended patches and a
reboot, _all_ sudo binaries I had tried (even the HP-supplied version) did crash
on exactly that one machine. As said before the only difference I'm aware of is
that this machine has the local password file, while others are NIS clients.
I don't have the time until thursday, but I'll try to build a debug version from
sources then.

My version uses /etc/sudoers, but other versions that also crashed used
different paths like /opt/something/etc/sudoers.

There are two sudo binaries in ftp://courtesan.com/pub/millert/tmp/
One uses pam, the other does not.  Please download them and install the files as root with mode 4111 and  
see if either one still exhibits the crash.  Thanks!

> There are two sudo binaries in ftp://courtesan.com/pub/millert/tmp/

Are you sure? I only see some ".hex" files with names that don't ring any bell here.

Sorry, I copied them to the wrong ftp server.  I have moved them to the correct place so you should be 
able to grab them now.

Bad news: Both binaries pass running with options "-V", "-v", and "-l", but as
soon as I add some command, both binaries get a "Memory fault" (at the same
location as the other binaries). It would be helpful ti have a binary that does
not suppress core dumps (HP-UX's adb is better than nothing).

At ftp://ftp.sudo.ws/pub/millert/tmp you will find two sudo binaries, one built with gcc, the other with 
HP's C compiler.  Both are built without the coredump disabling and with debugging symbols.  However, 
most OSes disable coredumps for setuid executables so you may only be able to get a core by running 
sudo as root.  If you do manage to get a core from it, I'd love to be able to download that and debug it.

Also, is the crash before or after sudo asks for a password?

I was not very lucky with those binaries: Both reported syntax errors for
comments lines in /etc/sudoers. See attachment that will follow.

Created attachment 34 [details]
terminal output for sudo.gcc and sudo.hpcc, /etc/sudoers file

Why does a comment trigger a syntax error?

Hmm, sounds like either bison or flex on the machine I built the binaries on has issues.  I've rebuilt the 
binaries using the pre-built parser so if you could test again I'd appreciate it.

There's some news: sudo.hpcc does not crash, but sudo.gcc does. According to gdb
it looks like a stack corruption. It happens at the call of sudo.c:412
(set_perms_suid), set_perms.c:194 (runas_setup), set_perms.c:466.
From there I had to single-step every assembler instruction. We entered
initgroups() [/usr/lib/libc.2], __getgroupsbymember(), nss_search(). Somewhere
inside the stack frame gets corrupted.

Wow, that's odd.  Is your libc patch level up to date?

Let me see: "swlist -l product | grep -i libc" reports:
PHCO_25569 (libc cumulative header file patch)
PHCO_28481 (cumulative 10.20 libc compatibility support)
PHCO_29829 (libc manpage cumulative patch)
PHCO_31061 (libc cumulative patch)
PHSS_28303 (LIBCL patch)

This should be the equivalent of installing the latest Support Plus CD (December
2004). BTW: sudo.gcc also gets a Memory Fault on another machine with the same
hard and software (NIS client instead of NIS server). Sudo.hpcc also works
there, however.

Trying again, I have a different backtrace:
set_perms.c:163:setgid() called by logging.c:336:log_auth() called by
set_perms.c:194:set_perms_suid() called by sudo.c:412:main(). "stepi" in gdb
failed at instruction 0x0000a644 (inside setgid): The instruction pointer
suddenly was at 0x6ffea298. Instruction at 0xa644 is "stw rp,-18(sr0,sp)".

Having checked syslog, no logging line made it up to there.

I've put binaries compiled both with and without optimization up on ftp://ftp.sudo.ws/pub/millert/tmp
This time I've also included binaries built from the sudo 1.7 devel tree in case you want to check and see if 
they exhibit the same problem.  I'm also going to try updating gcc on my HP-UX 11.11 machine from 
3.3.2 to 3.3.5.

Is there any way I can get ssh access to one of the machines that exhibits the problem?  It would make 
debugging quite a bit simpler.

I didn't have time to try your binaries earlier, but I just fetched all of them.
I'll give them a try and report back the results. Unfortunately the machine
cannot be reached via Internet. Sorry.

Created attachment 36 [details]
GZIPed tar archive with two GDB log files

Here are the results of the tests:
1.6.8p8: All binaries pass the "-l" parameter, but only the "hpcc" binaries
pass parameters "mount /tmp"; both "gcc" version get a SIGSEGV (but do not dump
core). Here the stack frame seems corrupted.
1.7: All binaries receive a "Bus Error" even for argument "-l". Here the stack
frame seems OK.
I've provided GDB terminal output for the unoptimized GCC binaries. I hope this
helps.

Hmm, looking at the code in question I don't see any errors, nor do I have problems on my HP-UX 11.11 
machine.  However, that is a 32-bit, not 64-bit machine.  I wonder if the root of the problem is simply 32-
bit vs. 64 bit?  My understanding was that 32 bit HP-UX binaries would run on 64-bit HP-UX machines but 
perhaps that is incorrect.  I'll try building binaries on one of HP's 64-bit testdrive machines next week and 
see if that makes any difference.

Any 32-bit application should run in 64-bit HP-UX, especially as most of the
programs that HP ships are still 32-bit apps (it makes little sense to have a
64-bit "cat" for example). So that's probably not the problem. BTW: 64-bit apps
use a completely new fil format (ELF64), so your 32-bit apps are definitely
executed a such (and an int is still 32 bits).

Did I tell you that I'm logged in via HP's Secure Shell? Maybe that makes some
difference...

I'm at building my own binaries. There I've noticed that "configure" has some
problems: For example "strftime() isn't recognized, because gcc reports "error:
conflicting types for 'strftime'". As it seem, the test expects a "char *"
result, while the system's manual page says it's returning a "size_t" (total
number of resulting bytes). There seem to be other odd decisions regarding
supplied library functions. (gettimeofday, utimes, ...)

Wow, this was hard-time debugging: I've found the cause of the problem, and a
work-around, but not the root of the problem: The last line of /etc/group on the
machine was "+:". When removing that line, sudo works, and when adding it back,
sudo gets a full stack corruption, making any backtrace impossible. The effect
is actually triggered from line 466 of set_perms.c by "initgroups(*user_runas,
runas_pw->pw_gid)". In my case the user was "root", and the gid was "3" (sys),
both locally defined in file /etc/group.
If you can reproduce the problem with a HP-CC compiled binary, I could file a
bug report at HP. Currently there is no patch dealing with this issue available.

The ultimate final experience: The following program works fine with HP's
bundled "cc", but fails (memory faiult) with gcc (3.4.3):
main()
{
    initgroups("root", 3);
}

Those interested in the GCC issue might visit the bug I've filed
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21719).

Closing this as it appears to be a compiler or libc bug, not a sudo bug.