Page 3 of 3 [ 47 posts ]  Go to page Previous  1, 2, 3

CloudWalker
Veteran
Veteran

User avatar

Joined: 26 Mar 2009
Age: 35
Gender: Male
Posts: 711

07 Oct 2010, 8:23 am

I found it much easier than telling people what to do though. :?



LordoftheMonkeys
Veteran
Veteran

User avatar

Joined: 15 Aug 2009
Age: 36
Gender: Male
Posts: 927
Location: A deep,dark hole in the ground

07 Oct 2010, 11:01 am

Avarice wrote:
Argh... but it's so difficult. I admit, I know almost nothing about programming, and my most complex project is the one which converts Imperial measurements to metric ones but C just seemed too hard to bother with as a first language. I had the compliler running and some basic programs which added numbers together and showed the results before I couldn't be bothered continuing. It didn't help I tried learning it late at night either...


You're never going to get anywhere by just taking the easy street. If you want to get anything out of your education, you have to put something into it, and this means challenging yourself and going outside your comfort zone.


_________________
I don't want a good life. I want an interesting one.


Avarice
Veteran
Veteran

User avatar

Joined: 5 Oct 2009
Age: 32
Gender: Male
Posts: 1,067

07 Oct 2010, 4:12 pm

You're right, and I've always know that. This would probably be the best time to learn too, as I have large amounts of spare time. It was just unnerving to think that I may be going about it wrong, or that I was learning the language incorrectly, or one of several other complaints. I tend to overthink problems and worry too much. I might learn some C later today, I still have one of the books and my compiler is still there.

Something I did notice is that I remember what I learned in C better than what I learned in Python. I prefer the structure too, though I'm not sure why. How difficult was it for you when you started learning your first language?



LordoftheMonkeys
Veteran
Veteran

User avatar

Joined: 15 Aug 2009
Age: 36
Gender: Male
Posts: 927
Location: A deep,dark hole in the ground

07 Oct 2010, 4:25 pm

Avarice wrote:
How difficult was it for you when you started learning your first language?


It's sort of complicated. I started programming when I was 14, but I never really learned anything fully. My first experience was programming a TI-83+ graphing calculator, though I never did anything beyond basic flow control, mathematical calculation, etc. The first language I "learned" was C; I learned a small portion of it when I was 14, though I never touched a C compiler until about nine months ago. So yeah, it was easy, but that was because the only parts of it I learned were the easy parts, and even those I didn't fully understand. Last January I started actually learning C, and this time I got a more full education - structures, pointers, memory management, dynamic data structures, and other stuff that actually posed some sort of difficulty. I had a real hard time with it at first, and kept getting segfaults and bus errors whenever I tried to use any of those advanced dynamic features, though eventually I got stuff to work. I would still say I'm a novice a C though.


_________________
I don't want a good life. I want an interesting one.


Jookia
Velociraptor
Velociraptor

User avatar

Joined: 7 Jan 2007
Age: 30
Gender: Male
Posts: 410

07 Oct 2010, 8:00 pm

I was 13, it was funny.



Avarice
Veteran
Veteran

User avatar

Joined: 5 Oct 2009
Age: 32
Gender: Male
Posts: 1,067

08 Oct 2010, 2:35 am

LordoftheMonkeys wrote:
Avarice wrote:
How difficult was it for you when you started learning your first language?


It's sort of complicated. I started programming when I was 14, but I never really learned anything fully. My first experience was programming a TI-83+ graphing calculator, though I never did anything beyond basic flow control, mathematical calculation, etc. The first language I "learned" was C; I learned a small portion of it when I was 14, though I never touched a C compiler until about nine months ago. So yeah, it was easy, but that was because the only parts of it I learned were the easy parts, and even those I didn't fully understand. Last January I started actually learning C, and this time I got a more full education - structures, pointers, memory management, dynamic data structures, and other stuff that actually posed some sort of difficulty. I had a real hard time with it at first, and kept getting segfaults and bus errors whenever I tried to use any of those advanced dynamic features, though eventually I got stuff to work. I would still say I'm a novice a C though.


I first tried when I was 14 as well. Python was the language that I used, I was using a fairly crappy tutorial that skipped most of the steps and didn't really teach you how to build anything that would work, I tried for about a few weeks and didn't get anywhere. Then I tried when I was 15 and got a bit further, but I still couldn't produce anything that could be used. I started again two days ago and I've already made two working programs, so I suppose I wasn't ready or motivated enough before this. Now I'm trying C, for some reason or other I'm enjoying C more than I enjoyed working with Python.

Is it true that the 'gets' function can be a security risk (in larger programs)? I'd prefer not to get used to functions which aren't worth using.



mcg
Veteran
Veteran

User avatar

Joined: 26 Jan 2010
Age: 35
Gender: Male
Posts: 538
Location: Sacramento

08 Oct 2010, 3:15 am

Avarice wrote:
Is it true that the 'gets' function can be a security risk (in larger programs)? I'd prefer not to get used to functions which aren't worth using.
Yes, gets() does not let you specify the length of your buffer, so if the string you try to read in is too long it will clobber memory after the buffer. This allows people to feed your program specifically crafted strings designed to redirect the flow of your program to evil code. You want to use scanf() instead of gets().



Fuzzy
Veteran
Veteran

User avatar

Joined: 30 Mar 2006
Age: 52
Gender: Male
Posts: 5,223
Location: Alberta Canada

08 Oct 2010, 3:52 am

mcg wrote:
Avarice wrote:
Is it true that the 'gets' function can be a security risk (in larger programs)? I'd prefer not to get used to functions which aren't worth using.
Yes, gets() does not let you specify the length of your buffer, so if the string you try to read in is too long it will clobber memory after the buffer. This allows people to feed your program specifically crafted strings designed to redirect the flow of your program to evil code. You want to use scanf() instead of gets().


You can easily fix this by appending their string to a header string so that any function they write which does not follow your naming scheme will fail.


_________________
davidred wrote...
I installed Ubuntu once and it completely destroyed my paying relationship with Microsoft.


Ancalagon
Veteran
Veteran

User avatar

Joined: 25 Dec 2007
Age: 46
Gender: Male
Posts: 2,302

08 Oct 2010, 9:29 am

mcg wrote:
Avarice wrote:
Is it true that the 'gets' function can be a security risk (in larger programs)? I'd prefer not to get used to functions which aren't worth using.
Yes, gets() does not let you specify the length of your buffer, so if the string you try to read in is too long it will clobber memory after the buffer. This allows people to feed your program specifically crafted strings designed to redirect the flow of your program to evil code. You want to use scanf() instead of gets().

You can use fgets() to do essentially the same thing as gets(). fgets() requires you to provide a length argument (as well as a file stream, which you would set to stdin if you wanted it to act like gets() ).

Using scanf("%s" ...) can be dangerous also, unless you set a length parameter.

A lot of functions in the C standard library come in families, with slightly different names and functionalities, but all related, so if there's a dangerous function that doesn't do error checking, there's probably another function that does essentially the same thing, but in a safer way.

Overall, you'll be fine if you don't use something that just assumes you'll have enough space in your string.


_________________
"A dead thing can go with the stream, but only a living thing can go against it." --G. K. Chesterton


LordoftheMonkeys
Veteran
Veteran

User avatar

Joined: 15 Aug 2009
Age: 36
Gender: Male
Posts: 927
Location: A deep,dark hole in the ground

08 Oct 2010, 10:34 am

If you don't want to use gets(), there is also scanf(). It's like gets() but more powerful, and it's basically a reverse of printf().


_________________
I don't want a good life. I want an interesting one.


mcg
Veteran
Veteran

User avatar

Joined: 26 Jan 2010
Age: 35
Gender: Male
Posts: 538
Location: Sacramento

08 Oct 2010, 11:49 am

Fuzzy wrote:
mcg wrote:
Avarice wrote:
Is it true that the 'gets' function can be a security risk (in larger programs)? I'd prefer not to get used to functions which aren't worth using.
Yes, gets() does not let you specify the length of your buffer, so if the string you try to read in is too long it will clobber memory after the buffer. This allows people to feed your program specifically crafted strings designed to redirect the flow of your program to evil code. You want to use scanf() instead of gets().


You can easily fix this by appending their string to a header string so that any function they write which does not follow your naming scheme will fail.
No, gets() is dangerous because the gets() function itself will write past the end of the buffer. No clever appending after the fact can protect from this.



Jookia
Velociraptor
Velociraptor

User avatar

Joined: 7 Jan 2007
Age: 30
Gender: Male
Posts: 410

08 Oct 2010, 11:58 am

Quote:
SYNOPSIS
#include <stdio.h>

char *fgets(char *s, int size, FILE *stream);

char *gets(char *s);

DESCRIPTION
gets() reads a line from stdin into the buffer pointed to by s until
either a terminating newline or EOF, which it replaces with '\0'. No
check for buffer overrun is performed (see BUGS below).

fgets() reads in at most one less than size characters from stream and
stores them into the buffer pointed to by s. Reading stops after an
EOF or a newline. If a newline is read, it is stored into the buffer.
A '\0' is stored after the last character in the buffer.

CONFORMING TO
C89, C99, POSIX.1-2001. LSB deprecates gets(). POSIX.1-2008 removes
the specification of gets().

BUGS
Never use gets(). Because it is impossible to tell without knowing the
data in advance how many characters gets() will read, and because
gets() will continue to store characters past the end of the buffer, it
is extremely dangerous to use. It has been used to break computer
security. Use fgets() instead.

It is not advisable to mix calls to input functions from the stdio
library with low-level calls to read(2) for the file descriptor associ‐
ated with the input stream; the results will be undefined and very
probably not what you want.



Fuzzy
Veteran
Veteran

User avatar

Joined: 30 Mar 2006
Age: 52
Gender: Male
Posts: 5,223
Location: Alberta Canada

08 Oct 2010, 12:49 pm

mcg wrote:
No, gets() is dangerous because the gets() function itself will write past the end of the buffer. No clever appending after the fact can protect from this.


I think I lost the plot. Are we talking about python and executing code fed remotely to an application?

You can use a dictionary like a switch statement. It takes a string and returns a function name. You then call that function. If the person with malicious intent has violated the integrity of your application such that he can add entries to that dictionary of legal functions, you have more to worry about than buffer overflows.

Code:
funcdict = { 'OF' = openFile, 'CF' = closeFile, 'MA' = mundaneAction }
funcdict['OF']()


of course the function bodies have to be defined too.


_________________
davidred wrote...
I installed Ubuntu once and it completely destroyed my paying relationship with Microsoft.


mcg
Veteran
Veteran

User avatar

Joined: 26 Jan 2010
Age: 35
Gender: Male
Posts: 538
Location: Sacramento

08 Oct 2010, 8:32 pm

Fuzzy wrote:
mcg wrote:
No, gets() is dangerous because the gets() function itself will write past the end of the buffer. No clever appending after the fact can protect from this.
I think I lost the plot. Are we talking about python and executing code fed remotely to an application?
No, we're talking about the classic buffer overflow attack (OP was asking about the CRT function gets()).



Cicero
Hummingbird
Hummingbird

User avatar

Joined: 9 Oct 2010
Age: 65
Gender: Male
Posts: 22

10 Oct 2010, 1:00 pm

Programming is kind of my special area of knowledge. I wanted to be a guitar-savant, but never got any traction there.

For me, when a new concept arises, I almost have to get used to it and this can take months. After that, it is easy for me. So, maybe once you get some of the threshold concepts down, it might flow. I don't know whether this is asp or not, but I learn things very deeply and it takes a lot of time. I can't memorize very well,

So, for me, I amost have to become friends with some of the fundamental concepts before I master them. I grew up with procedural languages, and the notion of creating objects took me quite a while to get comfortable with. I was used to a contiguous and static memory space where I could find everything in a core dump (old timer here ;) ). I sort of had to learn how a memory heap works and how to allocate and deallocate from it before I could get comfortable with objects. I think other people may just be able to accept the layer of abstraction and move on.

So, what I am saying is that your initial difficulty may not reflect your ultimate aptitude or level of success.

PS. I program mostly in c# now.