On Mon, May 2, 2022 at 8:26 AM Emmanuel Deloget <log...@free.fr> wrote: > Le lun. 2 mai 2022 à 03:31, Denys Vlasenko <vda.li...@googlemail.com> a écrit > : > > > I beg to differ, and especially on some embedded systems where the RNG > > > might be quite controllable by an attacker from the outside (mostly > > > because > > > it lacks a lot of entropy crediting inputs, which is exactly the reason > > > why we > > > need seedrng in the first place). This may lead to catastrophic > > > cryptography > > > failures down the road. > > > > Did you personally encounter such a situation? > > I'm not implying it's not really happening, I'm interested to hear > > from people who met this situation in real world. > > Hey :) We're now entering in the "cautionary tales" territory :) > > This happened, yes. We have not seen any exploitation of this in > nature (I would guess that it was mostly because there were other > lower hanging fruits; why would you attack the cryptography when you > could shellshock the device? yeah, bash was here -- it was a time > where ash was not deemed good enough to run the CGI scripts :) ; and > that was not the worst vulnerability so in practice you wouldn't even > need to use it to take full control of the device) but it was scary to > see that our different devices were able to boot and generate the same > SSH keys. This happened only on their first boot when the device was > not connected to the LAN (and not on all devices). Blank state, 0 > source of entropy. Quite a "fun" time.
If you still have a device which exhibits this behavior (seemingly totally deterministic state during each boot), can you try something like find /proc -maxdepth 1 -type f -size -8k '!' -name kmsg '!' -name sysrq-trigger | xargs md5sum and see whether any /proc files display variability? _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
