Sup, everyone. I wanted to see how different CVE vulnerabilities look in real code examples. Not exploits, but vulnerable code. So, does anyone know if there is a site, git repo or anything with such stuff? Or i just have to search git for fixes of vulnerabilities and compare code like before/after?
This is a little bit of vague question.
However, when it comes to WebApps OWASP is a great resources. They have a number of projects e.g. WebGoat. This gives you both examples of insecure code and also tutorials around how to avoid the problems.
Of course, this doesn't necessarily include all recent CVE's, but is a great example of some real code examples.
Well, i'll post what i've found on the topic just in case. The original question resulted from my lack of knowledge about CVEs being an outcome of CWE exploitation. So, i should've been looking for code examples containing CWEs instead of CVEs. Hence, the web-site i was looking for is nist gov and their Test Suites.
Related
I'm using pyperplan in my project, however I'm very limited in choice of planning domains, as pyperplan does not support PDDL v2
Do you know of any pyperplan fork, that has this functionality? Basic +1 action costs should be enough, they are my only problem right now.
Eventually, do you know of any pyperplan-ish alternative that would support more modern versions of PDDL?
I'm planning to implement the functionality on my own, I ran through the code, and it shouldn't be THAT hard, it looks pretty set up for that.
I went through all forks listed on github, but none of them has this feature. I've also tried looking up such clone myself, or looking up any related articles, but nothing of value showed up.
I will be really grateful for any tips!
We have a large number of repositories. We want to implement a semantics(functionality) based code search on those repositories. Right now, we already have implemented keyword based code search in which we crawled through all the repository files and indexed them using elasticsearch. But that doesn't solve our problem as some of the repositories are poorly commented and documented, thus searching for specific codes/libraries become difficult.
So my question is: Is there any opensource libraries or any previous work done in this field which could help us index the semantics of the repository files, so that searching the code becomes easy and this would also help us in re-usability of the codes. I have found some research papers like Semantic code browsing, Semantics-based code search etc. but were of no use as there was no actual implementation given. So can you please suggest some good libraries or projects which could help me in achieving the same.
P.S:-Moreover, companies like Koders, Google, cocycles.com etc. started their code search based on functionality. But most of them have shut down their operations without giving any proper feedback, can anyone please tell me what kind of difficulties they are facing.
not sure if this is what you're looking for, but I wrote https://github.com/google/zoekt , which uses ctags-based understanding of code to improve ranking.
Take a look at insight.io
It provides semantic search and browsing
When discussing (asking/answering questions about, writing blog posts about, etc.) some programming matters, it may be desirable to give source code examples of what you're talking about; but in some cases these snippets may be dangerous, not because they are directly harmful but because they seem to work at first but only set up for problems later. Two examples would be when discussing concurrency issues, where the code works most of the time but rarely and non-deterministically fails, and when discussing security issues, where the code seems to work but can in fact be exploited; and there could be other examples.
It is necessary to be able to discuss such issues, to foster awareness of them at least. However, I am always worried that someone will come from a search engine, barely read the post, copy and paste the snippet and use it for something; more subtly, someone may read the post, try out the code in a test project and confirm it can indeed be exploited (as he is encouraged to do), then some time later reuse the dangerous code, as he has forgotten the code is dangerous and there is no longer a blog post explaining why the code is dangerous around the snippet.
So I am wondering how to mark such code so that no part of it somehow makes it to production (or if it ever does, then the responsible party could not plausibly deny awareness).
One way I came up with is to put:
an #error (or similar) directive inside each of the functions, as well as
repeated comments warning of the dangerousness of the code (since someone who will try out the code in a test project to confirm the issue will have removed the #error directive).
But since these comments would only clutter up the snippet when reading on the web, I make them the same color as the background (or at least I am trying to; see how I put it in action here, I incidentally have a question on doctype.com asking how to best do this).
If that seems completely overkill, remember that concurrency (and security) issues are very dangerous so I want to do all I can (within reason) to prevent my snippets from causing issues in real software; I am sometimes comparing this to fissile material handling.
(I honestly don't know whether it would be best suited for programmers.stackexchange.com or here, so I'm asking here first; feel free to move to programmers.stackexchange.com if it turns out it would be better there.)
You make a very good point and I think that you handle it pretty well right now.
However, the #error lines show up in the blog post for me, they are not white.
I think that you shouldn't worry so much about it being picked up by a feed or something like that. If the code is pulled away from the warning message on your blog, it's more important to have the #error lines visible.
But overall, I like your system. I might be good idea to set some standard for this, though, as programmers.
I would however add a link to the original post explaining why it is bad, too. That is way more important than just saying it is.
So to summarize: good idea, we should think of a standard. Make sure to include a link to a why.
Personally, yes, I think it's overkill.
I don't think you need to concern yourself with someone who extracts and uses the code without reading the context in which it's given. Such a programmer will likely be making so many other mistakes as to render using your code largely irrelevant.
In short they will have and be creating bigger problems.
I am the lone software engineer on a team that develops physics models (approx 30,000 lines of code). The rest of the team consists of scientists who have been developing their codebases for about 20 years. My workflow goes something like this:
Scientist requests a new feature
I implement it
Via testing & validation, I find a serious problem somewhere deep within the numerics
Scientist requests a new feature (without fixing the problems identified in #3)
Our problem seems to be that bug tracking is done via e-mail and post-it notes. Busy work schedules let bugs slip under the radar for months and months. I think some formalized bug tracker (i.e. Trac, Redmine, Jira, FogBugz, etc.) could help us. The following features are essential:
Incredibly easy to use
Integrate with version control software (we use Subversion)
There are plenty of posts that suggest which bugtracker is "best"... but I suppose that I am more interested in:
What's your experience in whether or not the overhead of a bugtracker is worth it
How do you convince a physicist (who follows poor software engineering "best practices" from the 70's) that a bug tracker is worth the extra effor?
I get the feeling that if I install a bug tracker, I'll be the sole user. Has anyone else experienced this? Is it still useful? It seems like the team would need a certain amount of "buy-in" to make a bug tracker worth the additional overhead.
Bug trackers are definitely worth it, in part because they formalize the work-flow required to implement new features and fix bugs. You always have a central place for your work load ("My bugs", "My tasks", etc). Pretty much every environment that I've worked at in the last few years has had a bugtracker of some sort so I'm not sure what to recommend in terms of buy in. Do you have more than one scientist coming to you for feature requests/bug fixes? If so, then perhaps you could use the bug tracker as a conflict resolution system of sorts. Do you have a boss/manager? Then having a bug tracking system would provide a lot of insight for your boss.
In general, as a software developer, bug trackers have been very useful. My suggestion would be to think of ways that a bugtracker would enhance your & your coworker's life. Maybe do a quick demo.
HTH.
In my experience, the overhead of a bugtracker is noticeable but definitely worth it! The catch is that if you decide to use a bug tracker, it can only succeed if everyone uses it. Being the sole user of such a system is not quite as useful.
Having said that, even if I am the sole user (which tends to happen a lot), I still install the bugtracker (typically trac). If you use it religiously (enter every thing that comes in through different means as a bug and ALWAYS refer to bug# in your replies), the team generally tends to pick it up over time.
Enter milestones (or whatever your tracker of choice calls them) and link bugs to them. Whenever someone asks what the progress of something is, call up the milestone report or equivalent and SHOW THEM. This helps convert people from thinking of the bug tracker as a nuisance to realizing that it can be a source of invaluable information.
I suggest taking a look at Strategy 2 in this Joel On Software article. He basically argues that if your company doesn't use bug tracking software, you should just start using it for yourself, and demonstrate how it helps get things done. Also ask other people to use it to submit bugs so they see how easy it is to use.
Even if you're the sole user (it happened to me once), it's worth it. You can start saying things like, "Bug 1002 is blocking. Who can help me with that so we can move on to this and that feature."
We found redmine to be a better than trac simply because it is easier to use. It does lack some of the features found in some of the other systems, but this also means there is less stuff for non-programmers to have a problem with. It's also very nice because it allows someone other than the programmers to get a feel for the current state of the system. If there is a large number of critical unclosed bugs it is easier to make people understand that their requested feature will have to wait a little.
This is a similar question.
What's the Most Effective Workflow Between People Who Develop Algorithsm and Developers?
It does NOT speak to which bugtracker is best, but it does speak to how to convince the physicists to buy-in.
Using subversion? Here's a /. post that is helpful:
Best Integrated Issue-Tracker For Subversion?
An in general, here's a Comparison of Issue Tracking Systems.
I understand the general idea of how vulnerabilities are exploited. Buffer overflows and stuff like that, but I guess I don't REALLY get it.
Are there useful sources of information that explain this area well? Maybe case studies about how particular vulnerabilities were exploited?
Even more interesting would be how projects you have worked on suffered from these kinds of issues.
I'm not trying to learn about currently existing vulnerabilities that I could exploit. I'm trying to get a feel for how this area could have an impact on any projects I may work on.
iss.net has articles on different examples of exploits, mainly explaining how to secure your system.
The corelancoder tutorial! A must read
https://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/
Part 1 is a single BOF on windows, ... , Part 12 is ROP. It is hard, but the first one can be done in a day or two, and it should give you a real feeling on which difficulties one finds when writing an exploit, and on which countermeasures are useless/useful.
The problem with this area is that it is unclear until you try out something on your own, but that requires time. You could also check Metasploit to exploit problems directly (to have an idea of the impact) - you will find a list of exploit to fire to a target. If you need a target, use Metasploitable http://www.offensive-security.com/metasploit-unleashed/Requirements#Metasploitable
If you want practical examples of real life exploits, I totally recommend the book
"A Bug Hunter's Diary: A Guided Tour Through the Wilds of Software Security"
It's exactly what you want. It's full of case studies and real life examples of almost every type of exploits and it explains it from the finding to fully writing a working exploit.
Also there are some examples in the book "The shellcoders handbook" but it's not as comprehensive as "The bug hunter's diary" Also "The shellcoders handbook" is pretty big and I only use it as a reference when needed.
Also sometimes I keep reading exploits from "http://www.exploit-db.com" and it helped me a lot but keep in mind not everything can be taught so sometimes you will need to improvise based on what you have and what you can control it's hard at first but it will make you feel great when the exploit runs and you see that calc.exe :)
Of course corlan tutorials and other tutorials are a must to know the essentials but they only teach you the basic concepts and you have to see some real life exploits in action to really understand the possibilities.