-
July 10th, 2005, 08:09 PM
#1
Junior Member
Does this server is vuln. to buffer overflow?
Hi!
I'm learning about buffer overflows! I writted a simple server, so I can see how remote buffer overflows work, but there is a problem! When recv(); recives data, the third recv(); argument specifies how much data it will recive, just like strncpy(); - how much data will be copied! Does this server is vuln. to buffer overflow's if I don't use strcpy();?
Code:
#include <stdlib.h>
#include <sys/socket.h>
#include <netinet/in.h>
int main(){
char buffer[10];
struct sockaddr_in server;
int addr_len, sock, sock_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
server.sin_family = AF_INET;
server.sin_port = htons(100);
server.sin_addr.s_addr = INADDR_ANY;
bind(sock_fd, (struct sockaddr*)&server, sizeof(server));
listen(sock_fd, 10);
while(1){
addr_len = sizeof(server);
sock = accept(sock_fd, (struct sockaddr*)&server, &addr_len);
while(1){
recv(sock, buffer, sizeof(buffer), 0);
if(strncmp("quit", buffer, 4) == 0){
close(sock);
break;
}
}
}
return 0;
}
Thank you!
-
July 11th, 2005, 12:06 AM
#2
Hi
Actually, an interesting question - because this is exactly the question I
asked myself, when I first read about buffer overflows So, I will answer
from my memory. In case I make an error (or in case of inprecision), I expect a lot
of replies I won't comment on the strcpy <-> strncpy issue - see Wikipedia[0].
In your particular case, you allow recv to copy maximally sizeof(buffer) bytes
to the buffer - which is safe. Recv() does not care whether there is more
data in the stream to be read or not - we could discuss ages about recv()
itself[1] (blocking, non-blocking, udp/tcp, ...), but let us focus on the main
problem here. I said, it is safe, if you can trust your implementation of recv(),
which you cannot control (except, you compile your own implementation).
But, when might recv() cause problems in principle:
Code:
char buffer[1];
(...)
recv(sock,buffer,1000,0);
For sure, you will overwrite something (notabene: you won't directly
overwrite the return address of recv()), and whether it can be exploited
depends on other details. When you perform a call to recv(), a memory
dump of the thread stack will show you something like
Code:
....00 <- address of the buffer to be copied in
....04 <- the pushed ebp
....08 <- the return address (eip)
....
....24 <- buffer to be copied in (allocated: only one byte!)
xxxxxx <- will be filled with stream byte
xxxxxx <- will be filled with stream byte
xxxxxx <- unknown area ? what happens here?
That scenario looks like very bad programming habit. But, in this
generic form, it happened in the past: What, if you just trust
the client's data (nowadays, you don't)? E.g. the client tells you:
"Hey, I know, you didn't really get how to deal with multiple
recv()-commands, without blocking the server, hence, here is the size
of data I will send you, which of course, trust me, is not more than the
maximum size of your buffer - hence, you don't have to check it"...
A recommended read is the "Secure Programming for Linux and Unix"-
HowTo[2], which has a chapter about buffer overflows. Some parts
are not specific to an OS, but to the programming language.
Cheers
[0] http://en.wikipedia.org/wiki/Buffer_overflow
[1] http://msdn.microsoft.com/library/de...ock/recv_2.asp
[2] http://howtos.linux.com/howtos/Secure-Programs-HOWTO/
If the only tool you have is a hammer, you tend to see every problem as a nail.
(Abraham Maslow, Psychologist, 1908-70)
-
July 11th, 2005, 11:24 AM
#3
In short: no, your server is not vulnerable to bufferoverflows
The above sentences are produced by the propaganda and indoctrination of people manipulating my mind since 1987, hence, I cannot be held responsible for this post\'s content - me
www.elhalf.com
-
July 11th, 2005, 01:08 PM
#4
Junior Member
-
July 11th, 2005, 02:18 PM
#5
Moderators -
This belongs in Programming Security.
"Data is not necessarily information. Information does not necessarily lead to knowledge. And knowledge is not always sufficient to discover truth and breed wisdom." --Spaf
Anyone who is capable of getting themselves made president should on no account be allowed to do the job. --Douglas Adams (1952-2001)
"...people find it far easier to forgive others for being wrong than being right." - Albus Percival Wulfric Brian Dumbledore
-
October 17th, 2005, 11:26 AM
#6
Junior Member
Sorry, I know it's a backward question, but what code is this? It follows the same format as the java I am familiar with, but I don't recognise it.
Cereal: Eaten at all times of the day.
-
October 17th, 2005, 11:51 AM
#7
Originally posted here by wheaty_bytes
Sorry, I know it's a backward question, but what code is this? It follows the same format as the java I am familiar with, but I don't recognise it.
It's C++ of course. Java has taken a lot of it's syntax from C++ which makes both languages very similar.
-
October 17th, 2005, 12:43 PM
#8
Originally posted here by Katja
It's C++ of course. {..}
No it's not. It's C, not C++ (stdlib.h is a C library and there's nothing OO about the source). It should compile without problems on C++ though.
Oliver's Law:
Experience is something you don't get until just after you need it.
-
October 17th, 2005, 12:48 PM
#9
but will not compile on most C compilers (implicit void in main being the first 'error')..
So I'd have to go with C++..
Quite C styled and using only C library's and includes.. but still C++
Well C and C++ have so many area's of overlap it's hard to see the difference
There are so many C and C++ deffinitions..
And you are quite free to abuse C and C++ together..
ASCII stupid question, get a stupid ANSI.
When in Russia, pet a PETSCII.
Get your ass over to SLAYRadio the best station for C64 Remixes !
-
October 17th, 2005, 12:54 PM
#10
Originally posted here by the_JinX
but will not compile on most C compilers (implicit void in main being the first 'error')..
So I'd have to go with C++..
Quite C styled and using only C library's and includes.. but still C++
Well C and C++ have so many area's of overlap it's hard to see usualy
And you are quite free to abuse C and C++ together
Compiles fine with gcc 2.95.3..(gcc test.c -o test) no errors, no warnings..
Oliver's Law:
Experience is something you don't get until just after you need it.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|