Hot answers tagged

26

Only Meltdown is specifically an Intel vulnerability / design flaw. update: it seems AMD is mostly resilient to Spectre. It's not clear why that would be the case. But according to AMD: (from early January, now replaced, see update 2 below) Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. ...


26

No. Most likely, you got that 64k limit from the Heartbleed bug, hovewer it is purely because in HTTPS Heartbeats the length field was 16 bits long. It doesn't mean that in your case your software will not have a buffer overflow reaching far further. So while yeah, this could add a tiny bit of security, you must always assume that buffer overflows can affect ...


20

I see multiple problems with your shellcode. First of all let's debug your code. I compiled the C code containing your shellcode, run it with gdb and step until the first system call (int 0x80) [----------------------------------registers-----------------------------------] EAX: 0x5655700b --> 0xde3050f7 EBX: 0x5655550c (<main+35>: mov eax,0x0) ...


19

The best advise for avoiding buffer overflow bugs in C is to not use C in the first place. The design philosophy of the language was that whenever they had to choose between efficiency and safety, they picked efficiency. The result is a language which can be used to write very fast and memory-conserving programs, but unfortunately at the expense of security. ...


8

No. Actually, most RoP attacks make use of existing codes (former return-into-libc-attacks). So, the RoP gadgets are snippets of existing code and have to be executable.


8

Creating a ROP chain is a difficult, creative, laborious yet exciting process. Generally speaking, when we are using ROP, we are trying to bypass DEP. After all, if we have control of EIP and can write to and execute the stack, why not just jump to our shellcode? With that in mind, it is important to remember that entire payloads are not, generally, written ...


8

The x86-compatible CPU are aptly named: they are compatible with each other. This means that the same OS code will work on all of them. So, from the point of view of the code which runs on the processor (which includes the operating system itself), things do not vary (much) depending on the brand. Things change depending on the generation: the newer systems ...


7

One of the known security approaches is to put a "canary" on the stack that would be damaged (modified) by the buffer overflow, if any would occur. It need not be so big, and it must be initialized with some values that attacking program is unlikely to know. After doing a IO, you can then check if the contents of this buffer have not been touched by the ...


7

If you are running this from the command line, and you are using the < to feed the shellcode from a file, the shell will immediately terminate when it reaches the end of input. If you want it to remain keyboard interactive, do this: cat shellcode.hex - | ./vulnerable_program The - is stdin (keyboard input in this case), so you can type as you wish ...


5

First, this is not an OS question but more of a compiler one. OS can only execute binary programs that contain machine instructions and that can (if they were instructed to) test the overflow flag. So a part of the question is (IMHO): Why does not the C compilers allow to test the overflow flag? The reason is that the language is supposed to accept (almost)...


4

I was interested in the same issue and did some preliminary research. I'll try to answer some of the questions, though as a non-AMD engineer I cannot be certain. Does it have software-updatable firmware? Yes, it does. This firmware is part of the AGESA (AMD Generic Encapsulated Software Architecture), a binary blob distributed from AMD to UEFI firmware ...


4

So what I would say is anything that provides direct memory access and essentially does processing on behalf of the processor is a whole other set of threat surfaces you are introducing to the computing platform. So I would say the threat surface is similar if not the same. The way that PSP is supposed to operate, in many ways mimics ME but, it will also ...


4

Making the injected payload "not executable" is what Data Execution Prevention is about. There are various techniques to achieve that, depending on what the underlying hardware can do. On most architectures, this will be done through the MMU: pages that are supposed to contain "data" (e.g. the stack) are marked as non-executable. Old x86 CPU makes DEP a bit ...


4

I ended up writing my shellcode in a different way. As I could not figure out how to return, I let the kernel do the heavy lifting for me, in returning to userland. The idea was to execute my privilege escalation bit, and jump back to where the vulnerable function was supposed to return, with the registers and stack fixed up. As soon as the kernel returned ...


4

If you have tried shellcode before which relies on absolute addresses, then that could explain the crashes. This shellcode survives because it uses call to obtain the absolute stack pointer address and then modifies the buffer in-place without other stack modifications. For a full understanding, it might be illustrative to see what is happening, linearly: ...


4

why aren't operating systems using this overflow flag to stop integer overflows? The operating system can't just forbid integer overflows, because sometimes it's not a bug but a feature. There is software out there which contains algorithms which actually rely on integer overflow behavior and would break if it would no longer work the way it does. Users ...


3

You are right that the buffer cannot overflow the flag because of the bounds check. Fgets also includes the null character in its bound check. http://www.cplusplus.com/reference/cstdio/fgets/ However, there is a string format vulnerability here: printf(buf); The user-controlled variable buf is used in a printf statement, causing a format string ...


3

Assuming that you're talking about a vanilla EIP overwrite and not something like SEH, you have two options available to you. Neither of these are what I would consider to be "beginner" techniques as they require a bit of Assembly knowledge though there are some great websites that can help you out. 1. Employ an Egg Hunter. An egg hunter involves sticking ...


3

Returning to normal execution from shellcode is hard. You're exactly right. Your function likely doesn't have a valid return address. I'm not entirely sure this is your problem, but your attempt to put the return address on the stack is incorrect. You would want your Target function's return address to be above you in the stack, not below it. As it is ...


3

Have a look at mona by corelan https://www.corelan.be/index.php/2011/07/14/mona-py-the-manual/


3

There's a good way to solve problems (2) and (3) in the described manual binding process but I'm reluctant to publish good and elaborated public tutorial about designing shellcode here on StackExchange. ^_^ So, there's a hint for you of using crcs for (2) and indirect calls for (3) - you seem familiar enough with the manual binding process to deduce the ...


2

int 0x80 is a really old way to make system calls. I'm not sure if it is even supported anymore. You might want to look for syscall/systenter instruction in the image. Ofcourse this depends on what underlying hardware and OS you are using. If you are using any hardware/hardware vm emulator and software newer than from 1995, you should probably be looking for ...


2

Based on what I see here, you can modify *src after ValidateOpcodesOrCrash finished checking that part of the memory but before SafeMemcpy starts. I don't know how ValidateOpcodesOrCrash is implemented, but presuming that it simply loops through [src,src+size] and look for illegal instructions, then you can call with a fairly TrustedPart_for_safe_jit large ...


2

TL;DR The reason why they're bad is listed in the links you've provided. Due to how the Windows OS is designed, the way the functions were coded, and the fact that determining if memory is valid is hard makes these functions inherently unstable to use. There is no good way to determine if a pointer is using a valid part of memory. Freed memory doesn't ...


2

Answer: Low-level vulnerabilities, such as buffer overflows in the stagefright binary or underlying Linux kernel, will behave differently on every system that you run them on (ie: x86 Android, QEMU ARM, native ARM). Userland-level security vulnerabilities will be largely the same as they live at a high level of abstraction from the processor architecture.


1

flag is not local to any function and global in scope. Therefore, it is not located on the runtime stack. Either patch the binary or take advantage of the fact that input to buf is not sanitized and that buf an argument to printf (manipulate the value of the format string argument such that 1337 is written to address 0x601084). flag is a statically ...


1

The Assembly that you've posted is not the shellcode, as you mentioned but rather the unpacking and execution of the shell script. The shellcode being executed is \xeb\x1f\x5b\x31\xc0\x88\x43\x0b\x88\x43\x18\x89\x5b\x19\x8d\x4b\x0c\x89\x4b\x1d\x89\x43\x21\xb0\x0b\x8d\x4b\x19\x8d\x53\x21\xcd\x80\xe8\xdc\xff\xff\xff\x2f\x2f\x2f\x2f\x62\x69\x6e\x2f\x63\x61\x74\...


1

There are various ways to do this. Are you able to get a fixed point in the code to set your EIP to? You are not telling us whether you have any ASLR restrictions, but if you do, are you then able to still get a fixed location to refer to? Look into: https://www.corelan.be/index.php/2009/07/23/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-...


1

int $0x80 is indeed executed by some of the C library functions in the statically linked binary, but not by nearly as many library functions as one would expect given how many library functions are included in the binary: $ objdump -dj .text binary | grep "cd 80" 8049401: cd 80 int $0x80 806c465: cd 80 int $...


1

There's no need to perform any push operations since you control the stack already. You can have the data you wish to store within your registers already placed where you can conveniently perform operations with them. In ROP, you find a series of useful code snippets present already within your target program that you can refer to as gadgets, which are ...


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