WebREPL unsafe?

[HermannSW]

I just learned how to query interned strings in ram:
viewtopic.php?f=2&t=2639#p29165

WebREPL prompt not displaying password input seems safe, but it is not.
The password I entered ("abcd") shows up as interned string -- seems to be a security bug ...

[jickster]

I just learned how to query interned strings in ram:
viewtopic.php?f=2&t=2639#p29165

WebREPL prompt not displaying password input seems safe, but it is not.
The password I entered ("abcd") shows up as interned string -- seems to be a security bug ...

All strings are interned with no way to remove them.

For production you can remove access to the qstrings but they’ll still be stored.


Sent from my iPhone using Tapatalk Pro

[HermannSW]

Thanks for the info.

> For production you can remove access to the qstrings ...
>
How?
With flashing a new MicroPython image?
If so, how to create that?

[jickster]

Thanks for the info.

> For production you can remove access to the qstrings ...
>
How?
With flashing a new MicroPython image?
If so, how to create that?

Yes by flashing a new micropython image.
You have to rebuild it from source.

There should be lots of threads on this forum explaining how to do that. There’s probably a tutorial on the github page.

Once you have that up and running, quote this message and I’ll show you which lines you have to comment out to remove the printing of qstrings.


Sent from my iPhone using Tapatalk Pro

[jickster]

Thanks for the info.

> For production you can remove access to the qstrings ...
>
How?
With flashing a new MicroPython image?
If so, how to create that?

But it is pretty dumb that you have to rebuild the firmware to hide a package.

https://github.com/micropython/micropython/issues/4173

[HermannSW]

Thanks for creating issue, I found it:

Code: Select all

$ find micropython -name '*.c*' -exec grep -nH "qstr pool:" {} \;
micropython/py/modmicropython.c:98:    mp_printf(&mp_plat_print, "qstr pool: n_pool=%u, n_qstr=%u, n_str_data_bytes=%u, n_total_bytes=%u\n",
$ 
$ head -105  micropython/py/modmicropython.c | tail -12
STATIC mp_obj_t mp_micropython_qstr_info(size_t n_args, const mp_obj_t *args) {
    (void)args;
    size_t n_pool, n_qstr, n_str_data_bytes, n_total_bytes;
    qstr_pool_info(&n_pool, &n_qstr, &n_str_data_bytes, &n_total_bytes);
    mp_printf(&mp_plat_print, "qstr pool: n_pool=%u, n_qstr=%u, n_str_data_bytes=%u, n_total_bytes=%u\n",
        n_pool, n_qstr, n_str_data_bytes, n_total_bytes);
    if (n_args == 1) {
        // arg given means dump qstr data
        qstr_dump_data();
    }
    return mp_const_none;
}
$ 

P.S:
Some comments on what the "threat" is. Yes, only one concurrent WebREPL connection is possible, and if someone can connect to WebREPL he has to know the password. The threat is that a third-party module that gets imported from a user either directly sends out qstr pool dump to the internet, or starts a (stealth) service that would allow an attacker to request a qstr pool dump over internet. And as seen the password is one of the qstr pool entries. I recently learned how stealth services get armed, preventing (simple) scan tool detection:
https://github.com/Hermann-SW/wireless- ... on-details

[jickster]

Just delete the function call to qstr dump data


Sent from my iPhone using Tapatalk Pro

[pfalcon]

As often happens, this topic discusses/mixes multiple issues at once. Let's try to separate one form another:

The password I entered ("abcd") shows up as interned string

You would need to prove that claim. More likely, what shows in qstr's is the password you have configured in webrepl_cfg.py. As you see, the difference is subtle. WebREPL was initially implemented to be simple and just work. There was a talk about adding password hashing, but that grows code, makes it dependent on hashing module (and anything written for MicroPython has a requirement to be minimal, to work on as minimal systems as possible), and beyond that, to deal with migrating existing deployments. So well, it didn't get to it so far.

[pfalcon]

qstr_info() running in WebREPL

Well, if an adversary has access to WebREPL, them being able to run qstr_info() is a minor problem. MicroPython REPL (whether serial or Web) allows complete access/control of the system, that's well, the requirement for them. So, someone who has access to WebREPL, can read/scan the entire memory. They can change password or anything else by writing to a file to directly to flash. Well, they can silently overwrite your flash with some cute version of mirai botnet. The solution? Well, don't let adversaries access your WebREPL, one possible way of doing that is not letting "anyone else" at all to access it. Just passwords aren't enough for that, there should be firewalls, steel doors, and dogs on guards.

[pfalcon]

The threat is that a third-party module

Oh, that's one of the real threat, and it seems that not enough people aware/understand it still (???). But then everyone who understands it knows that it's a trait of any non-centralized system. In particular, it affects CPython, Ruby, Perl, PHP, etc. Your (web) application could accept credit card data, and you might have 3rd-party module which... And for some languages/communities that issue is not just abstract thinking, but a day to day reality. For example, for JavaScript it started like this: https://www.theregister.co.uk/2016/03/2 ... pad_chaos/ , proceeded like this: https://medium.com/@jdan/i-peeked-into- ... 9f63d21558 , and now it's like this: I’m harvesting credit card numbers and passwords from your site. Here’s how.

The way to deal with these is also known:

• Start with no trust for 3rd-party
• Minimize external dependencies
• Afterwards, make grounded/verified/verifiable trust exceptions.

HermannSW, I'm glad that you brought up this topic, because it would allow to more easily explain concerns with your otherwise great PR at https://github.com/micropython/webrepl/pull/37. The original webrepl_cli.py was written in a way to work using MicroPython itself (it's generally a requirement for all tools related to MicroPython - to dogfeed them into MicroPython itself).

Instead, you add dependency on CPython, and a particular 3rd-party module for it, named "websocket". However, this fact isn't disclosed anywhere. Besides pure usability issues (put simple, users won't know how to make your tool run), with some effort, security eyebrows can be raised: a) dependency on 3rd-party module is added, but not disclosed; b) the name of 3rd-party module used matches that of MicroPython's. Obviously a great guy like you can't mean anything wrong, but just think that an attacker would act exactly like this: silently add a dependency on 3rd-party module, masquerading it as a well-known (builtin) module, flooding PRs with minor changes-over-changes to complicate its review and possibly let questionable changes sneak in.