Announcement

**jesse** · July 21, 2003, 12:52

Re: scene degradation

I'm more disturbed by the lack of linebreaks in that post.

It's hard to believe that buffer overflows are still the predominant method of rooting a box when programmers should have learned years ago not to have them--stupid fucking people.

Because there is no patch for human stupidity.

**telco88** · July 21, 2003, 13:22

interesting first post

stop breaking the pills in half.....it appears you need to up your dosage.

**astcell** · July 21, 2003, 13:31

cyn0n, we differ from you in that we get enjoyment from LEGAL activities.

**bascule** · July 21, 2003, 13:51

It's hard to believe that buffer overflows are still the predominant method of rooting a box when programmers should have learned years ago not to have them--stupid fucking people.

As the size of a codebase balloons, especially in the case of a C codebase, complexity and interdependancies of portions of code become increasingly more difficult to analyize. Most buffer overflows are not caused by "obvious" errors in the code, but arise from errors which crop up in highly complex code.

I believe there are two schools of thought on this subject. The first is that buffer overflows (as well as other problems such as memory leaks) are inevitable in a language as low-level as C. The solution then becomes to eliminate the low-level aspects of the language and handle program execution in a "sandbox" environment which provides a considerable degree of run-time checking. Pointers and other low-level constructions are replaced by high level constructions, which should in theory eliminate some of the complexity by encapsulating some of the logic which would have appeared within the C code intermingled with other core parts of a program's functionality within the high level language constructions present in a particular language's standard library. This is the approach taken by a number of modern languages and runtimes, such as Java, C#/.NET, Perl, Python, Ruby, and many others.

The second is that complexity is an indicator of bad design. The solution is increased modularization and componentization of the code, with the aim of keeping all parts of the code as simple as possible without compromising necessary functionality. This approach is taken by programs like qmail, which also tries to fully leverage parts of the Unix environment in order to reduce complexity.

The disadvantage of the first approach is that it significantly increases the resource usage of a particular program, thus decreasing its performance and scalability. Furthermore, deploying a program designed for a particular runtime environment is typically more complex than deploying a program compiled to native code (which is only compounded by the fact that the runtime environment may need to be installed as a dependancy) For these reasons we have not seen widespread adoption of Java web servers, FTP servers, SMTP servers, etc.

The second approach has a terrible disadvantage in that the visible complexity of the code is instead replaced by the invisible complexity of module interactions. This can be advantageous provided module interactions are extensively described in the design document, in that the complexity can be comprehended through a natural language as opposed to a programming language. Unfortunately, this may also mean that component interaction problems will have to be diagnosed through rigorous component testing.

I would tend to prefer the latter approach, as I'm something of an idealist and I would prefer to think that code complexity and defects may be kept to a minimum through an intelligent, modularized design. The former will allow for much more flexibility in terms of the design itself, does not require as well written of a design document, does not require the same degree of intelligence in those writing the design document and implementing the code framework, but in exchange will result in much more complicated but often more maintainable code. The former will virtually eliminate the possibility of buffer overflows, at the cost of deployment and use being impractical at best.

In a similar manner to Brooks' observation that there is "No Silver Bullet" for solving software engineering problems, there is no silver bullet for eliminating software defects that can lead to a security compromise. There are simply a number of steps which can be taken when developing a new program from scratch.

**cyn0n** · July 21, 2003, 15:03

of the more intelligent responses

Well, as I see it, most of the code analyzed in recent years have been obvious use of functions that do not utilize secure practices. So, I would have disagree with you that 'highly complex code' is responsible.

<quote>As the size of a codebase balloons, especially in the case of a C codebase, complexity and interdependancies of portions of code become increasingly more difficult to analyize. Most buffer overflows are not caused by "obvious" errors in the code, but arise from errors which crop up in highly complex code.</quote>

I believe that number buffer overflows and memory leaks are not inevitable in languages such as 'low-level' c because most programmers test their code before releasing it.
As for eliminiating complexity.....why? Who cares if the kid down the street can't code his way out of a paper sack? Let him learn--it will give him more motivation to improve upon the currently selected source.

<quote>I believe there are two schools of thought on this subject. The first is that buffer overflows (as well as other problems such as memory leaks) are inevitable in a language as low-level as C. The solution then becomes to eliminate the low-level aspects of the language and handle program execution in a "sandbox" environment which provides a considerable degree of run-time checking. Pointers and other low-level constructions are replaced by high level constructions, which should in theory eliminate some of the complexity by encapsulating some of the logic which would have appeared within the C code intermingled with other core parts of a program's functionality within the high level language constructions present in a particular language's standard library. This is the approach taken by a number of modern languages and runtimes, such as Java, C#/.NET, Perl, Python, Ruby, and many others.</quote>

This just leads to bad hackers. If you just want to get the job done and don't give a shit about the code go suck an egg because you are not true to the scene anyways.

<quote>The second is that complexity is an indicator of bad design. The solution is increased modularization and componentization of the code, with the aim of keeping all parts of the code as simple as possible without compromising necessary functionality. This approach is taken by programs like qmail, which also tries to fully leverage parts of the Unix environment in order to reduce complexity.</quote>

Fuck significant resources! The best programmers I've ever seen wrote under wrote under significantly lower resources than are avaialble today.

<quote>The disadvantage of the first approach is that it significantly increases the resource usage of a particular program, thus decreasing its performance and scalability. Furthermore, deploying a program designed for a particular runtime environment is typically more complex than deploying a program compiled to native code (which is only compounded by the fact that the runtime environment may need to be installed as a dependancy) For these reasons we have not seen widespread adoption of Java web servers, FTP servers, SMTP servers, etc.</quote>

Yes, testing...the basis of open-source/free-source programming. Goddamn! When are you people going to wake up and realize that the product is the future! Fuck fame and fuck money! Your approach is wrong. You must stive for the best and if that means hard work so be it. Don't give up for temporary fame.

<quote>The second approach has a terrible disadvantage in that the visible complexity of the code is instead replaced by the invisible complexity of module interactions. This can be advantageous provided module interactions are extensively described in the design document, in that the complexity can be comprehended through a natural language as opposed to a programming language. Unfortunately, this may also mean that component interaction problems will have to be diagnosed through rigorous component testing.</quote>

I would tend to prefer the latter approach, as I'm something of an idealist and I would prefer to think that code complexity and defects may be kept to a minimum through an intelligent, modularized design. The former will allow for much more flexibility in terms of the design itself, does not require as well written of a design document, does not require the same degree of intelligence in those writing the design document and implementing the code framework, but in exchange will result in much more complicated but often more maintainable code. The former will virtually eliminate the possibility of buffer overflows, at the cost of deployment and use being impractical at best.

<quote>I appreciate your concern and I agree with you but you can not argue that modularized design is the end-all be-all. There will always be better coders and hackers than you. You can not assert that you are the shit and no one will ever surpass you.</quote>

In a similar manner to Brooks' observation that there is "No Silver Bullet" for solving software engineering problems, there is no silver bullet for eliminating software defects that can lead to a security compromise. There are simply a number of steps which can be taken when developing a new program from scratch. [/B][/QUOTE]

I'm not saying there is. However, there are many alternatives than to overflowing a fucking buffer with invalid memory locations.
Also, this isn't my main arugment. My argument is that the hacker culture is dying and if we don't try to save it, it my fall into extinction. We can not allow this to happen. Please for the sake of your code and your future benefactors stay true to the hacker culture!

**blackwave** · July 21, 2003, 16:55

Re: scene degradation

Originally posted by cyn0n
I for one am going to make it my point this year to try to revive our culture and decrease the indolence, apathy and rid ourselves of this corporate disease and virus of heritage rape.

Greetings, we all know actions speak louder than words... what actions do you plan to take to make such an impact on the hacker community aka "the scene" as it were?

I am sure we could all start breakdancing and mentally masturbate until the cows came home... but what is the end result of your proverb?

Please enlighten us all.

**skroo** · July 21, 2003, 18:50

Re: scene degradation

Originally posted by cyn0n
Now, you have kids talking bout buffer overflow this and cross site scripting that while their only motive is to get some type of job working for the security industry, which I personally believe, imho, is the strongest enemy of the hacker community.

Hold on a minute, o mouthpiece for the masses. You're saying that anyone who works in the security industry is somehow the enemy of the community? Horseshit. I'd like to hear you explain exactly *why* you hold that point of view, and how you justify it - something you have woefully neglected to do here.

I for one am going to make it my point this year to try to revive our culture and decrease the indolence, apathy and rid ourselves of this corporate disease and virus of heritage rape.

Wow... That was like reading an issue of 2600, only without the articles on how to annoy the guy in the Wal-Mart garden supplies aisle.

**octalpus** · July 21, 2003, 19:17

Re: Re: scene degradation

Originally posted by skroo

Wow... That was like reading an issue of 2600, only without the articles on how to annoy the guy in the Wal-Mart garden supplies aisle.

And no NAMBLA ads...

**dataworm** · July 21, 2003, 21:57

Re: scene degradation

Originally posted by cyn0n
What happened to the groups that would protect the underground from people like the RIAA?

Check this out

If someone is pissed off all they do nowadays is deface a site or ddos it.

You seem to be talking about the kiddie...

Then, the 'true hackers' who are aspiring for jobs to the sec industry shun those guys. Why stop at defacing? Fuck those people over! Fry their fucking boxen and triple wipe their drives!

Do you realising most people here are working in IT Sec? Oh well, I'll have to find a job at Mc Donald...

Is anyone ready for the future? What does it have in store for the hacker culture? Yes, we are a culture--there is no way denying it. Are we going to allow less powerful governments and corporations to kill us or will we rise up and strengthen our holdings better than ever? Will we see the rise of guerilla networking grapple the internet or will we see an increase in limitations on crypto, anonymouity, and source?

What are you doing to get ready for the future? And who are those less powerful governement you are fearing about?

I for one am going to make it my point this year to try to revive our culture and decrease the indolence, apathy and rid ourselves of this corporate disease and virus of heritage rape.

What is your plan of action?

**ck3k** · July 21, 2003, 22:20

Re: Re: scene degradation

What is your plan of action?

To get a beer, and to stop reading long posts :D

**cyn0n** · July 21, 2003, 22:35

replies

greets-
In response to criticism:
"What do you suppose we do instead of work for security companies? Work at McDonalds?" Well, yes. I can't expand my entire philosophy here and it probably doesn't entirely fit the 'hacker ethic & culture' but I would strongly recommend not selling yourself for temprorary comfort. (eg: making money by working for the security industry)
As for those of you who have asked what I'm going to do to change the scene I don't think a single answer can accomodate everyone's question, but I do believe encouraging others to recognize their contribution to the decline of hacker culture and encouraging them to stand up for what is right should be the number one priority. This can mean anything from writing t-files to evangelizing drunkenly in hotel rooms but the main point is getting the information out that we are in a decline and need to get back to our original values.

As for those of you that never saw the hacker community as a culture or never felt the love of code--fuck you! You are one of the reasons of our decline.

**jesse** · July 21, 2003, 22:46

Re: replies

Originally posted by cyn0n
As for those of you that never saw the hacker community as a culture or never felt the love of code--fuck you! You are one of the reasons of our decline.

You mean we should HACK THE PLANET! HACK THE PLANET! BECAUSE THEY'RE TRASHING OUR RIGHTS?!

**jounin** · July 21, 2003, 22:55

Re: replies

Originally posted by cyn0n
"What do you suppose we do instead of work for security companies? Work at McDonalds?" Well, yes.

WooHoo! More money for me!!

As for those of you that never saw the hacker community as a culture or never felt the love of code...

When did Jerry MaGuire become a hacker?

I do believe encouraging others to recognize their contribution to the decline of hacker culture and encouraging them to stand up for what is right should be the number one priority.

Exactly who are you to be the authority on what the culture IS and what state of decline it is in?

**Grifter** · July 21, 2003, 23:03

Re: Re: Re: scene degradation

Originally posted by ck3k
To get a beer, and to stop reading long posts :D

Amen to that my brother.

Announcement

scene degradation

scene degradation

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment