Text 69502, 73 rader
Skriven 2012-12-02 12:14:57 av mark lewis (1:3634/12.42)
     Kommentar till en text av Ed Vance (10844.windowsa)
Ärende: perfect example of the wa
=================================
 EV> I just wish there was some technology that could be used to trace
 EV> where those sneaky buggars were just as they are releasing their
 EV> latest and greates problem for folks like me, 

there kinda is but it takes cooperation and work from many sources... basically
they can (and do) trace the originating points but it is not very straight
forward... one of the tools is what's known as a honeypot... honeypots are
networks that don't go anywhere... they are set up specifically for the
spammers and hackers to beat on while all the network traffic is captured for
analysis... in this way, some IP numbers are able to be seen as the origination
points...

 EV> and get them in the slammer. 

that's a whole other tale... for one thing, even though many use the term,
there is no such thing as "international law"... there is also no true
"international police force" or "international court" with which to handle the
offenders...in some areas, bulgaria for instance, things are not illegal as
they are in the US and other countries... so there has to be cooperation
between countries and enforcement systems...

 EV> But probably some computer technology company would probably just
 EV> hire them and put them to work makeing the good stuff since the
 EV> companies know those sneaky buggars have lots of knowledge about
 EV> how computers work.

they can do that after they serve their time and probation period... kevin
mitnik is a security analist these days IIRC... and it isn't really how
computers work but more how the software works... that meaning how memory is
allocated and what, if any, protections are in place to try to keep one task's
memory from being accessed by another task... in some cases, this is actually
desired and wanted but in others it is a definite nono...

the biggest problem is what i call "lazy coding" but that's not always the
coders' fault... many times it is the fault of the managers and marketing
rushing software to market before it has been fully tested and the flaws
fixed... there was a recent series of articles on theregister written by a
person who used to work with IBM back when IBM and microsoft were working on
OS/2 together... this person had made a notation about starting checkdisk from
the desktop twice at the same time... the second time being an error... the
problem was that checkdisk would run both times and each would be trying to fix
things and causing problems because they were both running... what should have
been done was each instance should check to see if another instance was already
running and if so, abort gracefully... however, this flaw wasn't fix and more
reports were filed about it each time a testing phase came around... this coder
got a visit from steve balmer (you know who he is, right?) one day and was
asked "what is your obsession with perfect code?"

sometimes the way to get flaws fixed is to blatently keep pointing them out and
evendually using them in ways that will definitely bring their consequences to
the forefront... in today's world, this is demonstrated by all the hacks out
there... virus', malware, trojans, etc... only now it is a lot harder to fix
the flaws because so much other code is built on those routines and some even
takes advantage of those flaws for normal operations... one example is simple
buffer overruns... each and every routine that uses a buffer should know how
big that buffer is and it should check that the data being shoved into the
buffer is not more than the buffer can handle... why was this buffer length
checking code left out? in many cases, they will say it is because of speed...
back then no one thought about buffer overruns but in today's world, the data
being shoved into the buffer can actually be code instructions and the buffer's
location in the task's memory allocation can be found... so they can determine
how much memory they can overwrite with their own code instructions and they
can know or cause the task to jump into their code instructions and start
executing it because now it is not in a data buffer but in the tasks code
instruction memory area... they simply used the buffer and an empty "sled" to
fill the buffer while carrying their stuff further past the buffer and
overwriting the actual task code... they substituted their code for the task's
operational code and now we have an infection taking place...

)\/(ark

--- 
 * Origin:  (1:3634/12.42)