Tag Info

Hot answers tagged

26

A few points: What you mean with encrypting passwords in the DB is hashing. That´s a big big difference. The first reason why DBs are used instead of hard coding user data is not security, but simplicity (add/modify/delete users without recompiling etc.) Storing passwords in plaintext is a problem, doesn't matter if they are in your program or in the ...


23

It's not that simple. With the huge number of platforms on which the program could have been built, it can be extremely difficult to replicate the original build environment. Because of this, you could be using a different compiler, with different settings, using different versions of libraries. These slight variations in the environment can definitely ...


20

Compilation is a mostly one-way operation, and it is not deterministic, at least not in a robust way. You could recompile the source code and see if it yields the same binary. However, the exact binary can vary depending on a lot of parameters, including the compilation options and the exact version of the used compiler. Moreover, some compilers embed some ...


17

There must be some security hole in the application. Think like any very-simple-and-common .txt file: if you open it with an hex viewer, or with a well-designed textpad editor, it should only display the file content, and ok. Then think about of processing the file, somehow, instead of just showing the contents. For example, reading the file and ...


15

If you compile the code yourself, then you may obtain the same binary. Or not. Basically, your chances are good if the compiler uses deterministic optimization algorithms (that's the usual case) and you use the exact same compiler version with the same command-line options (that's usually much harder to ensure). Deterministic re-compilation is easier with ...


11

It depends on the situation - type of application, deployment model, especially your threat model, etc. For example, certain compilers can substantially change some delicate code, introducing subtle flaws - such as bypassing certain checks, that do appear in the code (satisfying your code review) but not in the binary (failing the reality test). Also ...


11

This quickly turns into a 'turtles all the way down' problem. You just have to decide at which point you stop encrypting things and rely on another method. I think the goal should be to stop casual users, but not determined hackers, to easily get at the protected data. I wrestled with a similar method in a web application which needed to store the DB ...


10

Such an attack relies on the image parser containing a bug that allows the execution of what would otherwise be a slightly wacky picture. For example, instead of "red" being interpreted as a color, the computer may try to interpret it as a shell command.


10

If you can recompile the source code and have your own binary, then maybe you won't be able to get the exact same binary as the one that is distributed; but why would it matter ? At that point, you have your own binary, which necessarily matches the source code (assuming your compiler is not itself malicious): you can just ditch the binary package, and use ...


10

Yes it is possible. But it is very hard, as the whole compilation process hasn't been designed for that goal. It is often called "deterministic builds", "reproducible builds", "idempotent builds" and is a challenge. Bitcoin, Tor, and Debian, are attempting to use deterministic builds, and the technical process is described here. Admittedly the process is ...


10

Please, do not Hard Code credentials or hashes. Hardcoded passwords may compromise system security in a way that cannot be easily remedied. [...] it also makes fixing the problem extremely difficult. See OWASP page about Hard Coded Passwords [...]many hashes are reversible (or at least vulnerable to brute force attacks) - and further, many ...


9

There are two ways for a piece of code to be executed: intentionally and unintentionally. Intentional execution is when a file is read by an application and the application does something based on whatever the file says. Reading the file is called parsing the file. Unintentional execution is when the parser reads something it shouldn't, and instead of ...


8

Much more common than a buffer-overflow type bug that @Zian mentions (though I think there was a WMF vuln of this sort in Windows as recently as 4-5 years ago), is something like GIFAR (also search on SO): a file that is both a valid image file (e.g. GIF), and a valid ZIP file (e.g. JAR (compiled java bytecode)). This is possible because of the way these ...


7

As usual, the best place to start is by asking yourself some questions: What's your threat model? What are you trying to protect? Who are you trying to protect it against? Why are you using crypto in the first place? None of these is clear from the question. (Crypto is not magic pixie dust.) And without answers to those questions, we cannot give you a ...


7

@AviD solid points, totally agree on the root kits on binaries/compilers component. If you're a knowledgeable sec professional, setting aside the valid points AviD makes, the most vulnerabilities will most likely be in your source code. Having a strong knowledge of programming securely and how reverse engineering is accomplished should give you the best ...


6

You should not envision things as a "black list" of things to trap. Black lists don't work. At least, they don't work well. Instead of trying to work out a list of "forbidden system calls", you should instead create a list of "definitely harmless system calls" which you explicitly allow. What you need is a sandbox. The Chromium Web browser (the open-source ...


6

Most of the time, it's only just barely safer, and sometimes it's less safe. Under what conditions can I simply download the exe(cutable?) Signed packages from major distributions are built on the Distribution's build servers. In that regard, it's almost certainly best to use the packaging system. Are there times when I should I compile the binary ...


6

It is not actually "well known". The story comes from a classic must-read article from Ken Thompson. Though it was implemented at that time as a demonstration, it would be challenging to do it on a larger scale. The main problem here is about software updates. For the malicious binary chunk to be reinjected in the compiler, should the compiler be recompiled ...


5

I assume when you say "image" you mean something like a JPEG or a GIF. The answer is that older software has bugs such that when they display the image, they can get confused. For example, images have comment fields inside them that are usually not displayed, but can contain things like the GPS coordinates of the iPhone camera that took the picture. Typical ...


5

No. EDIT: Actually, possibly. See below. The compiler really only cares about the source files. If you want a GUID to be in the assembly you need to code it in. Thats how for instance the COM interop stuff works -- you decorate the assembly in code with an attribute that contains the GUID. However, if a GUID is hardcoded into the source for something like ...


5

Ultimately, the CPU runs the code. And the CPU expects instructions in "clear text". You could envision some application code where a small initial part of the executable first decrypts the rest of the code, but this has several issues: This forces all the code to go to RAM instead of staying on disk and be loaded on-demand, implying a higher RAM ...


5

Let me first state that I do not know any case where only the precompiled executable file of a FOSS project contains malicious code. So if you are looking for concrete examples, this answer probably isn't for you. The biggest advantage of compiling the code yourself is the ability to read through said code and determine what the code actually does. This is ...


4

The key problem with pdf's, Word documents etc is that the current standards allow macros and executable code. (In my opinion this is a fatal flaw, but then I like emails to be text only...) It is that macro execution stage that is usually the target for attack, as it provides a way to run code. The attacker just needs to figure out how to get past the ...


4

There are plenty of reasons aside from security-related ones to look into the final binary. Either by means of a debugger, disassembler or a profiler and emulator like Valgrind (which can verify various aspects of a compiled program). Security and correctness of the program usually go hand in hand. For me it's first linting the code (i.e. using PCLINT), ...


4

I use SLP Server from InishTech. http://www.inishtech.com It was formerly developed by Microsoft, and was spun off into a 3rd party company. SLP is a technology that protects software running on Windows platforms and addresses many, if not all of your concerns. I've been communicating with their sales rep and they have some cost-effective plans for small ...


4

One could write books about these things and not ever be satisfied. Let me try to answer this in general, without naming special products. Binary/Bytecode Analysis Advantages (mostly) Programming language agnostic Can be run on closed source binaries/libraries you got from wherever Can find flaws introduced due to compiler bugs (or undefined behaviour of ...


4

That is actually far less secure. In an ideal world, where your database is not sitting in the DMZ but is instead only accessible directly from your web server, and then with limited account rights, in order to breach your database and retrieve your hashed password table, I have to: Expose your software database connection variables (account/password) by ...



Only top voted, non community-wiki answers of a minimum length are eligible