Title
#general
s

slevchenko

02/03/2022, 8:34 AM
Hi everyone. Does anybody knows which kind of address this is
00:02:08:10:60:00:00:00:00:00:00:00:00:00:88:82
(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.
3:44 PM
Hi @alessandrogario 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

02/03/2022, 4:49 PM
Hey @slevchenko! That looks like a bug, can you verify that the address is correct by grouping those values every 2 bytes?
s

slevchenko

02/03/2022, 4:52 PM
I will. Can you explain how to do it ?
a

alessandrogario

02/03/2022, 4:52 PM
Sure! You can just remove every odd
:
character from the address
4:53 PM
So it becomes: 0002:0810:6000:0000:0000:0000:0000:8882
4:54 PM
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
4:55 PM
Finally, I am not 100% sure about these rules, but in theory fields that have only zeroes can be collapsed:
0200:1008:0060:::::8288
4:55 PM
This can probably applied to zeroes on the left too:
200:1008:60:::::8288
s

slevchenko

02/03/2022, 4:56 PM
Now that does resemble valid IPv6
a

alessandrogario

02/03/2022, 5:02 PM
were you able to verify that the IP address is correct?
s

slevchenko

02/03/2022, 5:04 PM
Unfortunatelly no. I've tried abut all variants I managed to get returned just:
...88: Name or service not known
5:05 PM
I feel like I need some script to do all these transformations with no mistakes
5:06 PM
Like swapping zeroes, skipping octets filled with nothing but zeroes, so on and so forth
5:09 PM
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

02/03/2022, 5:10 PM
I think it's just bad handling on all IPv6 addresses
5:11 PM
or are you thinking that those addresses are being mishandled and are not in fact IPv6?
s

slevchenko

02/03/2022, 5:11 PM
maybe, but it gives a huge headache to our security team, so I had to share it with someone form dev team at very least 🙂
5:12 PM
I think they are IPv6, but I don't know how they ended up messed up so bad
a

alessandrogario

02/03/2022, 5:12 PM
if they have always been IPv6, they have been broken for a while I think
s

slevchenko

02/03/2022, 5:13 PM
to me it looks like more just skipping zero filled octets, since in this case address might look like:
2008:::::....
a

alessandrogario

02/03/2022, 5:14 PM
it's not corruption or uninintialized memory, it's just that the logic to convert to string those addresses is wrong
s

slevchenko

02/03/2022, 5:15 PM
Applications actually work, so they definitely able to reach destinations, it's rather related to how Osquery reflects them in query results
a

alessandrogario

02/03/2022, 5:17 PM
yeah, it's all in the ::toString method of IPv6 addresses
s

slevchenko

02/03/2022, 5:18 PM
BTW, 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

02/03/2022, 5:18 PM
I think a simple netcat on ::1 should reproduce it easily
s

slevchenko

02/03/2022, 5:27 PM
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01
5:28 PM
that's
nc ::1 53
5:28 PM
So just as you said it's IPv6 conversion getting mangled
a

alessandrogario

02/03/2022, 5:30 PM
Yeah, so you can probably still query data that has been already collected
5:30 PM
until a fix is included in the stable release
s

slevchenko

02/03/2022, 5:30 PM
Yes if I'll figure out how to convert it to readable form
5:31 PM
it was easy with ::1, but how to handle complex addresses which values we don't know beforehand ?
a

alessandrogario

02/03/2022, 5:32 PM
i think the easiest way is to process this data from the log aggregator
5:32 PM
rather than trying to fix it with SQL
s

slevchenko

02/03/2022, 5:33 PM
on our side osquery is used for anomaly detection, and it works with ipv4.
5:35 PM
I guess, we can wait. Do you think this fix has any chances to make it into stable release?
5:36 PM
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

02/03/2022, 5:38 PM
We already have some additional fixes to BPF, but I am not sure when they are going to be merged & released
5:38 PM
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
5:39 PM
It is definitely a bug so it will get fixed
s

slevchenko

02/03/2022, 5:41 PM
Oh, that's great. Thank you Alessandro for your time and answers, have a great day.
s

slevchenko

02/09/2022, 9:45 AM
That's great, thanks for your efforts Alessandro.