Name: Anonymous 2016-08-18 6:22
http://arstechnica.com/security/2016/08/code-dumped-online-came-from-omnipotent-nsa-tied-hacking-group/
https://xorcatt.wordpress.com/2016/08/16/equationgroup-tool-leak-extrabacon-demo/
Once again, a buffer overflow has lead to new vulnerabilities in C land. This time all pre-2013 Cisco routers are affected.
It does indeed feel there is a gaping hole in our software stack as these buffer overflows are only increasing in rapidity. It is time we take a serious look at the epidemic of exploits in C land, and begin to implement real solutions; they are out there.
It’s hard to deny that easy access to stack, especially unpriveleged access, plays a serious role in creating computer crime. How many buffer overflows happen in languages with access checks on stacks? How many buffer overflows are discovered in the Ada each year? None. How many in Haskell? None. How many in Java? None. The list could go on. And yet, mass exploitation in the C-land continue to increase. There is certainly a correlation. But there are other important causes at play as well: the language is an ill-designed clusterfuck of hacks upon hacks.
Of course, mass buffer overflows are only one indication of the security nightmare that plagues the language — the whole language is built on unsafe and insecure code. In the C-land, memory rules are much more lax than that of other popular languages, on par with the assembly and lacking even basic safety features: unless explictly requested by the programmer.
Nearly 70% pre-2013 routers are Cisco and are vulnerable to being hacked during the %CurrentYear%.
https://gigaom.com/2013/02/27/chart-cisco-owns-the-switching-and-routing-world/
These are a only a few of the indicators of what may feed into the hopelessness and despair that causes so much distrust in C and its derivatives. The bugs cost real money and real work-hours to be wasted on correcting and debugging the garbage that was compiled by compilers which don't value anything but speed and memory use..
https://xorcatt.wordpress.com/2016/08/16/equationgroup-tool-leak-extrabacon-demo/
Once again, a buffer overflow has lead to new vulnerabilities in C land. This time all pre-2013 Cisco routers are affected.
It does indeed feel there is a gaping hole in our software stack as these buffer overflows are only increasing in rapidity. It is time we take a serious look at the epidemic of exploits in C land, and begin to implement real solutions; they are out there.
It’s hard to deny that easy access to stack, especially unpriveleged access, plays a serious role in creating computer crime. How many buffer overflows happen in languages with access checks on stacks? How many buffer overflows are discovered in the Ada each year? None. How many in Haskell? None. How many in Java? None. The list could go on. And yet, mass exploitation in the C-land continue to increase. There is certainly a correlation. But there are other important causes at play as well: the language is an ill-designed clusterfuck of hacks upon hacks.
Of course, mass buffer overflows are only one indication of the security nightmare that plagues the language — the whole language is built on unsafe and insecure code. In the C-land, memory rules are much more lax than that of other popular languages, on par with the assembly and lacking even basic safety features: unless explictly requested by the programmer.
Nearly 70% pre-2013 routers are Cisco and are vulnerable to being hacked during the %CurrentYear%.
https://gigaom.com/2013/02/27/chart-cisco-owns-the-switching-and-routing-world/
These are a only a few of the indicators of what may feed into the hopelessness and despair that causes so much distrust in C and its derivatives. The bugs cost real money and real work-hours to be wasted on correcting and debugging the garbage that was compiled by compilers which don't value anything but speed and memory use..