On Fri, 2008-01-18 at 02:31 -0800, Alex Alten wrote:
> At 07:35 PM 1/18/2008 +1000, James A. Donald wrote:
> >
> >And all the criminals will of course obey the law.
> >
> >Why not just require them to set an evil flag on all
> >their packets?
>
> These are trite responses. Of course not. My poin
Alex Alten wrote:
[snip]
These are trite responses. Of course not. My point is
that if the criminals are lazy enough to use a standard
security protocol then they can't expect us not to put
something in place to decrypt that traffic at will if necessary.
[snip]
Look, the criminals have
Alex Alten wrote:
> Generally any standard encrypted protocols will
> probably eventually have to support some sort of CALEA
> capability. For example, using a Verisign ICA
> certificate to do MITM of SSL, or possibly requiring
> Ebay to provide some sort of legal access to Skype
> private keys.
I
At 07:35 PM 1/18/2008 +1000, James A. Donald wrote:
Alex Alten wrote:
> Generally any standard encrypted protocols will
> probably eventually have to support some sort of CALEA
> capability. For example, using a Verisign ICA
> certificate to do MITM of SSL, or possibly requiring
> Ebay to provide
Alex Alten wrote:
> Generally any standard encrypted protocols will
> probably eventually have to support some sort of CALEA
> capability. For example, using a Verisign ICA
> certificate to do MITM of SSL, or possibly requiring
> Ebay to provide some sort of legal access to Skype
> private keys.
From: Alex Alten <[EMAIL PROTECTED]>
Writing in support of CALEA capability to assist prosecuting botnet
operators etc ...
> Generally any standard encrypted protocols will probably eventually have
> to support some sort of CALEA capability.
So you havn't heard that the UK has closed down the "
On Jan 12, 2008 9:32 AM, Alex Alten <[EMAIL PROTECTED]> wrote:
> Generally any standard encrypted protocols will probably eventually have
> to support some sort of CALEA capability. ...
That's a rather large and distinctly dangerous assumption. Here's the
IETF's official line on the question, the
On Fri, 11 Jan 2008 17:32:04 -0800
Alex Alten <[EMAIL PROTECTED]> wrote:
>
> Generally any standard encrypted protocols will probably eventually
> have to support some sort of CALEA capability. For example, using a
> Verisign ICA certificate to do MITM of SSL, or possibly requiring
> Ebay to pro
Sorry for the long delay in responding, I was traveling out of
"radio range" this week.
At 06:23 PM 1/4/2008 -0500, Leichter, Jerry wrote:
| > | ...Also, I hate to say this, we may need to also require that all
| > | encrypted traffic allow inspection of their contents under proper
| > | authori
On Mon, Jan 07, 2008 at 10:35:00AM -0500, [EMAIL PROTECTED] wrote:
|
| Jerry,
|
| It is always possible that I misunderstand the McCabe
| score which may come from the fact that so many build
| environments compute it along with producing the binary,
| i.e., independent of human eyeballs. If com
| Jerry,
|
| It is always possible that I misunderstand the McCabe
| score which may come from the fact that so many build
| environments compute it along with producing the binary,
| i.e., independent of human eyeballs. If complexity
| scoring requires human eyeballs or the presence of the
| des
Jerry,
It is always possible that I misunderstand the McCabe
score which may come from the fact that so many build
environments compute it along with producing the binary,
i.e., independent of human eyeballs. If complexity
scoring requires human eyeballs or the presence of the
designer's flow ch
| ...Taking as our metric the venerable McCabe score:
|
|v(G) = e - n + 2
|
| where e and n are the number of edges and nodes in the
| control flow graph, and where you are in trouble when
| v(G)>10 in a single module, the simplest patch adds two
| edges and one node, i.e., v'(G)=v(G)+1, and
On Jan 5, 2008, at 3:47 AM, Alexander Klimov wrote:
It sounds like: we cannot make secure OS because it is too large --
let us don't bother to make a smaller secure OS, just add some more
software and hardware to an existent system and then it will be
secure. Sounds like a fairytale
I don't thi
Alexander Klimov writes, in part:
-+---
| It sounds like: we cannot make secure OS because it is too
| large -- let us don't bother to make a smaller secure OS,
| just add some more software and hardware to an existent
| system and then it will be secure. Sounds lik
Leichter, Jerry
> > Why not just require that the senders of malign
> > packets set the Evil Bit in their IP headers?
> >
> > How can you possibly require that encrypted traffic
> > *generated by the attackers* will allow itself to be
> > inspected?
Alex Alten wrote:
> You misunderstand me. We c
On Fri, 4 Jan 2008, Alex Alten wrote:
> I think that we will have to move toward encrypting more data at
> rest in some manner that is that is easy for the user to use (like
> ATM cash cards) yet difficult for a malicious piece of software on
> the user's machine to circumvent. This will require t
| > | ...Also, I hate to say this, we may need to also require that all
| > | encrypted traffic allow inspection of their contents under proper
| > | authority (CALEA essentially)
| > Why not just require that the senders of malign packets set the Evil Bit
| > in their IP headers?
| >
| > How
At 05:47 PM 1/4/2008 -0500, Leichter, Jerry wrote:
| ...Also, I hate to say this, we may need to also require that all
| encrypted traffic allow inspection of their contents under proper
| authority (CALEA essentially)
Why not just require that the senders of malign packets set the Evil Bit
i
| ...Also, I hate to say this, we may need to also require that all
| encrypted traffic allow inspection of their contents under proper
| authority (CALEA essentially)
Why not just require that the senders of malign packets set the Evil Bit
in their IP headers?
How can you possibly require tha
At 11:23 PM 1/3/2008 +, Steven M. Bellovin wrote:
On Thu, 03 Jan 2008 11:52:21 -0500
[EMAIL PROTECTED] wrote:
> The aspect of this that is directly relevant to this
> list is that while "we" have labored to make network
> comms safe in an unsafe transmission medium, the
> world has now reach
> Crypto solves certain problems very well. Against others, it's worse
> than useless -- "worse", because it blocks out friendly IDSs as well as
> hostile parties.
>
>
Yawn. IDS is dead, has been for a while now. The bottom line discovery
has been that:
1) Anomaly detection doesn't work bec
| >The claim that VMM's provide high level security is trading on the
| >reputation of work done (and published) years ago which has little if
| >anything to do with the software actually being run.
|
| Actually VMMs do provide some security, but not in the way you think.
| Since malware researche
[EMAIL PROTECTED] writes:
>Second, as soon as one of these guys figures out how to hook the memory
>manager (which may already have happened),
It's been done for awhile by various rootkits. The first AFAIK was
ShadowWalker, which marked pages to be hidden as non-present and used a custom
page fa
Perry E. Metzger wrote:
> I think Steve is completely correct in the case of
> cryptography. We have a lot of experience of real
> world security failures these days, and they're not
> generally the sort that crypto would fix.
They are the sort that a different sort of way of using
crypto could f
"Leichter, Jerry" <[EMAIL PROTECTED]> writes:
>The claim that VMM's provide high level security is trading on the reputation
>of work done (and published) years ago which has little if anything to do with
>the software actually being run.
Actually VMMs do provide some security, but not in the way
On Thu, 03 Jan 2008 11:52:21 -0500
[EMAIL PROTECTED] wrote:
> The aspect of this that is directly relevant to this
> list is that while "we" have labored to make network
> comms safe in an unsafe transmission medium, the
> world has now reached the point where the odds favor
> the hypothesis that
Jason <[EMAIL PROTECTED]> writes:
> On Wed, 2 Jan 2008, Steven M. Bellovin wrote:
>> Cryptography provides authentication and integrity. It does not
>> provide authorization, nor does it provide protection against bugs.
>> Your suggested approach -- better OS and better crypto -- is exactly
>> wh
[EMAIL PROTECTED] (Ivan Krsti) on Thursday, January 3, 2008 wrote:
>On Dec 31, 2007, at 4:46 PM, Bill Frantz wrote:
>> My favorite virtual machine use is for the virus to install itself
>> as a virtual machine, and run the OS in the virtual machine. This
>> technique should be really good for hid
> however, another interpretation is that the defenders
> have chosen extremely poor position to defend ... and are
> therefor at enormous disadvantage. it may be necessary
> to change the paradigm (and/or find the high ground)
> in order to successfully defend.
First, it is evident that th
Leichter, Jerry wrote:
Virtualization has become the magic pixie dust of the decade.
When IBM originally developed VMM technology, security was not a primary
goal. People expected the OS to provide security, and at the time it
was believed that OS's would be able to solve the security problems.
With this discussion of virtualization and security, it might be a
good time to note:
IEEE Security & Privacy
Special issue on virtualization
September/October 2008
Deadline for submissions: 6 February 2008
Visit www.computer.org/portal/pages/security/author.xml to submit a
manuscript
On Dec 31, 2007, at 4:46 PM, Bill Frantz wrote:
My favorite virtual machine use is for the virus to install itself
as a virtual machine, and run the OS in the virtual machine. This
technique should be really good for hiding from virus scanners.
It's not, and despite the press handwaving about
[EMAIL PROTECTED] (Jason) on Wednesday, January 2, 2008 wrote:
>On the other hand, writing an OS that doesn't get infected in the first place
>is a fundamentally winning battle: OSes are insecure because people make
>mistakes, not because they're fundamentally insecurable.
I fully agree that a
On Wed, 2 Jan 2008, Steven M. Bellovin wrote:
Cryptography provides authentication and integrity. It does not
provide authorization, nor does it provide protection against bugs.
Your suggested approach -- better OS and better crypto -- is exactly
what's failed for the last 25 years.
You're pa
> Detecting viruses is a fundamentally losing battle: a
> sufficiently advanced virus can fully simulate a clean
> computer for the scanner to run in.
>
> On the other hand, writing an OS that doesn't get
> infected in the first place is a fundamentally winning
> battle: OSes are insecure because
On Wed, 2 Jan 2008 21:26:47 + (UTC)
Jason <[EMAIL PROTECTED]> wrote:
> On the other hand, writing an OS that doesn't get infected in the
> first place is a fundamentally winning battle: OSes are insecure
> because people make mistakes, not because they're fundamentally
> insecurable.
>
~~20
Today's VMMs aren't even designed to fit the formal criteria for a VMM
(at least as expressed, intelligently, by Popek and Goldberg back in the
70s). VMM-aware malware leverages this: for example, by making calls to
VMware's "backdoor" communications channel from the guest (ie. jerry.c).
If the "e
| One virtualization approach that I have not see mentioned on this
| thread is to run the virtual machine on a more secure OS than is used
| by the applications of interest.
|
| For example, one could run VMware on SELinux and use VMware to host
| Windows/Vista. Thus, even if a virus subverts Wi
Re: Death of antivirus software imminent
Virtualization has become the magic pixie dust of the decade.
When IBM originally developed VMM technology, security was not a primary
goal. People expected the OS to provide security, and at the time it
was believed that OS's would be able to solv
Virtualization has become the magic pixie dust of the decade.
When IBM originally developed VMM technology, security was not a primary
goal. People expected the OS to provide security, and at the time it
was believed that OS's would be able to solve the security problems.
As far as I know, the f
On Wed, 2 Jan 2008, Anne & Lynn Wheeler wrote:
however, another interpretation is that the defenders
have chosen extremely poor position to defend ... and are
therefor at enormous disadvantage. it may be necessary
to change the paradigm (and/or find the high ground)
in order to successfully defe
ine, and run the OS in the virtual machine. This
> technique should be really good for hiding from virus scanners.
re:
http://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus
software imminent
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus
software imminent
i commente
software
imminent
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software
imminent
i commented on that in reference posts mentioning that there have been
uses of virtual machines to study virus/trojans ... but that
some of the new generation virus/trojans are now looking to see if
On Dec 29, 2007, at 6:37 PM, Anne & Lynn Wheeler wrote:
> Virtualization still hot, death of antivirus software imminent
My favorite virtual machine use is for the virus to install itself
as a virtual machine, and run the OS in the virtual machine. This
technique should be really good for
On Dec 29, 2007, at 6:37 PM, Anne & Lynn Wheeler wrote:
Virtualization still hot, death of antivirus software imminent
My, that sounds awfully familiar:
<http://radian.org/~krstic/talks/2007/auscert/slides.pdf>
I note that, come the January OLPC software update, I will be using my
Anne & Lynn Wheeler wrote:
> Virtualization still hot, death of antivirus software imminent, VC says
> http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html
Interesting how "virtualization" seems to imply "safe" in the public
mind (and explici
Virtualization still hot, death of antivirus software imminent, VC says
http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html
from above:
Another trend Maeder predicts for 2008 is, at long last, the death of
antivirus software and other security products that allow employees to
48 matches
Mail list logo