I have run into these CVEs during an audit. I looked into the patches linked to
them, and it seems that the ancient lua code for 5.1.5 was very different from
the code where the patches are created against. When I attempted to manually
make similar changes in the code, it seemed to me that the o
Lua 5.1.5 would appear to have CVEs below against it.
The patches to this in OpenWrt are significant, but dated, with the
last bug fix seeming to be from 2019, so it's hard to say if
these are addressed:
https://github.com/openwrt/openwrt/tree/openwrt-22.03/package/utils/lua/patches
https://
On 10/25/22 17:45, Michael Richardson wrote:
So, it needs to bound to *all* the IPv6 "LAN" IPs.
That means:
a) the ULA that is created.
b) the LL-IPv6 that are always present
c) the GUA IPv6 that is delegated
Sorry, I badly paraphrased. The requested change was for IPv4 only. I
don'
Initialize the data structure using memset to avoid the possibility of
writing garbage values to the hardware.
Always set a valid entry type, which should fix writing unicast entries
on RTL930x.
For unicast entries, set the is_static flag to prevent the switch from
aging them out.
Also set the r
L2 learning on the CPU port is currently not consistently configured and
relies on the default configuration of the device. On RTL83xx, it is
disabled for packets transmitted with a TX header, as hardware learning
corrupts the forwarding table otherwise. As a result, unneeded flooding
of traffic fo
This is a follow-up to the patch "realtek: don't set L2LEARNING flag in
rtl83xx TX header". An undesired effect of that patch is flooding of
some packets destined for the switch CPU port, which is addressed by
this additional patch series.
This patch series switches to assisted learning for the CP
On 10/25/22 5:34 PM, Peter Naulls wrote:
On 10/25/22 17:25, Reuben Dowle wrote:
The issue of HTTP listening on all interfaces also came up in my
audit, but the auditors were happy with the explanation that the
firewall prevented any access through the WAN interface. If the
people auditing you
Peter Naulls wrote:
> Nevertheless, the security people are looking at this config
> statically, and not seeing that it's bound to the LAN interface IP
> only.
I don't think they are really security people, but...
> For my use, I've changed the default binding to the LAN IP, and
On 10/25/22 17:25, Reuben Dowle wrote:
I have myself gone through the process of getting an openwrt based product
through a security audit.
The issue of HTTP listening on all interfaces also came up in my audit, but the
auditors were happy with the explanation that the firewall prevented a
I have myself gone through the process of getting an openwrt based product
through a security audit.
> I think everyone bothering to read this understands the theatre aspects of all
> this that I called out in my original post. Whether things should actually be
> fixed (or "fixed") is certainly
On 10/25/22 16:40, Karl Palsson wrote:
Peter Naulls wrote:
If they see what they want to see, then why should anyone else
get involved in their wish fulfilment?
Security review is fine, security should not be entertained, and
certainly foisted on other people?
Karl, not sure where you're
Peter Naulls wrote:
> On 10/25/22 14:53, Luiz Angelo Daros de Luca wrote:
> is much easier to let the firewall zones deal with that.
> >
> >> As aside, they don't see the iptables tool in the system, and don't
> >> understand that that's been deprecated (although I since did add it
> >> for some
On 10/25/22 14:53, Luiz Angelo Daros de Luca wrote:
is much easier to let the firewall zones deal with that.
As aside, they don't see the iptables tool in the system, and don't
understand that that's been deprecated (although I since did add it
for some unrelated legacy usage), and think there'
> The default uhttpd configuration has this:
>
> # HTTP listen addresses, multiple allowed
> list listen_http0.0.0.0:80
> list listen_http[::]:80
>
> Now, I know there's lots of practical reasons for this to be the case,
> and I know also that the firewall setup in O
The default uhttpd configuration has this:
# HTTP listen addresses, multiple allowed
list listen_http0.0.0.0:80
list listen_http[::]:80
Now, I know there's lots of practical reasons for this to be the case,
and I know also that the firewall setup in OpenWrt is r
On Tue, Oct 25, 2022 at 7:37 AM Peter Naulls wrote:
>
> On 10/24/22 18:21, Hauke Mehrtens wrote:
>
> Hauke, thanks for replying!
As I said on a related thread - if an eu body can be found to care
more deeply on these issues, I'm pretty sure
30-50k of funding is available via one or more of nlnet
On 10/24/22 18:21, Hauke Mehrtens wrote:
Hauke, thanks for replying!
I also prefer if the CVE number is named in the patch. If this is missing
somewhere you could send a patch or pull request to rename the patch.
I'm afraid I don't have any explicit examples, but I'll let you know if
find a
17 matches
Mail list logo
