5 ms·

I'm not going to lie, but this article left me absolutely hanging off a huge cliff with no one to rescue me. The actual bug was not fixed!!

• lisper 7y ago
  Yes, it was. > We looked at how we communicate with the camera. We opened a TCP connection the first time it was needed, and left it open for changes to camera settings via the application. We modified this to close the connection once we had sent the required information and open it again if we needed it. We tested this thoroughly over the next few days and it looked solid. Furthermore... > I still don't understand how this caused the camera to lock up. We were receiving the TCP results via Telnet but we weren't reading the stream. Did it just build up in some buffer? How did this cause the camera to lock up? My guess: the buffer filled up and the result was that the computer's OS stopped sending ACK packets to the camera. The camera then locked up waiting for ACKs that never came. Kinda straightforward actually.
  • watt 7y ago
    What if the author decided to make the minimal testcase to make the camere lock up, and reported it as a vulnerability to the camera manufacturer. I think the camera vendor is obligated to fix the defect. It's really annoying to work around such obvious issues when communicating to hardware and frankly the manufacturer should be held against a higher standart.
    • dfox 7y ago
      This behavior is not a bug much less a security vulnerability. If the camera would try to handle this in some "clever" way (and thus started to drop data), that would be a bug.
• hax 7y ago
  Indeed. I really feel a more accurate title would've been "My Hardest Bug to workaround without really understanding what was happening".