Channels
- s
slevchenko
4 months agoHi everyone. Does anybody knows which kind of address this is
*(address redacted)* ? I seed such addresses in *bpf_socket_events* remote_address field and are not recognized with usual utilities like nc, ping and so on.00:02:08:10:60:00:00:00:00:00:00:00:00:00:88:82
Hi @User I apologize for tagging you directly, I've noticed that you've answered some bpf related questions. If you have a spare moment, could you please look into my question, or advise someone might know? Thanks in advance. - a
alessandrogario
4 months agoHey @slevchenko! That looks like a bug, can you verify that the address is correct by grouping those values every 2 bytes? - s
slevchenko
4 months agoI will. Can you explain how to do it ? - a
alessandrogario
4 months agoSure! You can just remove every odd
character from the address:
So it becomes: 0002:0810:6000:0000:0000:0000:0000:8882
Now I don't know about endianness, bytes may have to be swapped. That would look like this:0200:1008:0060:0000:0000:0000:0000:8288
Finally, I am not 100% sure about these rules, but in theory fields that have only zeroes can be collapsed:0200:1008:0060:::::8288
This can probably applied to zeroes on the left too:200:1008:60:::::8288 - s
slevchenko
4 months agoNow that does resemble valid IPv6 - a
alessandrogario
4 months agowere you able to verify that the IP address is correct? - s
slevchenko
4 months agoUnfortunatelly no. I've tried abut all variants I managed to get returned just:...88: Name or service not known
I feel like I need some script to do all these transformations with no mistakes
Like swapping zeroes, skipping octets filled with nothing but zeroes, so on and so forth
Not sure if it helps, but I've noticed that mangled addresses come from containerized apps: docker containers, snaps (Ubuntu snapcraft), Flatpaks (RH Flatpak) - a
alessandrogario
4 months agoI think it's just bad handling on all IPv6 addresses
or are you thinking that those addresses are being mishandled and are not in fact IPv6? - s
slevchenko
4 months agomaybe, but it gives a huge headache to our security team, so I had to share it with someone form dev team at very least 🙂
I think they are IPv6, but I don't know how they ended up messed up so bad - a
alessandrogario
4 months agoif they have always been IPv6, they have been broken for a while I think - s
slevchenko
4 months agoto me it looks like more just skipping zero filled octets, since in this case address might look like:2008:::::.... - a
alessandrogario
4 months agoit's not corruption or uninintialized memory, it's just that the logic to convert to string those addresses is wrong - s
slevchenko
4 months agoApplications actually work, so they definitely able to reach destinations, it's rather related to how Osquery reflects them in query results - a
alessandrogario
4 months agoyeah, it's all in the ::toString method of IPv6 addresses - s
slevchenko
4 months agoBTW, to reproduce it one can try to use, Thunderbird (snap, remote_port 53), Microsoft Teams (flatpak remote_port 53), to name a few. Unfortunately rest of apps are custom and naming them will not help - a
alessandrogario
4 months agoI think a simple netcat on ::1 should reproduce it easily - s
slevchenko
4 months ago00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01
that'snc ::1 53
So just as you said it's IPv6 conversion getting mangled - a
alessandrogario
4 months agoYeah, so you can probably still query data that has been already collected
until a fix is included in the stable release - s
slevchenko
4 months agoYes if I'll figure out how to convert it to readable form
it was easy with ::1, but how to handle complex addresses which values we don't know beforehand ? - a
alessandrogario
4 months agoi think the easiest way is to process this data from the log aggregator
rather than trying to fix it with SQL - s
slevchenko
4 months agoon our side osquery is used for anomaly detection, and it works with ipv4.
I guess, we can wait. Do you think this fix has any chances to make it into stable release?
if that's considered a minor issue, it would be also great to know, we'll find a way to work around it, one way or another - a
alessandrogario
4 months agoWe already have some additional fixes to BPF, but I am not sure when they are going to be merged & released
bpf: Improve socket event handlinghttps://github.com/osquery/osquery/pull/7446 Add BPF support for CentOS 7.6 distributions with kernel 3.10https://github.com/osquery/osquery/pull/7378 bpf_process_events: Implement additional eventshttps://github.com/osquery/osquery/pull/7370
It is definitely a bug so it will get fixed - s
slevchenko
4 months agoOh, that's great. Thank you Alessandro for your time and answers, have a great day. - a
alessandrogario
4 months ago@slevchenko I pushed a fix in this PR: https://github.com/osquery/osquery/pull/7446/ You can find the new tests here: https://github.com/osquery/osquery/pull/7446/commits/51086d104c2f51adaa220ecf5d0c8f88790668b0#diff-23dba6c075784b3a3b02[…]f9df781d8cdde6a76dc22R1259
View count: 5