Buffer Overflow-Not getting the Correct output - stack

the Shell code print the hostname(bin/hostname). but when i execute the code its shows me the the path in reverse order but not printing the HOSTNAME.
I am actually doing the buffer over flow .
I am using freebsd intel machine.
this is my code
can you figure out please where is the error
//Prog 1
#include<stdio.h>
main()
{
char shellcode[]= “\x31\xc0\x50\x68\x6e\x61\x6d\x65\x68\x68\x6f\x73\x74\x68\x62
\x69\x6e\x2f\x68\x2f\x2f\x2f\x2f\x89\xe3\x50\x54\x53\xb0\x3b
\x50\xcd\x80”;
int i;
char buf[108];
i=strlen(shellcode);
printf(“%d”,i);
strcpy(buf,shellcode);
for(i=36;i<104:i++)
{
buf[i]='b';
}
buf[104]='\x2c';
buf[105]='\xfa';
buf[106]='\xbf';
buf[107]='\xbf';
printf(“%s”,buf);
return 0;
}
The Above program is injected into below program ...... so it creates the bufferover flow and print the hostname
#include <stdio.h>
int
main (int argc, char **argv){
char buf[100];
printf("Please Enter your Name");
fflush(stdout);
gets(buf);
printf("Hello %s \n",buf);
}
void notcalled(void){
//puts("cccc");
}

you are defining int I; and using i
the for is using a :i++, instead of a ;i++
strncpy() is missing the size_t param too

There is no buffer overflow in this sample code. You are simply printing the shell code, instead of executing it.
The code as posted doesn't even compile, due to things like quotes, i vs I problem, : instead of ; and strncpy needing 3 arguments (possibly more errors).
The shell code may be correct for freebsd, I can't check that. It definitely isn't correct for linux, though.

Apparently you are still not triggering code execution, even though now I see where you have your buffer overflow. Note however that overflowing the buf variable is trying to overwrite the return address for main, so it should print the text in any case. Also, the compiler may have generated a different stack layout than what you expect, or maybe your stack is not executable (although you should get a segfault in this case).
Use a debugger to single step through the code, beginning with the "return" statement in main and see what is happening. You will soon reach a RET instruction which should pop the starting address of your shellcode into the instruction pointer, effectively jumping to it. I suspect that is not happening for some reason.

Related

stack protector does not throw error with strcpy()

I'm testing an example of stack protector from ARM reference document (https://developer.arm.com/documentation/101754/0616/armclang-Reference/armclang-Command-line-Options/-fstack-protector---fstack-protector-all---fstack-protector-strong---fno-stack-protector), which has code like:
// main.c
#include <stdio.h>
#include <stdlib.h>
void *__stack_chk_guard = (void *)0xdeadbeef;
void __stack_chk_fail(void)
{
fprintf(stderr, "Stack smashing detected.\n");
exit(1);
}
void get_input(char *data);
char main(void)
{
char buffer[8] = { 0 };
char *overflowed = &buffer[8];
get_input(buffer);
// =============================================================
// The following line is added by me. This triggers stack smashing,
// but strcpy() should also trigger stack smashing detect.
// *overflowed = 0xFF;
printf("buffer: %s\n", buffer);
printf("buffer addr: 0x%08x\n", buffer[8]);
// =============================================================
return buffer[0];
}
// get.c
#include <string.h>
void get_input(char *data)
{
strcpy(data, "01234567");
}
I think this code intends to make stack overflow by accessing extra memory(buffer[8]) for NULL character using strcpy(). But the actual behavior is that no messages are thrown at all.
➜ stack_protector gcc main.c get.c -o test -fstack-protector-all
➜ stack_protector ./test
buffer: 01234567
buffer addr: 0x00000000
I checked that stack protector cannot detect smashing error if the stack size is smaller than 8 bytes, but this is not the case I think. Is there anything I am missing?
I stepped through the code with a debugger and figured out the stack guard value was not set properly. Its lower 8bits are always set to zero, which results in detection miss.
Since fs:0x28 register is set from the operating system, I reported this to my Linux distro's bug tracker.
--
(Added) I looked into Kernel code and there is code like:
/*
* On 64-bit architectures, protect against non-terminated C string overflows
* by zeroing out the first byte of the canary; this leaves 56 bits of entropy.
*/
#ifdef CONFIG_64BIT
# ifdef __LITTLE_ENDIAN
# define CANARY_MASK 0xffffffffffffff00UL
# else /* big endian, 64 bits: */
# define CANARY_MASK 0x00ffffffffffffffUL
# endif
#else /* 32 bits: */
# define CANARY_MASK 0xffffffffUL
#endif
Basically, initializing the first byte of the canary to zero is intended by kernel code. This is a kind of boundary that secures canary value from printing out. Due to \0 character, we can prevent canary value from printing out and this is the reason that I cannot reproduce stack overflow error with NULL character using strcpy().

How to get a wasm stacktrace

I'm looking for something gdb --core equivalent on webassembly.
Take this example:
//crash.cpp
#include <iostream>
int main() {
std::cout << "crashing soon..." << std::endl;
int *a = 0;
*a = 1;
}
I compile this with:
$ em++ -g4 crash.cpp -o crash.html --source-map-base http://localhost:8080/
And start the server:
$ emrun --no_browser --port 8080 crash.html
So how can I get a stack trace of this core dump/crash? The console on both chrome/firefox when visiting page just shows a js stacktrace and that won't help me. Looking at Sources => Call stack on chrome console just shows "Not paused", after the crash.
This is on debian 11, emscripten 2.0.12~dfsg-2, clang-11.
The reason is that what you're doing is not an error in WebAssembly. Like on many embedded platforms, writing to or reading from zero pointer is a perfectly valid operation in WebAssembly memory model.
However, Emscripten tries to help you catch this as for C/C++ it's a common mistake, so what it does instead is checks the value at the address zero after the program has finished execution and throws a helpful assertion if that value happened to be overwritten. For this reason you're getting a stacktrace with only JavaScript bits in it - because the check is done by JavaScript when Wasm stack has already been exited.
If you tried a different operation that does cause immediate abort, for example, assert(false), then you would see WebAssembly and/or C/C++ on the stack as expected.

puts(NULL) - why doesn't WP+RTE complain?

Consider this small C file:
#include <stdio.h>
void f(void) {
puts(NULL);
}
I'm running the WP and RTE plugins of Frama-C like this:
frama-c-gui puts.c -wp -rte -wp-rte
I would expect this code to generate a proof obligation of valid_read_string(NULL); or similar, which would be obviously unprovable. However, to my surprise, no such thing happens. Is this a deficiency in the ACSL specification of the standard library?
Basically yes. You can see in the version of stdio.h that is bundled with Frama-C that the specification for puts is
/*# assigns *stream \from s[..]; */
extern int fputs(const char * restrict s,
FILE * restrict stream);
i.e. the bare minimum, an assigns clause (plus a from clause for Eva). Preconditions on s and stream. Adding a precondition on s would be easy; things are more complex for stream since you need a model for the various objects of type FILE.

Parsing Command Line Parameters in C++. I'm having a strange error

I'm having a strange error when I try parsing command line parameters. Why do I call it strange? Well, that's because I've done a lot of research about command line parsing in c++ before hand, and nobody's test code works on my visual studio 2010 IDE. When I use the debugger, I find I always get a FALSE returned when I try to check for the parameters. In the example below, it's when I do a if (argv[1] == "-in"). I tried testing it several different ways in the watch window. And I tried passing it to a string first. Or using single quotes. Then I searched around the internet and used other people's code who supposedly got it working. What am I doing wrong? Is it a setting I have set wrong in my Visual Studio environment?
This is what I had originally
#include <iostream>
#include <stdlib.h>
#include <sstream>
#include <fstream>
using namespace std;
int main(int argc, char * argv []) //Usage FileSplitter -in [filename] -sz [chunk size]
{
if (argc==5)
{
string strTest = argv[1];
if ((argv[1] == "-in") && (argv[3] == "-sz"))
{
//Code here
}
}
}
Anyways that was my original code. I've tried tweaking it several times and I've tried using the code from the following websites...
http://www.cplusplus.com/forum/articles/13355/
He has some examples of comparing argv[1] with a string... and he says it works.
http://www.cplusplus.com/forum/unices/26858/
Also here a guy posted some code about a comparison.. Under Ryan Caywood's post.
They won't work for me when I try to do a comparison. I am thinking about just doing a legit strcmp, but I want to know WHY my visual studio environment is not compiling like it is on everybody else's system?
Also, during debugging, I input the command line parameters in the debug section of the project properties. I don't know if that would have affected anything. I also tried building and running the project, but alas, all to no avail. Thanks in advance to anyone who can give me some good advice.
Arguments are passed in through c strings, and so if I recall correctly, comparing them using == will just compare the pointers to them. Try using strcmp() to compare two c strings, or convert both to c++ strings and compare them that way, if you must.
You are doing the string compare incorrectly.
either do it C-style using strcmp() or (like suggested in the links you mention), convert to a C++ style string first.
if (string(argv[i]) == "stuff") { ... }

trying to run COBOL .exe using C++ program

I'm still learning how to program but I have a simple question. I have the following code for running an executable COBOL program through C++, but I am getting COBOL errors: 251 and 410
#include <iostream>
#include <windows.h>
using namespace std;
int main(){
system("C:\\rmcobol\\runcobol.exe SOLOCAJA.COB c=windows.cfg L=WOWRT.DLL");
cout << "\n";
system("pause");
return 0;
}
I assume there must be a very simple reason for this, but I am clueless so far. Any help would be highly appreciated.
Error 410 is a "configuration file not found" error based on Apendix A of the user guide. Are you sure your windows.cfg file is in the directory you're running your code in?
Failing that, error 251 states "Incorrect runtime command" and all the samples I can find have an uppercase C. So maybe change your C program to use to:
system("C:\\rmcobol\\runcobol.exe SOLOCAJA.COB C=WINDOWS.CFG L=WOWRT.DLL");
and see if that fixes it (a long shot, I know, but I've seen stranger things than that).
Based on update:
I tried changing the c to a C on the C=WINDOWS.CFG, ran it in C++ and directly on the Command Line, no change. I am still looking into the reasons behind this, and I read through tek-tips.com/viewthread.cfm?qid=1119251&page=5 but I couldn't use any of that info. Any extra tips would be gold at this point. THANKS!
A couple of questions:
Has it ever worked in this environment?
Is it failing on both cmdline and within C (just want to clarify)?
Does windows.cfg actually exist in the current directory when you run it?
Are you running it in a directory with spaces (like My Documents)?
Other than that, maybe post the windows.cfg file, though the error seems pretty explicit that it's config file not found rather than error in config file.

Resources