core dump using pam authentication

[Marco Salvi]

Hi Dennes,

> Who printed this poor stack trace? Where are the hex addresses and function offsets?

This is not a real stack trace. I've got this running my program in gdb with

set heap-check on
set heap-check string on

After a while the program execution has been interrupted and I have got the stack trace I have sent you.

I don't have same context available but I remember that bt command shown a stack trace starting form the pam_end call and containing a free() when the gdb stop whit the memory corruption messsage.

I think I need someone that have access to pam_sm_authenticate code in order to understand what is going on there

[Dennis Handly]

>I don't have same context available but I remember that bt command shown a stack trace starting form the pam_end call and containing a free()

That seems reasonable, pam_end is where the memory has to be cleaned up. But it is the code that moves "Password" that has the problem.

>I think I need someone that have access to pam_sm_authenticate code

I'll see if I have access.

[Marco Salvi]

About your previous observation regarding the fact that all that structure look to be corrupted, I think you were right.
I run a single thread program and that structure look completely different:

from info heap
...
8 260 1 0x60000000008b8ed0 pam_sm_authenticate()
...

x/16gx 0x60000000008b8ed0
0x60000000008b8ed0: 0x0000000100000000 0x0000000000000000
0x60000000008b8ee0: 0x0000000000000000 0x0000000000000000
0x60000000008b8ef0: 0x0000000000000000 0x0000000000000000
0x60000000008b8f00: 0x0000000000000000 0x0000000000000000
0x60000000008b8f10: 0x0000000000000000 0x0000000000000000
0x60000000008b8f20: 0x0000000000000000 0x0000000000000000
0x60000000008b8f30: 0x0000000000000000 0x0000000000000000
0x60000000008b8f40: 0x0000000000000000 0x0000000000000000

In the case of corruption this structure is plenty of values like 9ffff.. that look like stack addresses

Anyway I don't know whether or not that means anything.

[Dennis Handly]

>About your previous observation regarding the fact that all that structure look to be corrupted, I think you were right.
>I run a single thread program and that structure look completely different:

At least that 1 is there:
0x60000000008b8ed0: 0x00000001

>Anyway I don't know whether or not that means anything.

Perhaps not.

>I think I need someone that have access to pam_sm_authenticate code

Basically "Password: " is passed to:
__pam_get_i18n_msg(pamh, "pam_unix", 1, 31, "Password: ") (which calls catgets) and the result copied to the stack, with 512 bytes of space.
This local, prompt, is then passed to:
__pam_get_authtok(pamh, PAM_PROMPT, PAM_AUTHTOK, passwd_len, prompt, &password)

In _pam_get_authtok, it is again copied to a local:
strncpy(messages[0], prompt, sizeof (messages[0]));

messages is passed to __pam_get_input then to __pam_input_output (4th parm).

Which passes this to your convert function as msg.

[Marco Salvi]

Hi Dennis,
I've just ask HP support to deal with this problem but I have really appreciated your help on this.
At the moment I've been able to recreate it in more simple program.

Basically I've written a java program that load my shared library with pam code and do some sql query on oracle database.

Running this program in the debugger with

set heap-check on
set heap-check string on

I've got this

[Switching to thread 14 (system thread 229340)]
warning: Memory block (size = 260 address = 0x6000000001387af0) appears to be corrupted at the end.
Allocation context not found

#1 pam_sm_authenticate() from /usr/lib/security/hpux64/libpam_unix.so.1
#2 pam_authenticate() from /usr/lib/hpux64/libpam.so.1
#3 PamUnixRegistryImpl_checkPassword() from /local/tws83/appserver/lib/ext/libtwspamjni.so
#4 Java_com_ibm_tws_pam_security_registry_PamUnixRegistryImpl_pam_1authenticate() from /local/tws83/appserver/lib/ext/libtwspamjni.so
warning: Use command backtrace (bt) to see the current context.

Ignore top 4 frames belonging to leak detection library of gdb.

__rtc_event () at ../../../Src/gnu/gdb/infrtc.c:1329
1329 ../../../Src/gnu/gdb/infrtc.c: No such file or directory.
in ../../../Src/gnu/gdb/infrtc.c
Current language: auto; currently c

The same program without using jdbc driver doesn't report any memory corruption.

I'll try to do some more debug on this but I hope hp support will come to a solution soon

Thanks again for your help and all the debugger tips you have taught me

[Dennis Handly]

>At the moment I've been able to recreate it in more simple program.

That's good.

> #1 pam_sm_authenticate .../hpux64/libpam_unix.so.1

Can you use "bt" to get a real stack trace? It would be nice to know the offset in pam_sm_authenticate.

[Marco Salvi]

Running bt after this memory corruption information return something like this

warning: Memory block (size = 260 address = 0x60000000012e7af0) appears to be corrupted at the end.
Allocation context not found

#1 pam_sm_authenticate() from /usr/lib/security/hpux64/libpam_unix.so.1
#2 pam_authenticate() from /usr/lib/hpux64/libpam.so.1
#3 PamUnixRegistryImpl_checkPassword() from /local/tws83/appserver/lib/ext/libtwspamjni.so
#4 Java_com_ibm_tws_pam_security_registry_PamUnixRegistryImpl_pam_1authenticate() from /local/tws83/appserver/lib/ext/libtwspamjni.so
warning: Use command backtrace (bt) to see the current context.

Ignore top 4 frames belonging to leak detection library of gdb.

__rtc_event () at ../../../Src/gnu/gdb/infrtc.c:1329
1329 ../../../Src/gnu/gdb/infrtc.c: No such file or directory.
in ../../../Src/gnu/gdb/infrtc.c
Current language: auto; currently c
(gdb) bt
#0 __rtc_event () at ../../../Src/gnu/gdb/infrtc.c:1329
#1 0x87ffffffbf73ee60:0 in check_bounds (pointer=0x60000000012e7af0,
size=260, pclist=0x600000000104c568) at ../../../Src/gnu/gdb/infrtc.c:1437
#2 0x87ffffffbf743ea0:0 in rtc_record_free ()
at ../../../Src/gnu/gdb/infrtc.c:2463
#3 0x87ffffffbf7458a0:0 in free () at ../../../Src/gnu/gdb/infrtc.c:2789
#4 0x87ffffff7f3b8c60:0 in + 0x40 ()
from /usr/lib/security/hpux64/libpam_unix.so.1
#5 0x87ffffffbde07670:0 in pam_end+0x280 () from /usr/lib/hpux64/libpam.so.1

I'm wondering in there is a way to lock on this 260 bytes of memory in order to discover what is corrupting it

[Dennis Handly]

>Allocation context not found
#1 pam_sm_authenticate() .../libpam_unix.so.1

This must be where it is allocated. My gdb 5.7.4 says: Allocation context might not be correct.

The only calloc in pam_sm_authenticate allocates a 260 byte struct:
typedef struct _unix_auth_data_ {
int key_status;
char netname[255+1];
} unix_auth_data;

The pointer is stored in some magic structure set/get by pam_get_data/pam_set_data, part of pam_handle_t.

#4 0x87ffffff7f3b8c60:0 in + 0x40

This is probably unix_cleanup, who cleans up the pam_set_data linked list, containing those unix_auth_data.

>I'm wondering in there is a way to lock on this 260 bytes of memory in order to discover what is corrupting it

Well you can set a hardware watch point if the address doesn't change:
(gdb) watch *(char (*) [260])0x60000000012e7af0

Have you tried pam debugging?
Do a google search for: /etc/pam_debug site:hp.com

For some reason the pdf link isn't there but the "View as HTML" link gives it: ...
To enable tracing the native PAM library, turn on debugging on syslog level
(the steps needed may vary for the different UNIX flavors). The related service
name is auth. To turn on tracing, configure syslogd as in the following
Page 156
Configuration Value Pack 3.0.3 Installation and Administration Guide

example:
# touch /etc/pam_debug
# vi /etc/syslog.conf
auth.debug /tmp/pam_auth.log

[Dennis Handly]

It looks like they may have figured it out. There was a strcpy to this field:
char netname[255+1];

But the source was uninitialized.

[Marco Salvi]

Thank you Dennis for all your help and

Merry Christmas