Exploits in 3rd party code

z662

z662

Perhaps this is in the wrong section, I apologize if it is. I just wanted to clear up something that I have been trying to research for quite some time now but havent been able to find any definitive information on. I would like to know if an application (lets take firefox for example) has a known exploit in the code, if that code would also be vulnerable in BSD. I am asking this because I was under the impression that 3rd party apps need to be ported to BSD for compatibility and including the proper C libs. Of course I am referring to a general example, I know there isnt going to be an answer that would be the case ALL the time...but perhaps a certain type of exploit would pertain to BSD whereas other types wouldnt. Please advise.
 
sure it may have it probably depends on exploit....
portable code == portable exploits [at some point] (As I think)
 
A general example but still a valid question. And I'll take your firefox to elaborate. Short answer is, yes. It would also be vulnerable on freebsd, linux, openbsd, OS-X, Solaris or whatever other OS that particular software runs on.

The somewhat longer answer is that it really depends on the bug and the code. Big projects like firefox will most likely have some architecture or OS dependent code. This is, from the author of the software's point of view, not wanted as you want your code to be the same for all systems. That will make it easier to maintain. You really don't want whole chunks of code to be dependent on a certain OS or architecture. This also means a bug in the general code will be present on every one of the software's target platform. Whether or not it is successfully exploitable is a different matter. The bug is there.

To successfully exploit a known bug is heavily dependent on the architecture and the OS itself. It really doesn't work if you inject i386 code into a vulnerable Solaris/Sparc process. It also doesn't work if you inject linux i386 code into a freebsd i386 process even though both architectures use the same assembler/machine code. Besides that there are also some other features to worry about. Things like ASLR and stack protection, both software and hardware implemented. ASLR really works well on 64 bit processors because there's more address space to randomize. You could bruteforce your way through ASLR on a 32 bit processor. It's definitely possible to break your way through (or around) all those roadblocks. But that's what they are. Roadblocks. More roadblocks means it will be harder to pull off. Harder, not impossible.

So the actual working exploit needs to be fine tuned to the targeted OS and architecture.
 
Interesting... I knew that there was both sides of the coin in that one exploit may be portable whereas another wouldnt, but I didnt know all of the details that went along with it as you pointed out. This actually brings up another question I have, is each third party app ported by BSD maintainers and developers or is it more up to the application development team for that particular app. (or both) Is there a code audit process that it goes through to filter out bad code written by 3rd party developers? (I always thought there was a similar process for code audits for BSD...please correct me if I am wrong)
 
I wasnt referring to portaudit, I meant an audit process in regards to code review before it gets released and put into the ports repository.
 
killasmurf86 said:
porters probably don't digg into ports code unless it doesn't compile.
Click to expand...

^^^
However I'm not familiar with processes in FreeBSD, because there are some checks before port in placed in ports, but probably weather ports actually can be installed
 
killasmurf86 said:
porters probably don't digg into ports code unless it doesn't compile.
Click to expand...

Agreed. The maintainer's goal is usually to achieve the same functionality on FreeBSD as on any of the other platforms. Warts and all.

It's one thing to know enough about makefiles, compiling, etc. to be able to get a working executable from a distfile. It's quite another thing to know how to find and patch security holes in the ported app. Many maintainers can do the first, but not the latter.

So set your expectations appropriately. Don't assume that the maintainer has debugged the app. What he has done for you is debug the build and install process. That's still a valuable contribution.
 
To elaborate on what SirDice said above, in addition to depending on targeted OS and architecture it also depends on individual builds. I've witnessed a discussion with a professional pen tester, and he said systems like Gentoo are tougher to crack in many cases because the binaries are not standard across any two machines.

For BSD users that use ports rather than binary packages, the same benefit would hold. Tweak a couple of compiler flags in make.conf and you may very well make yourself immune to certain classes of exploits buy virtue of having a different binary than most other machines.

Of course, this alone should not give any one a sense of safety. Assume the services you expose to the internet at large can and will be exploited, and plan accordingly to reduce the potential damage.
 
Imagine how many port's we'd have if all codebase had to be checked for security vulnerabilities... millions and millions and probably billions of lines
 
SageRaven said:
To elaborate on what SirDice said above, in addition to depending on targeted OS and architecture it also depends on individual builds. I've witnessed a discussion with a professional pen tester, and he said systems like Gentoo are tougher to crack in many cases because the binaries are not standard across any two machines.

For BSD users that use ports rather than binary packages, the same benefit would hold. Tweak a couple of compiler flags in make.conf and you may very well make yourself immune to certain classes of exploits buy virtue of having a different binary than most other machines.

Of course, this alone should not give any one a sense of safety. Assume the services you expose to the internet at large can and will be exploited, and plan accordingly to reduce the potential damage.
Click to expand...

you may as well open other vulnerabilities by tweaking flags {My very own opinion}
 
you may as well open other vulnerabilities by tweaking flags {My very own opinion}
Click to expand...

This is indeed true, however it's probably unlikely unless you go crazy overboard with weird optimizations. And those are more likely to simply break the binary altogether.

It would only typically work against stack exploits, and those can now be made much more difficult (impossible?) with the new ProPolice extensions that are now enabled in FreeBSD by default.

Still, changing that "-O2" optimization to a "-Os" could possibly prevent attacks that may otherwise succeed against the same package compiled with the stock compiler flags.
 
When OpenBSD split off the code underwent some serious scrutiny by some seriously clever people. New additions to the code have undergone the same type of scrutiny. Even that didn't quite help as it still contained a few bugs. Still, it has a very good track record.

AFAIK FreeBSD doesn't have the same kind of scrutiny. Sure security is important and serious bugs need to be fixed. We still benefit from the efforts of the OpenBSD crowd though. Isn't open source and particularly the BSDs just lovely? Especially if I look at the number of serious bugs in the base. I consider FreeBSD the best combination of the other BSDs. A reasonably secure and stable racehorse.

With regards to the ports, I do believe ports on OpenBSD are more closely monitored. This is why Open has less ports then Free. But the security of the port itself is largely dependent on the author. The port maintainer just makes it work for us. If possible of course certain patches or modifications should be made 'upstream'. It helps if the port maintainer has a good understanding of the ported code itself.

Portaudit makes it easier to keep track of security vulnerabilities in one of the ports for us mortals :e
 
killasmurf86 said:
Imagine how many port's we'd have if all codebase had to be checked for security vulnerabilities... millions and millions and probably billions of lines
Click to expand...

You'd end up with the OpenBSD ports tree. :) From what I understand, they do code audits of the sources for things that go into their ports tree. Which is why there's only 10-20% of the number of ports in their tree compared to FreeBSD.
 
phoenix said:
You'd end up with the OpenBSD ports tree. :) From what I understand, they do code audits of the sources for things that go into their ports tree. Which is why there's only 10-20% of the number of ports in their tree compared to FreeBSD.
Click to expand...

Do you think they make audit for OpenOffice.org as well?
 
phoenix said:
You'd end up with the OpenBSD ports tree. :) From what I understand, they do code audits of the sources for things that go into their ports tree. Which is why there's only 10-20% of the number of ports in their tree compared to FreeBSD.
Click to expand...

There is no extensive code auditing of ports, there is more attention to security issues though, and upgrades and the likes are also a bit more conservative.

The main reason there are fewer ports is because OpenBSD is a smaller project ;)
 
You must log in or register to reply here.
Back
Top