With the advent of "Safe" languages like Rust, the prevalence of Software Correctness, and improved type checking in existing systems, memory based exploits are very hard if not possible at all, to execute. Technically, Cryptography is in a very advanced stage, and its not feasible for the most to actually break the current standards. Systems like SeL4, are proven to be correct.

Although it is a work in a very positive direction, but then what is the future of the art of Breaking/Hacking of digital computer systems? Is this profession/art coming to an end?

closed as primarily opinion-based by Neil Smithline, Tobi Nary, schroeder Apr 14 '16 at 5:11

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I suspect this is going to end up considered off-topic because it's 100% opinion based as it stands. Most of the issues found nowadays are implementation issues or logical flaws, though, both of which are entirely possible with "safe" languages. – Matthew Apr 13 '16 at 16:18
  • Human fallibility is the root of buffer overflows, and we're likely to keep writing a lot of our own code, or the code that defines code, for a while to come. – Dave Apr 13 '16 at 18:04
  • 2
    wiki.sel4.systems/FrequentlyAskedQuestions - "Does seL4 have zero bugs? [..] There may still be unexpected features in the specification and one or more of the assumptions may not apply. The security properties may be sufficient for what your system needs, but might not. For instance, the confidentiality proof makes no guarantees about the absence of covert timing channels." and "If I run seL4, is my system secure? Not automatically, no" – TessellatingHeckler Apr 13 '16 at 19:00

There is whole world of vulnerabilities out there which don't need buffer overflows or bad crypto. Just have a look at web applications where you have all these web based insecurities like Cross Site Scripting (XSS) or Cross Site Request Forgery (CSRF). Then take a look at code injections like SQL injection or Remote File Inclusion. If this is not enough have a look at the latest Ransomware which makes use the Windows Scripting Host etc. No buffer overflows or bad crypto is needed for all this.

Is this profession/art coming to an end?

Don't worry. The increasing complexity of current systems combined with security as an afterthought opens enough new attack vectors, even though some older ones might vanish. Just have a look at the whole IoT mess for example.


You are overlooking the fact of the OSI Layers 8, 9 and 10 problem. Technology has been in place to prevent, minimize, and or disrupt most attacks for years. It does not matter how much more technology you create, theorize, adore, if the processes are broken. Most organizations that have been breached had more than sufficient technology to minimize access, authorization, and the ability for threat actors to escalate. Most if not all failed to have the proper "security architecture" in place. By architecture, I mean foundation.

Envision a database server if you will. Nothing fancy, an MSSQL system that needs to interact ONLY with a webserver that makes a query: Client -> Server Now ask yourself, if that is the only connection that needs to be made, why would you NOT at minimum implement a firewall policy on that server itself that says: "You can only talk to this system (client)" The process/interconnection is not understood and or defined often, and this is what leads to data exfiltration. If I am on the network via way of malicious software introduced to say a laptop, I can compromise that DB and use that DB to pivot, etc.

Now as far as software is concerned, it means little to make security too complicated as it will often makes things worse/slower/less user friendly. So the more you tack on, the higher the likelihood users itself will seek to bypass: "I'll just turn of SELinux because it prohibits me from XYZ." In trying to solve one problem (poor code/practice/design) you created others. When I pentest, I am exploiting human errors moreso than technological errors. You can't fix humans.


I am pretty sure when assembly programmers first heard of high-level system programming languages like C they must have thought some classes of the bugs will never be seen again. What happened is we have exactly the same classes of bugs but under different disguises.

Typical command/data confusion (which is behind most injection attacks) will occur no matter how languages evolve because there will always be naive programmers and type systems are not really designed to solve trust problems.

Other security issues like mis-configuration and social engineering will continue to happen until the point AI take over. Maybe even AIs are susceptible to them as we've seen in the recent Tay incident.

Not the answer you're looking for? Browse other questions tagged or ask your own question.