DEBUG:root:Publishing meshtastic.receive.admin leaks wifi passwords

Support
1

Where this info is published? Because it leaks wifi passwords. Can’t find the place in the code

2

Mind posting logs or more information?

1 Like
3

sure, do 'meshtastic --debug and you’ll see something like this

DEBUG:root:Publishing meshtastic.receive.admin: packet={'from': 4064764972, 'to': 4064764972, 'decoded': {'portnum': 'ADMIN_APP', 'payload': b'xxxxx', 'requestId': 3228470752, 'admin': {'getRadioResponse': {'preferences': {'waitBluetoothSecs': 28800, 'phoneTimeoutSecs': 900, 'lsSecs': 300, 'wifiSsid': 'WannaLog', 'wifiPassword': 'heresafrickinglog', 'region': 'EU865', 'chargeCurrent': 'MA280', 'mqttServer': 'mqtt.meshtastic.org:1883', 'mqttDisabled': True, 'debugLogEnabled': True, 'rangeTestPluginSave': True}}, 'raw': get_radio_response { preferences { wait_bluetooth_secs: 28800 phone_timeout_secs: 900 ls_secs: 300 wifi_ssid: "WannaLog" wifi_password: "heresafrickinglog" region: EU865 charge_current: MA280 mqtt_server: "mqtt.meshtastic.org:1883" mqtt_disabled: true debug_log_enabled: true range_test_plugin_save: true } } }}, 'id': 1608039836, 'rxTime': 1627832366, 'hopLimit': 3, 'priority': 'RELIABLE', 'raw': from: 4064764972 to: 4064764972 decoded { portnum: ADMIN_APP payload: "xxxx" request_id: 3228470752 } id: 1608039836 rx_time: 1627832366 hop_limit: 3 priority: RELIABLE , 'fromId': '!fXXXXXXX', 'toId': '!fXXXXXXX'}
1 Like
4

Hmm - I’d say this is a minor (but important) problem because any API consumer talking to the device over USB can read/write the entire device config. But it is a good idea to strip it!

I’d recommend you make the change here (and please send in a pull-request so we can share it with others):

void AdminPlugin::handleGetRadio(const MeshPacket &req)
{
    if (req.decoded.want_response) {
        // We create the reply here
        AdminMessage r = AdminMessage_init_default;
        r.get_radio_response = radioConfig;

        // NOTE: The phone app needs to know the ls_secs & phone_timeout value so it can properly expect sleep behavior.
        // So even if we internally use 0 to represent 'use default' we still need to send the value we are
        // using to the app (so that even old phone apps work with new device loads).
        r.get_radio_response.preferences.ls_secs = getPref_ls_secs();
        r.get_radio_response.preferences.phone_timeout_secs = getPref_phone_timeout_secs();
       // @vodkin, clear r.get_radio_response.preferences.wifi_password = "";

        r.which_variant = AdminMessage_get_radio_response_tag;
        myReply = allocDataProtobuf(r);
    }
}
1 Like
5

Still needs to be clarified - where is it published? To the app? Does the app send it somewhere? Should I change my AP pass now?

6

That message is published internally (inside the python process) so that python API consumers can do things with the device. Unless you’ve written custom python code using the python API that information is going nowhere (other than your console that printed that debug message).

so no need to change your wifi password :wink: .

1 Like
7

actually, I just thought of a cleaner fix (just clearing the string would not be sufficient - that would break later API writes). I went ahead and implemented it and it will be in the next release.

1 Like
8

Nice and prompt, great job!

1 Like