Compromising on the Basics isn't a great idea...
Recently, we at Quantum Village disclosed a fairly trivial, but vital bug in the QICK software stack - a relic, in many ways.
What was the bug? Well, it was a default password that can log in over SSH and has sudo privileges! Kinda neat, if you're a hacker.
The login user:pass? 'xilinx:xilinx'. For real.
Now, they have actually changed it - see here - and their advice is still much much better than it was - but it falls short on a few points.
Firstly, they ask the user to change the password... this isn't a tremendous idea. Users generally choose bad-to-awful passwords. Users choose things that are memorable and as such they can be disclosed in many ways without anyone intending to hand out the keys to the castle.
This is particularly important in the 'quantum controller' space - after all, these things are the true gateway to the quantum world from the classical. They translate the output of quantum algorithms, circuits, and pulse descriptions into microwave vibrations that manipulate the state of superconducting qubits. It's quite amazing, but probably not something you want to leave exposed.
This naturally leads to questions about the rest of the quantum stack... if we are planning on using quantum computing on some of our most sensitive data, then we should probably secure it meaningfully first.
This is a project we are looking at picking up at QV@DEF CON; what does the full attack surface and threat model for quantum technologies look like? For quantum sensing, networking, and computing, we really need to identify what this looks like and then see how best to apply it.
Comments
Post a Comment