We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

171

C and C++, contrary to most other languages, traditionally do not check for overflows. If the source code says to put 120 bytes in an 85-byte buffer, the CPU will happily do so. This is related to the fact that while C and C++ have a notion of array, this notion is compile-time only. At execution time, there are only pointers, so there is no runtime method ...


58

Compilation is not a directly verifiable deterministic process across compiler versions, library versions, operating systems, or a number of other different variables. The only way to verify is to perform a diff at the assembly level. There are lots of tools that can do this but you still need to put the manual work in.


56

Note that there is some amount of circular reasoning involved: Security issues are frequently linked to C and C++. But how much of that is due to inherent weaknesses of these languages, and how much of it is because those are simply the languages most of the computer infrastructure is written in? C is intended to be "one step up from assembler". There is no ...


53

It is impossible to analyze a program to find out if it will do anything malicious. That is true regardless of whether you are attempting to analyze the source or compiled code. The way to do what you are asking for is done by compiling and running the code in a sandbox. Once the program has terminated (or after a timeout you have decided upon) you destroy ...


49

I don't code for gcc, so hopefully someone else can add to this, or correct me. I'll edit it with responses. Some of these will not work for all circumstances. -Wall -Wextra Turn on all warnings to help ensure the underlying code is secure. -Wconversion -Wsign-conversionWarn on unsign/sign conversion. -Wformat­-securityWarn about uses of format functions ...


37

Actually, "heartbleed" was not really a buffer overflow. To make things more "efficient", they put many smaller buffers into one big buffer. The big buffer contained data from various clients. The bug read bytes that it wasn't supposed to read, but it didn't actually read data outside that big buffer. A language that checked for buffer overflows wouldn't ...


32

The Linux kernel can be viewed as a kind of ultimate shell code, since it is "injected" on a raw machine (which only has the BIOS code at that point) and then provides a lot of functionality. That kernel is written in C. If you write shell code in C or C++, you will run into trouble with library calls and linking, which are two facets of the same issue. ...


28

This is a really hard problem, and one all online code judges has to solve. Basically, you are asking how you can prevent somebody who can execute arbitrary code on your machine from taking it over. I have been coding on an online judge (Kattis) for a decade or so, and here are some of my experiences from building the security solutions for this kind of ...


25

First, as others have mentioned, C/C++ is sometimes characterized as a glorified macro assembler: it is meant to be "close to the iron", as a language for system-level programming. So for instance, the language allows me to declare an array of zero length as a placeholder when, in fact, it may represent a variable-length section in a data packet or the ...


22

Polynomial tells you what may happen, and how to solve it. Here I will illustrate it: I ran both binaries through strings and diffed them. That enough shows some completely harmless differences, in particular, the compiler used: GCC: (Debian 6.3.0-18) 6.3.0 20170516 | GCC: (GNU) 8.2.1 20181105 (Red Hat 8.2.1-5) ...


19

It is perfectly valid to write shellcode in any language that gets compiled down to machine code instructions. Provided no external libraries that are not linked by the victim program are required for its operation. However, it is almost never the case that directly compiled code (even from just C) is a valid, injectable shellcode. The most common reason ...


18

It is possible to have issues with printf(), by using as format string a user-provided argument, i.e. printf(arg) instead of printf("%s", arg). I have seen it done way too often. Since the caller did not push extra arguments, a string with some spurious % specifiers can be used to read whatever is on the stack, and with %n some values can be written to ...


12

There is plenty of malware out there that is written in .NET, but as a C# dev I can see why many malware authors avoid it: Easy to disassemble and reverse engineer. Easy for AV to detect use of certain classes and functions. Requires .NET on the box (older XP boxes might not have it, or might only have .NET 2.0) Harder to do anti-debug tricks in .NET than ...


10

This is extremely unsafe, to the point of being pointless: Your hash function is not a one-way function. One can instantly (with constant and low runtime) calculate an input producing any given hash if you allow arbitrary 4 character passwords as inputs by undoing the XOR with the initial hash value formed from the password length. With a little ingenuity, ...


9

Using unsigned integers does not prevent overflow. A k-bit variable can only represent 2k different values. No matter how you interpret the bits. What you're probably referring to is the fact that signed integer overflow in C and C++ is undefined behavior. Which means that the C or C++ international standard does not specify any behavior of the program that ...


8

32 bit hash function cannot be possibly safe for the purpose of password verification. Problem here is that it is "easy" to find a colliding password, that is, a password, that hashes to the "correct" hash value despite being different from the original password. On average it will take 2^31 password trials to get such collision, which is considered very ...


8

It's actually byte code. Bytecode, also known as p-code (portable code), is a form of instruction set designed for efficient execution by a software interpreter. Unlike human-readable source code, bytecodes are compact numeric codes, constants, and references (normally numeric addresses) which encode the result of parsing and semantic analysis of ...


8

Basically, you can't. What you look for is DRM by any other name, and history has shown time and time again that DRM isn't effective. Any skilled attacker in possession of the binary is therefore also in possession of the key, regardless of how well you hide it. Even if you were to store the key on your server and load it dynamically from the internet, the ...


7

As DeerHunter points out, pieces of information that should never be accessed by anything other than a hard-wired set of instructions can be stored in a Hardware Security Module. HSMs hold the key and can perform tasks that use the key, for example generating signatures, without the key ever being known outside the HSM. An HSM is not a box you keep an ...


7

Background: What you are seeing is machine language code. They are the data values that are actual instructions to a CPU chip. When a programmer writes a program in a higher level language like C or C++, tools called compilers take those instructions and turn them into the machine language. Normally, programmers don't care about those machine language ...


7

The rootkit replaces the legitimate call to EnumProcesses() with the address of its own implementation. Its implementation calls the original, but before it returns the list, it removes any mention of the processes it has been told to hide. While the behavior and outcome are similar, I consider hooking to be slightly different, because it can be done ...


7

It is not only possible, it has been documented several times in the past. http://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-960/GNU-GCC.html For example, http://www.cvedetails.com/cve/CVE-2008-1367/ shows a memory corruption attack that could lead to various types of compromise, if they were sufficiently exploited. A compiler is just ...


7

An aspect which hasn't been mentioned yet very clearly: suppose you have a multi-user system (as all modern PC OSes like Windows, Linux, Unix and so on are), and suppose you are a normal (non-privileged) user who can run "normal" application programs. Now you want to do something malicious to your PC (like installing a keylogger to get all passwords which ...


7

No, you shouldn't encrypt the password on the client if the transmission of data is secured. If you got it all perfect, you're not likely to add any security to the process. If you don't get it perfect, you might be introducing a new vulnerability (buffer overflow, oracle attack, etc). If the TLS version you're using somehow gets compromised, then you ...


7

In the particular case of a puzzle website, consider the alternative: don't bother. Ask participants to upload the output so you don't have to run untrusted code. This saves you computing power, avoids a security risk, and allows people to compete in any language. If there's a prize at stake, you can verify the winning entry later manually. If the form of ...


6

In addition to the answer by @Tom, I would also like to guide you to the OWASP code review guidelines, where some issues on using printf() are highlighted and this answer to a similar question on cs.stackexchange website.


6

Sounds like a fun project. I know you said "simple," but here are my thoughts anyway. The data you're writing the file over with isn't random, and one pass will still leave traces of the original data. It depends on the storage medium. For example, with magnetic devices, there's magnetic force microscopy. Even after ten rounds of the same thing, I'm not ...


6

The compiler itself is irrelevant; the rand() function is implemented in libc. The glibc implementation uses a linear congruential generator (LCG) or a linear feedback shift register (LFSR) for its rand(). These can be quite easily cracked given some of the outputs (which it seems you have). The details can be found in the answer to another question already ...


5

I think that having sensitive data (whether it is the password, or derived key, etc) in memory is not something that most systems deal with. That being said, here are several possible mitigation methods for protecting private data in-memory. This could apply to a variety of subjects, Server, Mobile or Desktop. The principals are the same. I'm also not sure ...


5

If you want to be 100% sure that some git repo doesn't contain malicious code, write it yourself; anything else will be an uphill battle. If someone's really truly trying to hide malicious code in plain sight, then you probably won't notice it. Take for example, the infamous 2003 nearly-a-backdoor in the Linux kernel where this harmless code: if ((options =...


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