Does this server is vuln. to buffer overflow?
Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Does this server is vuln. to buffer overflow?

  1. #1
    Junior Member
    Join Date
    Feb 2005
    Posts
    8

    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!

  2. #2
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    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)

  3. #3
    Senior Member
    Join Date
    Jun 2003
    Posts
    772
    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

  4. #4
    Junior Member
    Join Date
    Feb 2005
    Posts
    8
    Thank you very much!

  5. #5
    AO Senior Cow-beller
    Moderator
    zencoder's Avatar
    Join Date
    Dec 2004
    Location
    Mountain standard tribe.
    Posts
    1,177
    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

  6. #6
    Junior Member
    Join Date
    Oct 2005
    Posts
    18
    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.

  7. #7
    Banned
    Join Date
    Jul 2005
    Posts
    511
    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.

  8. #8
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401
    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.

  9. #9
    Leftie Linux Lover the_JinX's Avatar
    Join Date
    Nov 2001
    Location
    Beverwijk Netherlands
    Posts
    2,534
    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 !

  10. #10
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401
    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
  •