osquery / osquery

SQL powered operating system instrumentation, monitoring, and analytics.
https://osquery.io
Other
21.65k stars 2.44k forks source link

ibridge_info table is broken on T2 devices #6086

Open FritzX6 opened 4 years ago

FritzX6 commented 4 years ago

Bug report

What operating system and version are you using?

macOS 10.15.1 Catalina

What version of osquery are you using?

osquery 4.1.1 / 4.0.2

What steps did you take to reproduce the issue?

Running a query against the ibridge_info table I discovered that results are only returned for T1 MacBook Pro's.

SELECT * FROM ibridge_info;

What did you expect to see?

I expected to see results from T2 devices similar to @keeleysam's output testing the original PR (https://github.com/osquery/osquery/pull/5166):

osquery> select * from ibridge;
+--------------------------------------+---------------+------------------+
| boot_uuid                            | model_name    | firmware_version |
+--------------------------------------+---------------+------------------+
| E45FACF9-FF39-4468-B4C8-FA97DCD0D1C9 | Apple T2 chip | 16P50371a        |
+--------------------------------------+---------------+------------------+

What did you see instead?

Instead, I see no rows for T2 devices. @sharvilshah mentioned in his original PR(https://github.com/osquery/osquery/pull/5203) that lack of results was a known issue for Desktop devices (https://github.com/osquery/osquery/pull/5203#issuecomment-521663431) but it is also failing to return results for T2 MacBook Pro's. Additionally, on these devices I see an error related to EmbeddedOS:

Cannot Get EmbeddedOS Properties

image image

I realize this table was significantly rewritten to use EmbeddedOS (https://github.com/osquery/osquery/pull/5707), Wondering if @sharvilshah, @keeleysam, @terracatta might have input on the possible causes for the issue.

sharvilshah commented 4 years ago

Hey @FritzX6,

Do you know what build version for Catalina 10.15.1 is running on those notebooks?

I am currently mobile, so don't have access to a computer, but will look into it when I do.

I also still don't have access to T2 hardware, and I have yet to upgrade machines to 10.15, so I will need your help debugging it. Do you mind pasting your /usr/libexec/remotectl dumpstate output? (Feel free to redact/DM me if it contains sensitive information).

(Also, have you tried the query with root privileges?)

FritzX6 commented 4 years ago

Hi @sharvilshah,

Same results with root / regular user.

I don't have a T2 enabled laptop (just the iMac Pro) but have asked @blaedj to paste the output of his /usr/libexec/remotectl dumpstate for us:

Found localbridge (bridge)
    State: connected (connectable)
    UUID: REDACTED
    Product Type: iBridge2,3
    OS Build: 3.6 (16P6571)
    Messaging Protocol Version: 1
    Heartbeat:
        Last successful heartbeat sent 13.649s ago, received 13.645s ago (took 0.004s)
        28981 heartbeats sent, 0 received
    Properties: {
        AppleInternal => false
        ChipID => 32786
        EffectiveProductionStatusSEP => true
        HWModel => J680AP
        HasSEP => true
        LocationID => REDACTED
        RegionInfo => LL/A
        EffectiveSecurityModeAp => true
        FDRSealingStatus => true
        SigningFuse => true
        BuildVersion => 16P6571
        OSVersion => 3.6
        BridgeVersion => 16.16.6571.0.0,0
        SensitivePropertiesVisible => true
        ProductType => iBridge2,3
        BoardRevision => 1
        Image4CryptoHashMethod => sha2-384
        SerialNumber => REDACTED
        BootSessionUUID => 5X30XXX-9XX8-458F-94A5-C1C50X7X68CE
        BoardId => 11
        EffectiveProductionStatusAp => true
        EffectiveSecurityModeSEP => true
        UniqueChipID => REDACTED
        UniqueDeviceID => REDACTED
        RemoteXPCVersionFlags => 72057594037927942
        CertificateSecurityMode => true
        CertificateProductionStatus => true
        ModelNumber => MR942LL/A
        RegionCode => LL
        InterfaceIndex => 8
        HardwarePlatform => t8012
        Image4Supported => true
    }
    Services:
        com.apple.sysdiagnose.stackshot.remote
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.nfcd.relay.uart
            Properties: {
                UsesBridgeXPC => false
            }
        com.apple.powerchime.remote
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.xpc.remote.multiboot
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.bridgeOSUpdated
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.osanalytics.logTransfer
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.private.avvc.xpc.remote
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.multiverse.remote.bridgetime
        com.apple.corecaptured.remoteservice
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.corespeech.xpc.remote.record
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.logd.remote-daemon
        com.apple.mobileactivationd.bridge
            Version: 1
            Properties: {
                ServiceVersion => 1
                UsesRemoteXPC => true
            }
        com.apple.corespeech.xpc.remote.control
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.eos.LASecureIO
        com.apple.aveservice
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.sysdiagnose.remote
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.internal.xpc.remote.kext_audit
            Properties: {
                UsesRemoteXPC => true
            }
        com.apple.eos.BiometricKit
            Properties: {
                UsesRemoteXPC => false
            }
        com.apple.icloud.findmydeviced.bridge
            Version: 1
            Properties: {
                ServiceVersion => 1
                UsesRemoteXPC => true
            }
        com.apple.nfcd.relay.control
            Properties: {
                UsesBridgeXPC => false
            }
blaedj commented 4 years ago

note that the above output comes from a laptop running macOS 10.14.6

theopolis commented 4 years ago

What parts of this table / iBridge information are important? If it is the case that T2 information is difficult to retrieve, I want to make sure we're focused on a real use case.

For example, if the only important information is that the machine has T2, this is simple. If you need the firmware version, it may be significant effort.

sharvilshah commented 4 years ago

Thanks @FritzX6 and @blaedj!

Are you aware if this is this an issue on T2 machines running 10.14, or just on 10.15? Trying to narrow it down.

In any case, I will try to carve out sometime over the weekend to look into this.

@theopolis That is a good compromise, if we can't make any progress.

keeleysam commented 4 years ago

The version information is important. For example, we've encountered issues with devices which are running beta versions of Bridge OS, such as from an early Catalina beta, when running an older operating system like 10.14.6. Finding these outliers with a table like this makes debugging much easier!

theopolis commented 4 years ago

I read https://duo.com/labs/research/apple-t2-xpc and browsed all of the ioreg properties on my T2 macbook last night and did not see an alternative to querying the firmware version. This is what makes me weary.

we've encountered issues with devices which are running beta versions of Bridge OS, such as from an early Catalina beta, when running an older operating system like 10.14.6. Finding these outliers with a table like this makes debugging much easier!

That's a good use case. In this scenario @keeleysam could the OS version (10.14.6) have been an indicator or were there multiple iBridge firmware versions on 10.14.6 and you needed to hone in on one?

directionless commented 4 years ago

We tried it with 4.0.2, and got the same Cannot get EmbeddedOS properties error. (I think 4.0.2 used the older SDK)

Smjert commented 4 years ago

We tried it with 4.0.2, and got the same Cannot get EmbeddedOS properties error. (I think 4.0.2 used the older SDK)

Since experimental the SDK used is 10.14, because pre-built libraries are built with that.

sharvilshah commented 4 years ago

I read https://duo.com/labs/research/apple-t2-xpc and browsed all of the ioreg properties on my T2 macbook last night and did not see an alternative to querying the firmware version. This is what makes me weary.

we've encountered issues with devices which are running beta versions of Bridge OS, such as from an early Catalina beta, when running an older operating system like 10.14.6. Finding these outliers with a table like this makes debugging much easier!

That's a good use case. In this scenario @keeleysam could the OS version (10.14.6) have been an indicator or were there multiple iBridge firmware versions on 10.14.6 and you needed to hone in on one?

I will continue to investigate a way to query bridge properties (though a bit hamstrung by lack of T2 device), but if we just want the version, we can check whether /System/Library/CoreServices/BridgeVersion.plist exists and parse that as a fall back.

I am not yet sure if /S/L/CoreServices/BridgeVersion.plist exists in 10.15, but that should be relatively easy to find out.

Caveat: I am not quite sure yet if BridgeProductBuildVersion or BridgeVersion in the plist is the actual firmware version.

Does that sound like a decent middle ground? Thoughts?

theopolis commented 4 years ago

Thanks @sharvilshah!

Here is an example of that plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>BridgeBuildGroup</key>
    <string>0</string>
    <key>BridgeProductBuildVersion</key>
    <string>17P1081</string>
    <key>BridgeVersion</key>
    <string>17.16.11081.0.0</string>
    <key>IsSeed</key>
    <string>NO</string>
    <key>SEPEpoch</key>
    <dict>
        <key>Major</key>
        <integer>1</integer>
        <key>Minor</key>
        <integer>0</integer>
    </dict>
</dict>
</plist>
sharvilshah commented 4 years ago

Thanks @theopolis!

I noticed some inconsistencies with /System/Library/CoreServices/BridgeVersion.plist:

On my T1 machine, the contents of that plist is the same as the one you posted, but every apple tool (system_profiler SPiBridgeDataType, remotectl, IOKit (and by extension current table implementation) mentions the version as 14Y906

On T2 machine (at least the one at local apple store), the content of that plist (which is same as above) and that reported by apple tools matches up.

nhakmiller commented 4 years ago

What parts of this table / iBridge information are important? If it is the case that T2 information is difficult to retrieve, I want to make sure we're focused on a real use case.

For example, if the only important information is that the machine has T2, this is simple. If you need the firmware version, it may be significant effort.

With this issue, is it still possible to just determine whether or not the machine has T2? I ran into this same issue while trying to write a query that would indicate whether a system has a T2 controller or not.

The use case is determining whether or not /usr/libexec/firmwarecheckers/eficheck/eficheck --integrity-check is supported (it is NOT support on T2 chips).

Just commenting to add that getting the firmware version is helpful, but just determining whether a machine has T2 is also a valuable use case.