[Eug-lug] Operating Systems.
Ben Barrett
stircrazyben at gmail.com
Tue Feb 20 11:46:46 PST 2007
I absolutly agree with you about what is being called "real time" being too
late (unless it is done on the
network, where interruption for allow/deny choices becomes more difficult).
General purpose OS's are not built for RTC needs, so I simply don't think
that these computing defintions
apply to what is sold as 'real-time scanning' solutions, as least the ones
that are PC-based.
It may be worthwhile to stick to these definitions, by which most such
'real-time' software FAILS due to
the deadline having been past. I would call the deadline for security
scanning, to be the time when infection
does (or may) take place. Most users think of this in terms of the firewall
software which stalls and pops up
a question, "Do you want to allow this? (once/always/never)". Which is
suitable for opening up most new
network connections... but maybe not for the umpteen JS scripts on a given
web page.
I enjoy the ranting, sorry it is wearing you down, and I hope it is not
bothersome to others. I think we're well
within the bounds and intentions of our group and its mailing list :) I
can't speak to the patience or infomation-
processing capabilities of the group's members though! ;)
I enjoyed some great [copylefted] videos from November's 23C3 tech-security
conference in Berlin,
where Vista was of course discussed, and they said that although they could
see (by comparing DLLs)
that many long-overdue patches had been applied, they also saw a slew of new
zero-day exploits waiting
to be enjoyed, abused, or otherwise plucked.... same old, same old, it
seems.
ciao,
ben
On 2/20/07, Michael Miller <mike.mikemiller at gmail.com> wrote:
>
> Ben,
>
> I agree with your points. This is my problem with the word real time
> scanning. In computing real time operations are defined as this.
>
> "In computer science, real-time computing (RTC) is the study of
> hardware and software systems which are subject to a "real-time
> constraint" =97ie. operational deadlines from event to system response.
> By contrast, a non-real-time system is one for which there is no
> deadline, even if fast response or high performance is desired or even
> preferred. The needs of real-time software are often addressed in the
> context of real-time operating systems, and synchronous programming
> languages, which provide frameworks on which to build real-time
> application software.
>
> A real time system may be one where its application can be considered
> (within context) to be mission critical. The anti-lock brakes on a car
> are a simple example of a real-time computing system =97 the real-time
> constraint in this system is the short time in which the brakes must
> be released to prevent the wheel from locking. Real-time computations
> can be said to have failed if they are not completed before their
> deadline, where their deadline is relative to an event. A real-time
> deadline must be met, regardless of system load.
> Contents"
>
> http://en.wikipedia.org/wiki/Real-time
>
> I know this is a little verbose.
>
> Real time scanning is after the fact. You have the virus or malware
> on your system so it's not really real time. Now if you IDS or IPS
> software on your network / computer this is all so not real time, It's
> after the fact. You may and can disagree with me on this point. I
> think best practice for virus scanning is to have the software
> installed. Then scanning may be what ever fits into your
> organisations polices.
>
> End users are going to browse what ever they want when they want to.
> The thing with end uses is they don't understand the technology. I
> think this is where the root of all problems is. If you don't do X,Y
> and Z you should have no problems at all. The same goes for if you
> have X,Y and Z programs installed and patches installed. The main
> problem is people don't do that and this is where the root of the
> botnet problems are. I'm not so confident that Microsoft in all there
> good intentions took the correct default security stance with Vista.
>
> http://blogs.zdnet.com/security/?p=3D29
>
> I only think they build a slightly better mouse trap. Maybe I'm wrong
> about this but I think time will write the final notes on this.
>
> -Miller
>
> P.S looking for a end too the ranting.
>
> On 2/20/07, Ben Barrett <stircrazyben at gmail.com> wrote:
> > Hmm, I have to say I'm not really much more scared about this than
> > as with any other web browsing. To the end-users I support, who are
> > just as likely to "accidentally" click on some bad email attachment or
> > "accidentally" surf into nether regions, there is little or no
> difference.
> > It *almost* appears as another attack vector, but not quite from what
> > I've seen. Now, if you start putting this crap in desktop widgets which
> > are sure to contain JS in some implementation, outside of a browser
> > entirely, then... well hum.
> >
> > I'm confused about why you say this is so important, and yet also state
> > that real time scanning is over-rated. It appears that real-time
> scanning,
> > is the best way to catch (or at least observe) these malicious
> behaviours.
> > And I notice all proofs-of-concept, and even early exploits, have say
> sql
> > injections in the clear, so it seems like you could easily scan for
> things
> > that look like sql in traffic, but with JS it is so easy to wrap/unwrap
> > data.
> >
> > Thanks for bringing this topic up -- future implications of AJAX, and
> > especially
> > the ways in which current trends are jut destroying some of the
> old-timey
> > web fundamentals, is just not discussed openly enough IMO.
> > If we started selling a car that drives on top of power lines, to avoid
> > traffic, then our audience could either be shocked or be busy building
> > elevated
> > parking spaces and new on-ramps. Sorry, I'm working on my
> pataphors! ;)
> >
> >
> > ben
> >
> >
> >
> > On 2/20/07, Michael Miller < mike.mikemiller at gmail.com> wrote:
> > > Ya your right Ben, I should have posted a example or two.
> > >
> > > http://blogs.securiteam.com/index.php/archives/734
> > > http://www.gnucitizen.org/blog/google-search-api-worms
> > >
> > > I know there is a lot of hype out there about this. Some of this is
> > > just theory and some of it is or will be fact when some one releases
> > > another banner ad worm.
> > >
> > > -Miller
> > >
> > > On 2/20/07, Ben Barrett < stircrazyben at gmail.com> wrote:
> > > > Are you asking if we know that AJAX can do things that we should
> > consider
> > > > scary?
> > > > (I think I agree... but...) How about giving a few examples of why
> we
> > > > should be
> > > > so scared? There are a LOT of folks who won't disable JS since it
> > "breaks
> > > > the web"
> > > > almost as much (in their opinion) and unplugging network cables!
> > > >
> > > > thanks,
> > > >
> > > > ben
> > > >
> > > >
> > > >
> > > > On 2/20/07, Michael Miller < mike.mikemiller at gmail.com> wrote:
> > > > > Real time scanning is over rated in my book. The only time you
> need
> > > > > to scan items real time is when your receiving e-mail. If you
> turn
> > > > > off Active X and java script ( If you can. ) You should be
> fine. It's
> > > > > really scary what we can do with AJAX and Java script in the web
> > > > > browser. I'm sure most of you if not all know this. If you can
> do
> > > > > some in line scanning with your web traffic that is even
> better. I
> > > > > thinking about setting up Squid to use ClamAV to scan the banner
> Ad's
> > > > > along with everything else looking for malware and or militias
> > > > > content.
> > > > >
> > > > > -Miller
> > > > >
> > > > > On 2/16/07, Elijah Buck < elijah.buck at gmail.com> wrote:
> > > > > > FYI,
> > > > > >
> > > > > > clamav doesn't have a real-time scanner (that is, it only scans
> when
> > you
> > > > > > schedule it to scan).
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 2/14/07, erock23175 at aol.com <erock23175 at aol.com> wrote:
> > > > > > >
> > > > > > >
> > > > > > > Just out of curiousity, how does AVG size up against Clam AV?
> > > > > > >
> > > > > > > -E
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > EUGLUG mailing list
> > > > > > euglug at euglug.org
> > > > > > http://www.euglug.org/mailman/listinfo/euglug
> > > > > >
> > > > > >
> > > > > _______________________________________________
> > > > > EUGLUG mailing list
> > > > > euglug at euglug.org
> > > > > http://www.euglug.org/mailman/listinfo/euglug
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > EUGLUG mailing list
> > > > euglug at euglug.org
> > > > http://www.euglug.org/mailman/listinfo/euglug
> > > >
> > > >
> > > _______________________________________________
> > > EUGLUG mailing list
> > > euglug at euglug.org
> > > http://www.euglug.org/mailman/listinfo/euglug
> > >
> >
> >
> > _______________________________________________
> > EUGLUG mailing list
> > euglug at euglug.org
> > http://www.euglug.org/mailman/listinfo/euglug
> >
> >
> _______________________________________________
> EUGLUG mailing list
> euglug at euglug.org
> http://www.euglug.org/mailman/listinfo/euglug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://euglug.org/pipermail/euglug/attachments/20070220/46a92c9b/attac=
hment.htm
More information about the EUGLUG
mailing list