From dave.taht at gmail.com  Thu Dec  1 12:18:08 2022
From: dave.taht at gmail.com (Dave Taht)
Date: Thu, 1 Dec 2022 09:18:08 -0800
Subject: [Cerowrt-devel] Fwd: Remote code execution bug in FreeBSD's ping
	(CVE-2022-23093)
In-Reply-To: <DM4PR18MB4254443C49D441785E22DF20AB149@DM4PR18MB4254.namprd18.prod.outlook.com>
References: <DM4PR18MB4254443C49D441785E22DF20AB149@DM4PR18MB4254.namprd18.prod.outlook.com>
Message-ID: <CAA93jw7-48fV4yLQKNECw4cnaLh_mny23PXGUyQeZjyedhDb1Q@mail.gmail.com>

ping.

---------- Forwarded message ---------
From: Mike Lewinski via NANOG <nanog at nanog.org>
Date: Thu, Dec 1, 2022 at 9:16 AM
Subject: Remote code execution bug in FreeBSD's ping (CVE-2022-23093)
To: nanog at nanog.org <nanog at nanog.org>


Ooof.

https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc

Some hope here: "The ping process runs in a capability mode sandbox on
all affected versions of FreeBSD and is thus very constrainted in how
it can interact with the rest of the system at the point where the bug
can occur."

Lots of other things are based on FreeBSD and may be affected,
including firewalls like pfsense and OPNsense and possibly Junos. At
the least I expect host discovery is ramping up by now.


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC

From dave.taht at gmail.com  Thu Dec 22 11:50:02 2022
From: dave.taht at gmail.com (Dave Taht)
Date: Thu, 22 Dec 2022 08:50:02 -0800
Subject: [Cerowrt-devel] Fwd: Ethernet switch with linux/openwrt and DSA
In-Reply-To: <CAFED-j=UTkYGR303BDUPz4EOQbwTVAevckPvpGVsxrxJS0_g0A@mail.gmail.com>
References: <CAFED-jnGsmfYZROG100vRObjBvcj8Wbug2Lr4r4KaNP=1-R=pQ@mail.gmail.com>
 <e40f3b3f-ebdd-5695-49a7-3779ec907b4e@3e8.eu>
 <537fc9dd-8197-d24d-4304-899e85bc8172@3e8.eu>
 <CAFED-jnkqNVhvMEY+2mk8Tf3GmA6-6qTKCS8mDSfQEGny_=93w@mail.gmail.com>
 <CAJq09z6N9M-wdj87bf9o6UCVwv1Xa65x9YLEguxaiLQ6mDzpUg@mail.gmail.com>
 <CAFED-j=UTkYGR303BDUPz4EOQbwTVAevckPvpGVsxrxJS0_g0A@mail.gmail.com>
Message-ID: <CAA93jw58aWtV4HWaWSoLAUwzPeKeuyUVC=nePJiBV7H4anWtxw@mail.gmail.com>

One of the things I find terrifying is knowing that new products are
still being delivered with linux 2.6 underneath.



---------- Forwarded message ---------
From: Janusz Dziedzic <janusz.dziedzic at gmail.com>
Date: Thu, Dec 22, 2022 at 8:26 AM
Subject: Re: Ethernet switch with linux/openwrt and DSA
To: Luiz Angelo Daros de Luca <luizluca at gmail.com>
Cc: Jan Hoffmann <jan at 3e8.eu>, OpenWrt Development List
<openwrt-devel at lists.openwrt.org>


czw., 22 gru 2022 o 02:24 Luiz Angelo Daros de Luca
<luizluca at gmail.com> napisał(a):
>
> > Thanks all!
> > Finally buy: D-LINK DGS-1210-48 G1.
> >
> > U-Boot 2011.12.(2.1.5.67086)-Candidate1 (Apr 13 2017 - 13:58:11)
> >
> > Board: RTL839x CPU:700MHz LXB:200MHz MEM:400MHz
> > DRAM:  128 MB
> > SPI-F: 1x32 MB
> >
> > Next:
> >  - connected serial cable
> >  - stop in uboot
> >  - boot from tftp/openwrt-realtek-rtl839x-d-link_dgs-1210-52-initramfs-kernel.bin
> >  - next simple scp/sysupgrade
> > openwrt-realtek-rtl839x-d-link_dgs-1210-52-squashfs-sysupgrade.bin
>
>
> Great news! Interesting, is it the same model as 1210-52 but with the
> extra ports as non combo? Or are SFP+ still combo ports with 45-48
> ports? Currently 49-52 they are disabled in -52 variant but they might
> introduce a problem if someone gets that fixed and they are missing in
> your device. Ports are statically defined in the DTS file and they
> might brick the device if missing.
>
Ports 49-52 seems to be "shared" I have both eth and sfp ports with
same numbers (btw eth ports 49-52 don't work correctly)

> Did you try the image1 firmware? It should work from the web interface
> but you need to write it to the image1, not image2 slot. If it is that
> close to F1 series, might be able to dual boot the device back to the
> original firmware. If that doesn't work, we might need to change some
> flags in the dlink image generator. Is the original firmware shared
> between -f1 and -g1 series?
>
>From original GUI/SW wasn't able to change image1/image2 - only config1/config2.
Because of that decide to run directly from uboout and RAM via tftp -
just to check if will up correctly.
But original SW show double mtds for kernel/rootfs - so maybe only GUI issue?

Linux version 2.6.19 (jonathan at 210Server) (gcc version 3.4.4
mipssde-6.03.00-20051020) #2 PREEMPT Fri Oct 6 14:29:30 CST 2017
CPU revision is: 00019555
Determined physical RAM map:
 memory: 02000000 @ 00000000 (usable)
User-defined physical RAM map:
 memory: 07900000 @ 00000000 (usable)
Built 1 zonelists.  Total pages: 30734
Kernel command line: console=ttyS0,115200 mem=121M noinitrd
root=/dev/mtdblock4 rw rootfstype=squashfs csb=0x0157CCD6
cso=0x0794DD64 csf=0x42662D12 sfin=<NULL>,32MB,8376352;8335392
Primary instruction cache 32kB, physically tagged, 4-way, linesize 32 bytes.
Primary data cache 32kB, 4-way, linesize 32 bytes.
Synthesized TLB refill handler (20 instructions).
Synthesized TLB load handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
Cache parity protection disabled
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 120320k/123904k available (1786k kernel code, 3460k reserved,
393k data, 104k init, 0k highmem)
Mount-cache hash table entries: 512
Checking for 'wait' instruction...  available.
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 4096 bind 2048)
TCP reno registered
squashfs: version 3.3 (2007/10/31) Phillip Lougher
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver $Revision: 1.1.1.1 $ 1 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 31) is a 16550A
Probe: SPI CS1 Flash Type MX25L25635F
Creating 9 MTD partitions on "Total SPI FLASH":
0x00000000-0x00080000 : "BOOT"
0x00080000-0x000c0000 : "BDINFO"
0x000c0000-0x00100000 : "BDINFO2"
0x00100000-0x00280000 : "KERNEL1"
0x00280000-0x00e80000 : "ROOTFS1"
0x00e80000-0x01000000 : "KERNEL2"
0x01000000-0x01040000 : "SYSINFO"
0x01040000-0x01c40000 : "ROOTFS2"
0x01c40000-0x02000000 : "JFFS2"
TCP cubic registered

> I would include a new DTS file/firmware generation, even if it only
> includes/copies -52 variant. It would make the lives of newcomers much
> easier.
>

G1 - have dedicated SW - DGS-1210-48-G1-7-00-B006.hex

BTW, this switch have some issues with IPv6?

Simple remove lan2 from switch/bridge and configure manually - connect
my device directly to eth2 port.
Seems IPv4 works correctly - while IPv6 not (ping6 ff02::1%lan2 - no answer).
Same config (with removed lan2 from bridge) works perfectly with
mt7530 (also dsa) on my mt7621 board.

Or we miss some configuration? Some logs below:

Thu Dec 22 15:05:20 2022 kern.info kernel: [98039.948092]
rtl83xx-switch switch at 1b000000 lan2: Link is Up - 1Gbps/Full - flow
control rx/tx
Thu Dec 22 15:05:20 2022 kern.info kernel: [98039.957695] IPv6:
ADDRCONF(NETDEV_CHANGE): lan2: link becomes ready
Thu Dec 22 15:05:20 2022 daemon.notice netifd: Network device 'lan2' link is up
Thu Dec 22 15:05:20 2022 daemon.notice netifd: Interface 'testnet2'
has link connectivity
Thu Dec 22 15:05:20 2022 daemon.notice netifd: Interface 'testnet2' is
setting up now
Thu Dec 22 15:05:20 2022 daemon.notice netifd: Interface 'testnet2' is now up
Thu Dec 22 15:05:21 2022 kern.warn kernel: [98041.065464]
rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported

root at dgs-1210-48:~# ifconfig lan2
lan2      Link encap:Ethernet  HWaddr 28:3B:82:F3:E4:87
          inet6 addr: fe80::2a3b:82ff:fef3:e487/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:536 errors:0 dropped:0 overruns:0 frame:0
          TX packets:579 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:57514 (56.1 KiB)  TX bytes:53054 (51.8 KiB)

root at dgs-1210-48:~# ifconfig lan2 192.168.1.100
root at dgs-1210-48:~# Thu Dec 22 15:05:54 2022 kern.err kernel:
[98073.849110] rtl83xx_fib_event_work_do: FIB4 failed
Thu Dec 22 15:05:54 2022 kern.err kernel: [98073.854477]
rtl83xx_fib_event_work_do: FIB4 failed
Thu Dec 22 15:05:54 2022 kern.err kernel: [98073.865276]
rtl83xx_fib_event_work_do: FIB4 failed
Thu Dec 22 15:05:54 2022 kern.err kernel: [98073.874632]
rtl83xx_fib_event_work_do: FIB4 failed

root at dgs-1210-48:~# ping -I lan2 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=1.123 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=0.506 ms
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.506/0.814/1.123 ms

root at dgs-1210-48:~# ping6 ff02::1%lan2
PING ff02::1%lan2 (ff02::1%4): 56 data bytes
^C
--- ff02::1%lan2 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss

Any idea?

BR
Janusz

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC