https://github.com/osquery/osquery logo
Join Slack
Powered by
Hi everyone. Does anybody knows which kind of addr...
# general
s
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.
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
Hey @slevchenko! That looks like a bug, can you verify that the address is correct by grouping those values every 2 bytes?
s
I will. Can you explain how to do it ?
a
Sure! You can just remove every odd 
:
character from the address
So it becomes: 0002081060000000000000000000: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
Now that does resemble valid IPv6
a
were you able to verify that the IP address is correct?
s
Unfortunatelly no. I've tried abut all variants I managed to get returned just:
Copy code
...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
I 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
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 🙂
I think they are IPv6, but I don't know how they ended up messed up so bad
a
if they have always been IPv6, they have been broken for a while I think
s
to me it looks like more just skipping zero filled octets, since in this case address might look like: 
2008:::::....
a
it's not corruption or uninintialized memory, it's just that the logic to convert to string those addresses is wrong
s
Applications actually work, so they definitely able to reach destinations, it's rather related to how Osquery reflects them in query results
a
yeah, it's all in the ::toString method of IPv6 addresses
s
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
I think a simple netcat on ::1 should reproduce it easily
s
Copy code
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01
that's 
nc ::1 53
So just as you said it's IPv6 conversion getting mangled
a
Yeah, so you can probably still query data that has been already collected
until a fix is included in the stable release
s
Yes 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
i think the easiest way is to process this data from the log aggregator
rather than trying to fix it with SQL
s
on 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
We already have some additional fixes to BPF, but I am not sure when they are going to be merged & released
bpf: Improve socket event handling https://github.com/osquery/osquery/pull/7446 Add BPF support for CentOS 7.6 distributions with kernel 3.10 https://github.com/osquery/osquery/pull/7378 bpf_process_events: Implement additional events https://github.com/osquery/osquery/pull/7370
It is definitely a bug so it will get fixed
s
Oh, that's great. Thank you Alessandro for your time and answers, have a great day.
a
s
That's great, thanks for your efforts Alessandro.
6 Views
Open in Slack
PreviousNext
Powered by