[meta-freescale] Etherleak detected from NESSUS security scan

[Zhenhua Luo]

Hello Sona,

Please see the inline feedback from NXP SDK team.


Best Regards,

Zhenhua

From: Sona Sarmadi [mailto:sona.sarmadi at enea.com]
Sent: Thursday, August 18, 2016 2:14 AM
To: meta-freescale at yoctoproject.org
Cc: Ting Liu <ting.liu at nxp.com>; 'Luo Zhenhua' <zhenhua.luo at freescale.com>; 'Liu Ting' <ting.liu at freescale.com>; Jennifer Mir <jennifer.mir at enea.com>; Thomas Lundström <Thomas.Lundstrom at enea.com>
Subject: Etherleak detected from NESSUS security scan


Hi guys,



Nessus scan reports a vulnerability in the FSL/NXP DPAA Linux Ethernet driver (on P2041, linux-qoriq-sdk/3.8-r11.1):

[Luo Zhenhua] May I know which SDK is used? There have been more than one SDK based on 3.8? Has this scanner been run against a system running SDK 2.0?  Can it be? Which MAC type (dtsec or tgec) was this seen with?  Is there any information about specific packet data it saw?



Scan report:
11197 - Multiple Ethernet Driver Frame Padding Information Disclosure (Etherleak)
Synopsis
The remote host appears to leak memory in network packets.
Description
The remote host uses a network device driver that pads ethernet frames with data which vary from one packet to
another, likely taken from kernel memory, system memory allocated to the device driver, or a hardware buffer on its
network interface card.
Known as 'Etherleak', this information disclosure vulnerability may allow an attacker to collect sensitive information
from the affected host provided he is on the same physical subnet as that host.
See Also
http://www.nessus.org/u?719c90b4
Solution
Contact the network device driver's vendor for a fix.
Risk Factor
Low
CVSS Base Score
3.3 (CVSS2#AV:A/AC:L/Au:N/C:P/I:N/A:N)
CVSS Temporal Score
2.9 (CVSS2#E:ND/RL:OF/RC:C)
References
BID 6535

CVE CVE-2003-0001



According to NVD this vulnerability affects Linux kernel 2.4.1 - 2.4.9 (cpe:/o:linux:linux_kernel:2.4.9) but it seems that this vulnerability exist in the 3.8 kernel (according to Nessus scan).



References: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2003-0001)

Example of ethernet driver patch can be found at:
https://www.cs.helsinki.fi/linux/linux-kernel/2003-06/1091.html



The "etherleak_fix" is fixed in drivers/net/net_init.c:

void ether_setup



/* New-style flags. */

dev->flags = IFF_BROADCAST|IFF_MULTICAST;

+

+ /* TBD: xmit_hook should ideally be part of "net_device" struct */

+ netif_xmit_hook = etherleak_fix;    <<<<<<<<<<<<<<<<<

+

[Luo Zhenhua] No, it's not.  That was a proposed fix but what was actually done was to fix individual drivers.

https://www.cs.helsinki.fi/linux/linux-kernel/2003-06/1091.html

https://www.cs.helsinki.fi/linux/linux-kernel/2003-06/1153.html



I need to confirm that the FSL driver is handling padding properly, could you please help me with this?

There seems to be no software padding, instead I assume the HW is doing the padding. Is this correct?

[Luo Zhenhua] Yes



Is this where the HW is configured to do the padding?



linux-qoriq-sdk/3.8-r11.1/git# vim drivers/net/ethernet/freescale/dpa/mac-api.c



..

if (macdev2enetinterface(mac_dev) != e_ENET_MODE_XGMII_10000) {

                /* 10G always works with pad and CRC */

                _errno = fm_mac_config_pad_and_crc(priv->fm_mac, true);

[Luo Zhenhua] Unless things were different in "3.8-r11.1" compared to SDK 2.0, this call has no effect because all three MAC types default to having this enabled.

For DTSEC padding is enabled by MACCFG2[PAD/CRC] which is set in fman_dtsec_init().

For TGEC the source code claims that it always pads, though from a quick search I couldn't find an explicit statement of that in the hardware documentation.





linux-qoriq-sdk/3.8-r11.1/git# vim drivers/net/ethernet/freescale/fman/src/wrapper/lnxwrp_fm.c
...

int fm_mac_config_pad_and_crc(struct fm_mac_dev *fm_mac_dev, bool enable)
{
        int err;
        int _errno;

        err = FM_MAC_ConfigPadAndCrc(fm_mac_dev, enable);
        _errno = -GET_ERROR_TYPE(err);
        if (unlikely(_errno < 0))
                pr_err("FM_MAC_ConfigPadAndCrc() = 0x%08x\n", err);

        return _errno;
}



Thanks

//Sona

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20160822/fb2dbbbf/attachment.html>