2

I'm a software developer who mainly programs in C# and C. I'm currently studying to transition into InfoSec related development. Most learning resources on exploiting that I've found, both online and physical books, seem to focus on C and other non-managed code. However, managed code is not entirely safe from exploits, although it may be tougher/impossible to find a memory vulnerability.

What types of exploits/vulnerabilities in the language are out there that have caused damage to managed programs? I'm talking about technical exploits that a programmer can open up naively in the code or ones that are inherent to the language itself. This could apply to any managed language but I'm focusing on C# or Java here.

Improve this question
8
  • Not sure what you're asking, entirely. If you search for "Java CVE's" you will get a list of 475 vulnerabilities that have existed in Java alone (just things in the language) cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/… Is that the kind of thing you are looking for?
    – schroeder ♦
    Commented Jan 26, 2017 at 20:48
  • Kinda. I had a look at the site yesterday but there seems to be no real detail on how these things occur? In other words, it's very easy for me to understand a buffer overflow, format string, global address table, DDOS etc... in a technical sense. But the CVEs seem to just say "vulnerability which allowed xyz with no technical details.
    – the_endian
    Commented Jan 26, 2017 at 20:53
  • Ah, then what you are looking for are CVEs with exploits or PoCs.
    – schroeder ♦
    Commented Jan 26, 2017 at 20:58
  • I can totally relate to the issue you're currently facing. There was a time where I just wouldn't see how all these complex memory vulnerabilities could be translated over to a memory-safe language. Now while there are exploits like the aforementioned CVEs or the PHP exploit that pornhub.com rewarded with 10000$, I've found that it's the logic errors, which really bring a program to its knees. Several have lead me to successful DDoS or RCE. These occur in all languages, human error can easily and frequently be exploited.
    – FMaz
    Commented Jan 26, 2017 at 21:46
  • @Krazor when you say logic errors, you're talking about something such as fail to check input validation properly or fail to take certain circumstances into account?
    – the_endian
    Commented Jan 26, 2017 at 21:48

1 Answer 1

Reset to default
1

It's really important to keep in mind, that memory vulnerabilities are from the only issues out there.

I've found that it's the logic errors, which really bring a program to its knees. Several have lead me to successful DDoS or RCE. These occur in all languages, human error can easily and frequently be exploited.

Here is a list of some, in no particular order:

Improper input validation

Real-World-Example: Injection. Being part of the OWASP Top 10, it can be found anywhere, and in any language. Especially SQL injection and XSS stand out.

Uncatched exceptions

Real-World-Example: These more often that not lead to a DDoS. I once looked at a program using threads and locks. Too bad that I could reliably trigger an exception state just after the lock was acquired. Ouch.

Use of insecure functions

Real-World-Example: Many programming languages (especially scripted ones) offer some sort of real-time eval. The use of these is bad practices. You know what else is bad practice? Rushing out an unfinished prototype as the actual product. Happens more often then you'd think. I know that these kind of relate to input validation, however it does not always need user input specifically to exploit these.

Pro-Tipp: My scripts grep for these functions before any assessment takes place. (Source known, obviously)

Dev- vs. Production Environment

Real-World-Example: A program which used sockets. In their development environment, each machine had 'unlimited' amount of available sockets. The computers where the software was eventually deployed on didn't. Their server could easily be crashed, and it was a critical piece of infrastructure as well.

Developer Misunderstanding or Lazyness

Real-World-Example: This one is my favorite by far! I once looked at web server, self-built in Python. In Python, the inbuilt HTTP-Handler has a 'do_METHOD' function for every HTTP-method. If you want your own handler, you subclass it and overwrite these functions, which is exactly what they did. Now they had one function which was called 'do_WORK', that had nothing to do with serving HTTP at all. Python (for forward-compatibility reasons, I can only assume) calls these functions by string-matching them. Which means that Python would actually try to call whatever function with the name of 'do_METHOD' (where method is the method stated by an HTTP-Client/Request) would be available. HTTP-method 'WORK' wasn't a thing...Until then. Therefore I could now call 'do_WORK' early and trigger a race condition. Beautiful.

These are just a few, but always remember: Computers do not make mistakes, humans do.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .