cyber is on heightened alarm levels

… ya’ll know why.

timeline of a successful attack on the most basic tools like: exiftool

  • cve-2021-22204 (failed to properly validate parsed input)
  • This was reported by a security researcher on April 7, 2021, initially confidentially via the bug bounty platform HackerOne at the affected GitLab.
    • They reacted quickly, passed this on to the exiftool maintainers, who already provided a patched version 12.24 on April 13 and on April 14, the researcher received a $19,000 reward.
    • But the story wasn’t over.
    • On April 30 – more than two weeks later – CySrc filed a report with Google’s Vulnerability Reward Program.
    • They had found that DjVu images uploaded to Virustotal gave them access to scan servers.
    • Had the operators of these servers overslept the patches?

translated from: https://www.heise.de/hintergrund/Der-Patch-Alptraum-Wenn-schnell-nicht-schnell-genug-ist-7069924.html

  • Probably not. I rather think that they simply relied on the security updates of their Linux distribution.
  • And with Debian, for example, that didn’t happen until May 2nd; at Fedora even on May 4th.
  • So, after the release of the patch that exposed the problem, there was a window of over 2 weeks in which Linux systems with exiftool were vulnerable to a known, easy-to-exploit vulnerability.
  • CySrc used this window of opportunity to score points on Google’s Vulnerability Reward Program (although it’s not clear if they got a reward).
  • But just as well, state APT or cybercrime hackers could have exploited this gateway for their own purposes and caused real harm.

possibly mitigation: Debian need to push updates more frequently

maybe even like a “hotline” to put together, updates/patches that are URGENT on track to be published IMMEDIATELY.

kernel-live patching?

ubuntu does it already.

https://ubuntu.com/blog/an-overview-of-live-kernel-patching

possibly mitigation:

/usr/bin/unshare

“For exiftool it would therefore have been the right approach not to start it with root rights (!), but rather to run it with unshare (/usr/bin/unshare) in an extremely downtripped context. Linux comes with a lot of security features that you just have to use.”

(src)

possibly mitigation:

another: possibly mitigation:

Yes C++ is “ugly”.

So is RUST.

But RUST comes with “build-in” safety (hardware control might be lacking somewhat).

So yes it is an hard-to-understand-and-what-is-actually-going-on-syntax-language… but unless there comes the “C with safety build in” RUST is the best option for Open Source to be secure, reliable and fast in the future.

Linus & probably also Mr Stallman will always stick to C, because yes it is a great language (still) and it is part of their DNA.

 

Links:

RUST – most loved programming language ever – C++ with safety – new programming language from Mozilla for Mozilla and Safety – now also with step debugging

compile rust hello world for arm7

Rust Dev Lang – how to view onboard html based documentation (man page) – The Rust Standard Library

How to step debug debugging rust in vim 8.1

 

java had it’s oopsi time

CyberInSecurity – Ah Oh it’s Java time – log4j called Log4Shell – “dynamically” remote loading code or any other resources is ALWAYS a bad cybersec idea

admin