Electronic voting machines have active internet connections and IPs. Possibly using LwIP under the hood? OSS is rarely audited by those who use it, perhaps something was slipped in. Checking LwIP commits now to see if I can perhaps notice anything odd, just for curiosity's sake.
Edit: This is a lot to dig through for one man.
I did notice that back in 2019-2020 someone (Gao Qingshui) changed the protocol to use IPv6 by default. See commit here
Then I noticed on github a bug pointed out, this year, which is caused if system is using IPv6. See issue here
Have not figured out what may or may not be exploited due to said bug. I unfortunately know little about networking protocols, perhaps someone else on this forum can assist.
Edit: Found a few commits of people fixing "endless" loop bugs, see here.
If Q team has a copy of the software code that is used to rig elections ... and they were to release it to the public (effectively making it "open source") ... then anyone with computer language knowledge could go through it and see exactly how the code is written to steal elections ... and then this would become the buzz on social media and everywhere, such that even those without those skills would hear about it and realize it really is rigged ... then it would be ... GAME OVER.
Not to discourage you but the things you pointed out aren’t really an issue.
IPv6 is a replacement for ipv4 but no one wants to fix what isn’t broke just yet. Maybe that’ll change when we run out of ipv4 addresses, which is what ipv6 was supposed to solve.
The bug you pointed to Is because the code base wasn’t designed to fall back to ipv4 when ipv6 was disabled on the receiving end. You can see that reflected in the commit you linked where the variable was replaced with a function call.
LwIP has been defaulting to IPv6 since 2020, the bug I pointed to is an issue of the header size being wrong when IPv6 is used (not when it’s disabled), the proposed fix is calling a function to get a proper header size, that fix has not been implemented in LwIP at this time and therefore is an issue (and therefore potentially a vulnerability) in systems using LwIP from 2020 until now. I just am not sure if anything meaningful can be accomplished from such an issue.
My hunch as well, but there’s also so many commits to this repo over the years that there could be any number of exploits lurking in here. I only had time to look at a few dozen and this caught my eye but I don’t know enough about the library to know what is a real issue and what’s not.
Electronic voting machines have active internet connections and IPs. Possibly using LwIP under the hood? OSS is rarely audited by those who use it, perhaps something was slipped in. Checking LwIP commits now to see if I can perhaps notice anything odd, just for curiosity's sake.
Edit: This is a lot to dig through for one man.
I did notice that back in 2019-2020 someone (Gao Qingshui) changed the protocol to use IPv6 by default. See commit here
Then I noticed on github a bug pointed out, this year, which is caused if system is using IPv6. See issue here
Have not figured out what may or may not be exploited due to said bug. I unfortunately know little about networking protocols, perhaps someone else on this forum can assist.
Edit: Found a few commits of people fixing "endless" loop bugs, see here.
If Q team has a copy of the software code that is used to rig elections ... and they were to release it to the public (effectively making it "open source") ... then anyone with computer language knowledge could go through it and see exactly how the code is written to steal elections ... and then this would become the buzz on social media and everywhere, such that even those without those skills would hear about it and realize it really is rigged ... then it would be ... GAME OVER.
A bug loop could be endless.
I thought this happened in 2020, already?
Requested a sticky for you. Let’s see if the mods are awake.
I like where you are going with this, but doesnt the voting machines run Windows 7?
https://qagg.news/?q=endless
Not to discourage you but the things you pointed out aren’t really an issue.
IPv6 is a replacement for ipv4 but no one wants to fix what isn’t broke just yet. Maybe that’ll change when we run out of ipv4 addresses, which is what ipv6 was supposed to solve.
The bug you pointed to Is because the code base wasn’t designed to fall back to ipv4 when ipv6 was disabled on the receiving end. You can see that reflected in the commit you linked where the variable was replaced with a function call.
sorry for the Reddit link
LwIP has been defaulting to IPv6 since 2020, the bug I pointed to is an issue of the header size being wrong when IPv6 is used (not when it’s disabled), the proposed fix is calling a function to get a proper header size, that fix has not been implemented in LwIP at this time and therefore is an issue (and therefore potentially a vulnerability) in systems using LwIP from 2020 until now. I just am not sure if anything meaningful can be accomplished from such an issue.
You’re right, I had it backwards and I didn’t realize the PR was still open. It’s 4am here.
It just means you can’t respond to a ping when ipv6 is enabled. More of an annoyance bug than an exploitable one imo.
My hunch as well, but there’s also so many commits to this repo over the years that there could be any number of exploits lurking in here. I only had time to look at a few dozen and this caught my eye but I don’t know enough about the library to know what is a real issue and what’s not.