openssh unix dev - Mar 2003 - cvs version / testing

Hello,

I pulled the latest from cvs today and ran several tests
and added more options to the CFLAGS in the Makefile. To
start with, I ran valgrind against sshd & it comes up with
this:

==24959== 112 bytes in 1 blocks are definitely lost in loss
record 297 of 310
==24959==    at 0x40164650: malloc (vg_clientfuncs.c:100)
==24959==    by 0x807A0D1: compat_init_setproctitle
(setproctitle.c:236)
==24959==    by 0x804D606: main (sshd.c:839)
==24959==    by 0x403444CD: __libc_start_main (in
/lib/libc-2.2.93.so)
==24959==    by 0x804C4E0: (within /opt/openssh/sshd)
==24959===24959== LEAK SUMMARY:
==24959==    definitely lost: 112 bytes in 1 blocks.
==24959==    possibly lost:   0 bytes in 0 blocks.
==24959==    still reachable: 8532 bytes in 340 blocks.
==24959==         suppressed: 0 bytes in 0 blocks.
==24959== Reachable blocks (those to which a pointer was
found) are not shown.
==24959== To see them, rerun with: --show-reachable=yes

This occurs several times in the output.

Next, I ran env_audit against the deamon. The stdin,
stdout, & stderr descriptors have changed since version
3.5p1. This is what env_audit finds: 

Open file descriptor: 0
User ID of File Owner: root
Group ID of File Owner: root
Descriptor is stdin.
No controlling terminal
File type: socket
Address Family: AF_INET
Local address: 192.168.3.30
Local Port: 1, tcpmux
NOTICE - connected to a privileged port
Peer address: 192.168.3.30
Peer Port: 55290

Now, the local side binds to port 1, which is tcpmux's
service port. What happens if someone wanted to so
something like this:

ssh -l me localhost "telnet localhost tcpmux <
command_file"

I don't know how often someone would want to do that or run
an application that accesses tcpmux remotely, but by using
pipes, this problem never existed. If sockets are the way
to go, it might be better to use a port higher up/ephemeral
so that no service is blocked.

I also added -W -Wshadow and found many more places that
variables shadow function names. The worst ones were rand &
socket. Rather than list them here, you can just add
-Wshaow  to find them.

The last thing, flexelint says that line 207 of vis.c has
an assignment of auto variable to outerscope symbol dst. I
looked at it and I'm not sure its a problem, but I'd rather
pass it along just in case.

Hope you find this feedback useful.

-Steve Grubb

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Hello,

The tcpmux report was a mistake on my part, please ignore
that part of the e-mail.

I also have some more memory leaks to share from a longer
valgrind session:

==31863== 1 bytes in 1 blocks are definitely lost in loss
record 1 of 387
==31863==    at 0x40164650: malloc (vg_clientfuncs.c:100)
==31863==    by 0x8070044: xmalloc (xmalloc.c:28)
==31863==    by 0x80633D9: buffer_get_string (bufaux.c:230)
==31863==    by 0x805C6A2: mm_answer_keyallowed
(monitor.c:777)
==31863==    by 0x805BE89: monitor_read (monitor.c:371)
==31863==    by 0x805BB9E: monitor_child_preauth
(monitor.c:280)
==31863==    by 0x804CF97: privsep_preauth (sshd.c:600)
==31863==    by 0x804DEFE: main (sshd.c:1532)
==31863=

AND this one:


==31863== 4 bytes in 1 blocks are definitely lost in loss
record 6 of 387
==31863==    at 0x40164B3D: calloc (vg_clientfuncs.c:242)
==31863==    by 0x4022D162: _copy_env (in
/lib/libpam.so.0.75)
==31863==    by 0x414348F7: ???
==31863==    by 0x41433D0D: ???
==31863==    by 0x4022ABA8: _pam_dispatch_aux (in
/lib/libpam.so.0.75)
==31863==    by 0x4022AD32: _pam_dispatch (in
/lib/libpam.so.0.75)
==31863==    by 0x4022C997: pam_close_session (in
/lib/libpam.so.0.75)
==31863==    by 0x80613E1: do_pam_cleanup_proc
(auth-pam.c:183)


These two leaks occur over and over. Hope this helps &
sorry for the confusion about tcpmux.

-Steev Grubb

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com