The restricted telnet shell on the D-Link DSL2730U router allows remote authenticated users to bypass intended command restrictions via shell metacharacters that follow a whitelisted command.

**D-Link DSL2730U router restricted telnet shell command whitelisting bypass**

**Vulnerability Note VU#876780**

Original Release Date: 2012-12-12 | Last Revised: 2012-12-12

**Overview**

D-Link DSL2730U routers contain a restricted telnet shell with limited allowed commands. An authenticated attacker can chain unauthorized commands through authorized commands in order to bypass the command whitelisting.

**Description**

CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'):

D-Link DSL2730U routers contain a restricted telnet shell with limited allowed commands. Commands entered in the restricted telnet shell are executed by passing them as command parameters of execution "sh -c", for example, "echo | ls" will result in passing a whitelisted command (echo) and executing "sh -c echo | ls" on the underlying Linux environment. The STDOUT output of the command execution is returned to the telnet terminal. An authenticated attacker can chain unauthorized commands through authorized commands in order to bypass the command whitelisting.

**Impact**

An authenticated attacker can chain unauthorized commands through authorized commands in order to bypass the command whitelisting.

**Solution**

We are currently unaware of a practical solution to this problem.

**Restrict Access**

As a general good security practice, only allow connections from trusted hosts and networks. Restricting access would prevent an attacker from accessing an telnet interface using the affected credentials from a blocked network location.

**Vendor Information**

Filter by content: Additional information available

 Sort by:

  
**CVSS Metrics**

Group

Score

Vector

Base

6.8

AV:N/AC:L/Au:S/C:C/I:N/A:N

Temporal

5.2

E:POC/RL:W/RC:UC

Environmental

1.4

CDP:L/TD:L/CR:ND/IR:ND/AR:ND

  
**References****Acknowledgements**

Thanks to Nikolay Dachev for reporting this vulnerability.

This document was written by Michael Orlando.

**Other Information**

**CVE IDs:**

CVE-2012-5966

**Date Public:**

2012-12-12

**Date First Published:**

2012-12-12

**Date Last Updated:**

2012-12-12 12:27 UTC

**Document Revision:**

7

CVE-2012-5966: CERT/CC Vulnerability Note VU#876780

login in Slackware 7.0 allows remote attackers to identify valid users on the system by reporting an encryption error when an account is locked or does not exist.

**\[prev in list\] \[next in list\] \[prev in thread\] \[next in thread\]** 
**List:       bugtraq
Subject:    Slackware 7.0 - login bug
From:       Stewart Gebbie <stewart () global ! co ! za>
Date:       1999-12-02 15:30:46
\[Download RAW message or body\]**

Hi,

Below I describe a bug in Slackware 7.0. I did notify
support@slackware.com about a week ago and thought that
it was about time to send the bug report to bugtraq.

This is regarding a logic but in the shadow suite that enables
a brute force attack for finding and cracking login in accounts
via telnet (and possibly some other nasty side affects).

The bug comes about as a result of the interplay between
using md5\_crypt and disabling the traditional crypt.

The bug occurs when either an account is locked or the account
does not exits. In either case the result is that login.c
makes a call to pw\_auth() in pwauth.c with the password set to
"!". This in turn calls \_old\_auth() in pwauth.c. This finally
calls pw\_encrypt() in encrypt.c. Now because the password is set
to "!" (and not "$1$") the md5\_crypt function is not called.
Instead the tradition crypt() is called. This has, as far as I
can see, been disabled in the Slack 7.0 distribution and always
returns NULL and sets errno=95. This causes pw\_encrypt() to
print out \`crypt: Operation not supported' and immediatly call
exit(1). Hence, from logging in one can see that the user name
does not exist or is locked, further more the exit is immediate
with no sleep before prompting again.

I did not confirm that crypt() was disabled in the glibc source
(simply because it meant downloading all of the glibc source).
But the test program I wrote did seem to confirm this.

Thanks
Stewart

**\[prev in list\] \[next in list\] \[prev in thread\] \[next in thread\]** 

  

Configure | About | News | Add a list | Sponsored by KoreLogic

CVE-1999-0856: 'Slackware 7.0 - login bug'

Denial of service in Cisco routers running NAT via a PORT command from an FTP client to a Telnet port.

CVE-1999-0843: IBM X-Force Exchange

Lynx WWW client allows a remote attacker to specify command-line parameters which Lynx uses when calling external programs to handle certain protocols, e.g. telnet.

CVE-1999-0817: IBM X-Force Exchange

Buffer overflow in Solaris libc, ufsrestore, and rcp via LC_MESSAGES environmental variable.

**\[prev in list\] \[next in list\] \[prev in thread\] \[next in thread\]** 
**List:       bugtraq
Subject:    Re: Linux NLSPATH buffer overflow
From:       Alan Cox <alan () LXORGUK ! UKUU ! ORG ! UK>
Date:       1997-02-14 20:51:02
\[Download RAW message or body\]**

> I'm sorry if the information I'm going to tell about was already known, but
> I hope it wasn't...

Its known, its fixed in current setups

> It might be possible to exploit this hole remotely, if using a patched telnet
> client which would allow exporting large environment variable values. The
> overflow would happen at /bin/login startup then (somewhat like the famous
> LD\_PRELOAD exploit, but an overflow). I'm not sure of that though, there might
> be some restrictions on environment variables in telnetd.

Netkit 0.08/9 telnetd do not pass any environment variables,

> As for the fix, well, this is a hard one -- would require re-compiling libc,
> and statically linked binaries. To protect yourself against remote attacks,
> you could for example change the variable name to something different, with
> a hex editor (like /usr/bin/bpe), in /lib/libc.so.5, and ensure the exploit
> stopped working. Of course, this is only a temporary fix.

libc5.4 is immune, RedHat has been shipping the fixed libc5.3.12 for a long
time, and all the vendors I had security contacts for where told ages ago.
If they haven't fixed it then Im disappointed with them, they dont have
an excuse. That libc5.3.12 unpatched also has other fun bugs with buffer
overruns in libc some in the BSD stuff akin to the BSD bugs in rcmd() etc.

Alan

**\[prev in list\] \[next in list\] \[prev in thread\] \[next in thread\]** 

  

Configure | About | News | Add a list | Sponsored by KoreLogic

CVE-1999-0767: 'Re: Linux NLSPATH buffer overflow'

Denial of service through Solaris 2.5.1 telnet by sending ^D characters.

Tag

#telnet