Channels
  • s

    slevchenko

    4 months ago
    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 @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 ago
    Hey @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 ago
    I will. Can you explain how to do it ?
  • a

    alessandrogario

    4 months ago
    Sure! 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 ago
    Now that does resemble valid IPv6
  • a

    alessandrogario

    4 months ago
    were you able to verify that the IP address is correct?
  • s

    slevchenko

    4 months ago
    Unfortunatelly 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 ago
    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

    slevchenko

    4 months ago
    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

    alessandrogario

    4 months ago
    if they have always been IPv6, they have been broken for a while I think
  • s

    slevchenko

    4 months ago
    to me it looks like more just skipping zero filled octets, since in this case address might look like:
    2008:::::....
  • a

    alessandrogario

    4 months ago
    it's not corruption or uninintialized memory, it's just that the logic to convert to string those addresses is wrong
  • s

    slevchenko

    4 months ago
    Applications 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 ago
    yeah, it's all in the ::toString method of IPv6 addresses
  • s

    slevchenko

    4 months ago
    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

    4 months ago
    I think a simple netcat on ::1 should reproduce it easily
  • s

    slevchenko

    4 months ago
    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

    alessandrogario

    4 months ago
    Yeah, 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 ago
    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

    alessandrogario

    4 months ago
    i 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 ago
    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

    alessandrogario

    4 months ago
    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 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 ago
    Oh, that's great. Thank you Alessandro for your time and answers, have a great day.
  • a

    alessandrogario

    4 months ago