search for: channels_alloc

This is the 1st revision of the Advisory. This document can be found at: http://www.openssh.com/txt/buffer.adv 1. Versions affected: All versions of OpenSSH's sshd prior to 3.7 contain a buffer management error. It is uncertain whether this error is potentially exploitable, however, we prefer to see bugs fixed proactively. 2. Solution: Upgrade to OpenSSH

...eving revision 1.194 retrieving revision 1.195 diff -u -r1.194 -r1.195 --- channels.c 29 Aug 2003 10:04:36 -0000 1.194 +++ channels.c 16 Sep 2003 21:02:40 -0000 1.195 @@ -228,12 +228,13 @@ if (found == -1) { /* There are no free slots. Take last+1 slot and expand the array. */ found = channels_alloc; - channels_alloc += 10; if (channels_alloc > 10000) fatal("channel_new: internal error: channels_alloc %d " "too big.", channels_alloc); + channels = xrealloc(channels, + (channels_alloc + 10) * sizeof(Channel *)); + channels_alloc += 10; debug...

This is the 1st revision of the Advisory. This document can be found at: http://www.openssh.com/txt/buffer.adv 1. Versions affected: All versions of OpenSSH's sshd prior to 3.7 contain a buffer management error. It is uncertain whether this error is potentially exploitable, however, we prefer to see bugs fixed proactively. 2. Solution: Upgrade to OpenSSH

...osity I was looking at the patch for CVE-2002-0083 and tried to understand what the actual problem is, but failed: --- channels_old.c?? ?Mon Mar? 4 02:07:06 2002 +++ channels.c?? ?Mon Mar? 4 02:07:16 2002 @@ -151,7 +151,7 @@ ?channel_lookup(int id) ?{ ??? ?Channel *c; -?? ?if (id < 0 || id > channels_alloc) { +?? ?if (id < 0 || id >= channels_alloc) { ??? ??? ?log("channel_lookup: %d: bad id", id); ??? ??? ?return NULL; ??? ?} What does that mean? If id is less than 0 (are we talking about the unix uid?) or id greater than channels_alloc - log & return null) Is this check for...

When I encounter the problem with TCP port forwarding locking up, I'll see this on the client window (if I haven't invoked ssh with -q): chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected This is with Blowfish encryption. I have to kill and restart the client when this happens. Phil

...================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; }

...================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; }

...================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; }

...================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; }

Hi! I am resending the following message about problems with utmp handling. * In the meantime I had some request in private mail from people asking whether I have new information. * The problem is still persistant in 2.9p2. * My own new investigations show, that the problem only appears with protocol 2, not with protocol 1, I therefore only started to note it when protocol 2 became the

...:26:17.119989982 +0200 @@ -2865,6 +2865,52 @@ return success; } +/* + * Write list of remote forwarding ports into an existing buffer + */ +void +channel_list_rport_listener(char *buf, size_t size) +{ + u_int i, j, num_ports = 0; + int offset = 0; + int *ports; + int skip; + + ports = xcalloc(channels_alloc, sizeof(int)); + + for (i = 0; i < channels_alloc; i++) { + skip = 0; + Channel *c = channels[i]; + if (c == NULL || c->type != SSH_CHANNEL_RPORT_LISTENER) + continue; + + /* Skip already added ports - IPv4 + IPv6 == same port twice */ + for(j = 0; j < num_ports; j++) { + if (port...

...sts, eg. SSH_REMOTE_FORWARD_PORT_1, SSH_REMOTE_FORWARD_PORT_2, .... I was able to wedge a proof of concept into session.c:do_setup_env (patch below). It's a hack because there doesn't seem to be an API to iterate channels outside of channels.c. Would it be agreeable to export channels and channels_alloc? Also, struct Channel doesn't let you tell which forwards were dynamically allocated, so an environment variable is set for all RemoteForwards. This could be changed by extending struct Channel, though it isn't a show-stopper for me. Last thought: if a new protocol request type were added...

...ex 1b310e3..111c808 100644 --- a/channels.c +++ b/channels.c @@ -886,6 +886,23 @@ channel_still_open(struct ssh *ssh) return 0; } +/* Returns true if a channel with a TTY is open. */ +int +channel_tty_open(struct ssh *ssh) +{ + u_int i; + Channel *c; + + for (i = 0; i < ssh->chanctxt->channels_alloc; i++) { + c = ssh->chanctxt->channels[i]; + if (c == NULL || c->type != SSH_CHANNEL_OPEN) + continue; + if (c->client_tty) + return 1; + } + return 0; +} + /* Returns the id of an open channel suitable for keepaliving */ int channel_find_open(struct ssh *ssh) diff --git a/chan...

...| Mobile: +358 40 5388169 -------------- next part -------------- diff -u -r openssh-2.1.1p4/channels.c openssh-2.1.1p4-jhchanges/channels.c --- openssh-2.1.1p4/channels.c Mon Jun 26 03:22:53 2000 +++ openssh-2.1.1p4-jhchanges/channels.c Sun Aug 13 02:22:42 2000 @@ -59,6 +59,9 @@ */ static int channels_alloc = 0; +/* Jarno: Needed to check if port_forwarding is allowed */ +extern ServerOptions options; + /* * Maximum file descriptor value used in any of the channels. This is * updated in channel_allocate. @@ -1506,15 +1509,12 @@ u_short port_to_connect) { int payload_len; + int type;...

...else { + user_authenticated_as_root = 0; } xfree(service); diff -u -r openssh-2.1.1p4/channels.c openssh-2.1.1p4-jhchanges/channels.c --- openssh-2.1.1p4/channels.c Mon Jun 26 03:22:53 2000 +++ openssh-2.1.1p4-jhchanges/channels.c Wed Aug 23 09:27:47 2000 @@ -59,6 +59,12 @@ */ static int channels_alloc = 0; +/* Jarno: Needed to check if port_forwarding is allowed */ +int allow_port_forwarding; +int user_authenticated_as_root; /* This could be uid so we could log who + * tried to forward ports. + */ + /* * Maximum file descriptor value used in any of the channe...

...et_get_string(NULL); + port_to_bind = packet_get_int(); + + /* Lookup the channel listening for this port: + First see if the channel type is SSH2_CHANNEL_PORT_LISTENER and then + compare port/addr. + TODO: Is it safe to use strcmp on address_to_bind ? + */ + for (chan = 0; chan < channels_alloc; chan++) { + if ( channels[chan].type == SSH2_CHANNEL_PORT_LISTENER ) { + if ( channels[chan].listening_port == port_to_bind && + (strcmp(address_to_bind, channels[chan].path) == 0) ) + break; + } + } + + if ( chan < channels_alloc ) { + /* We have a winner -->...

I am running OpenSSH 2.9p1 on SunOS 5.7 w/4-24-2001 patch cluster. Like many other users I am seeing the hanging session on logout with background processes. This is a huge problem for me as I centrally manage 50+ machines with rdist across ssh. Instead of just complaining about the problem I thought I would put my CS degree to use and try to track down the problem myself. For starters,

I'm reading this fine article on O'Reilly: http://linux.oreillynet.com/lpt/a//linux/2001/11/08/ssh_keystroke.html <quote> The paper concludes that the keystroke timing data observable from today's SSH implementations reveals a dangerously significant amount of information about user terminal sessions--enough to locate typed passwords in the session data stream and reduce the

Hello, In response to the timing analysis attacks presented by Dawn Song et. al. in her paper http://paris.cs.berkeley.edu/~dawnsong/ssh-timing.html we at Silicon Defense developed a patch for openssh to avoid such measures. Timing Analysis Evasion changes were developed by C. Jason Coit and Roel Jonkman of Silicon Defense. These changes cause SSH to send packets unless request not to,