From Ken at krvw.com  Fri Jan  6 13:05:00 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Fri, 6 Jan 2006 13:05:00 -0500
Subject: [SC-L] IEEE Spectrum: The Exterminators
Message-ID: <200601061305.00634@KRvW>

I saw an interesting IEEE Spectrum article today about the software security 
work being done by Peter Amey and the folks over at Praxis.  Full text can be 
found at:

http://www.spectrum.ieee.org/sep05/1454

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com


From ken at krvw.com  Mon Jan  9 22:06:59 2006
From: ken at krvw.com (Kenneth R. van Wyk)
Date: Mon, 9 Jan 2006 22:06:59 -0500 (EST)
Subject: [SC-L] ZDNet: Microsoft to hunt for new species of Windows bug
Message-ID: <2238.208.54.14.65.1136862419.squirrel@mail.krvw.com>

Following the recent Microsoft WMF flaw, there's an article in ZDNet talking about how
Microsoft is now going to "scour its code to look for flaws similar to a recent serious
Windows bug and to update its development practices to prevent similar problems in future
products."  The full text of the article can be found at:
http://news.zdnet.com/2100-1009_22-6024778.html

Cheers,

Ken
-- 
KRvW Associates, LLC
http://www.KRvW.com




From bellovin at acm.org  Mon Jan  9 23:35:25 2006
From: bellovin at acm.org (Steven M. Bellovin)
Date: Mon, 09 Jan 2006 23:35:25 -0500
Subject: [SC-L] ZDNet: Microsoft to hunt for new species of Windows bug 
Message-ID: <20060110043525.7728A3C01C9@berkshire.machshav.com>

In message <2238.208.54.14.65.1136862419.squirrel at mail.krvw.com>, "Kenneth R. v
an Wyk" writes:
>Following the recent Microsoft WMF flaw, there's an article in ZDNet talking a
>bout how
>Microsoft is now going to "scour its code to look for flaws similar to a recen
>t serious
>Windows bug and to update its development practices to prevent similar problem
>s in future
>products."  The full text of the article can be found at:
>http://news.zdnet.com/2100-1009_22-6024778.html
>

I like this line: "This kind of threat has not been anticipated before",
from Microsoft.  Mobile code hasn't been anticipated?  C'mon!

		--Steve Bellovin, http://www.stevebellovin.com




From dwjackson at bcbsal.org  Tue Jan 10 12:49:26 2006
From: dwjackson at bcbsal.org (Don Jackson)
Date: Tue, 10 Jan 2006 11:49:26 -0600
Subject: [SC-L] ZDNet: Microsoft to hunt for new species of Windows
 bug
In-Reply-To: <2238.208.54.14.65.1136862419.squirrel@mail.krvw.com>
References: <2238.208.54.14.65.1136862419.squirrel@mail.krvw.com>
Message-ID: <200601101745.k0AHjq5S076567@ratsass.krvw.com>

>>>> "Kenneth R. van Wyk" <ken at krvw.com> 1/9/2006 9:06:59 pm >>>
>Following the recent Microsoft WMF flaw, there's an article in ZDNet
talking about how
>Microsoft is now going to "scour its code to look for flaws similar to
a recent serious
>Windows bug and to update its development practices to prevent similar
problems in future
>products."  The full text of the article can be found at:
>http://news.zdnet.com/2100-1009_22-6024778.html 

If Microsoft won't do it, others will.  Multiple buffer overflow
vulnerabilities have reportedly been found in patched WMF handlers.

Here we go again... Teportedly, these affect many systems, even those
with the recent MS06-001 WMF patch installed.  I've included the
original message from the security researcher.  A little checking
appears to confirm that it's legit.

  DJ

-----Original Message-----
From: frankruder at hotmail.com [mailto:frankruder at hotmail.com] 
Sent: Saturday, January 07, 2006 2:08 AM
To: bugtraq at securityfocus.com 
Subject: Microsoft Windows GRE WMF Format Multiple Memory
OverrunVulnerabilities

Microsoft Windows GRE WMF Format Multiple Memory Overrun
Vulnerabilities

by cocoruder
page:http://ruder.cdut.net
email:frankruder_at_hotmail.com

Last Update:2006.01.07
class:design error
Remote:yes
local:yes

Product Affected:
Microsoft Windows XP SP2
Microsoft Windows XP SP1
Microsoft Windows Server 2003 SP1
Microsoft Windows Server 2003
Microsoft Windows ME
Microsoft Windows 98se
Microsoft Windows 98
Microsoft Windows 2000SP4

Vendor:
www.microsoft.com 

Overview:
Microsoft Windows GRE(Graphics Rendering Engine) has been discovered
multiple memory overrun vulnerabilities while rendering WMF format
file.Users who view the malicious WMF format file will bring a denial
of
service attack(explorer.exe will be restart).

Details:
there is 2 memory overrun vulnerabilities at least.

1.ExtCreateRegion call result in memory overrun vulnerability HRGN
ExtCreateRegion(
  CONST XFORM *lpXform,     // transformation data
  DWORD nCount,             // size of region data
  CONST RGNDATA *lpRgnData  // region data buffer );

WMFRECORD structure:
typedef struct _StandardMetaRecord
{
    DWORD Size;          /* Total size of the record in WORDs */
    WORD  Function;      /* Function number (defined in WINDOWS.H) */
    WORD  Parameters[];  /* Parameter values passed to function */ }
WMFRECORD;

the Parameters is likely about:
typedef	struct 	_Parameters
{
	char	unknow1[0x0a];
	WORD	All_PointtStruct_Num;	//the total following "
PointtStruct" number
	char	unknow2[0x0a];
	char	PointtStruct[];		//first  "PointtStruct"
}Parameters;

"PointtStruct"  structure:
typedef	struct 	_PointtStruct
{
	WORD	PointNum;		//
	WORD	Point[PointNum];	//
	char	unkonow[6];
}PointtStruct;

if we set 0xff to WMFRECORD.Function,PlayMetaFileRecord will compute
the
memory which will be allocate later,as following:

..text:7F00FE07 loc_7F00FE07:                           ; CODE XREF:
PlayMetaFileRecord+1256j
..text:7F00FE07                 sub     eax, 3
..text:7F00FE0A                 jnz     loc_7F022B9A    ; 0xff
..text:7F00FE10                 movzx   ecx, word ptr
[ebx+10h]	;get
total "PointtStruct" number
..text:7F00FE14                 mov     [ebp-88h], ecx		;save
..text:7F00FE1A                 test    ecx, ecx
..text:7F00FE1C                 jnz     short loc_7F00FE2E	;jmp 
..text:7F00FE1E                 xor     eax, eax
..text:7F00FE20                 push    eax             ; int
..text:7F00FE21                 push    eax             ; int
..text:7F00FE22                 push    eax             ; int
..text:7F00FE23                 push    eax             ; int
..text:7F00FE24                 call    CreateRectRgn
..text:7F00FE29                 jmp     loc_7F010494
..text:7F00FE2E ;
&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;
&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;
&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;
&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;&#21738;
&#21738;?
..text:7F00FE2E
..text:7F00FE2E loc_7F00FE2E:                           ; CODE XREF:
PlayMetaFileRecord+C15j
..text:7F00FE2E                 xor     edi, edi
..text:7F00FE30                 mov     [ebp-8Ch], edi
..text:7F00FE36                 lea     eax, [ebx+1Ch]		;get
first "PointtStruct" address
..text:7F00FE39                 mov     [ebp-90h], eax		;save
..text:7F00FE3F                 and     [ebp-94h],
edi			
..text:7F00FE45                 and     [ebp-98h], edi
..text:7F00FE4B                 test    ecx, ecx
..text:7F00FE4D                 jbe     short
loc_7F00FE8C		
..text:7F00FE4F
..text:7F00FE4F loc_7F00FE4F:                           ; CODE XREF:
PlayMetaFileRecord+C83j
..text:7F00FE4F                 movzx   ecx, word ptr [eax]	;get
PointNum,here will trigger memory access error**
..text:7F00FE52                 mov     edx,
ecx				
..text:7F00FE54                 shr     edx, 1
;PointNum/2
..text:7F00FE56                 add     edx,
edi			;sum
PointNum/2
..text:7F00FE58                 cmp     edx, edi
..text:7F00FE5A                 jb      loc_7F0106D5
..text:7F00FE60                 mov     edi, edx
..text:7F00FE62                 mov     [ebp-8Ch], edi
..text:7F00FE68                 cmp     ecx, 7FFFFFFBh
..text:7F00FE6E                 jnb     loc_7F0106D5
..text:7F00FE74                 lea     eax, [eax+ecx*2+8]
..text:7F00FE78                 inc     dword ptr [ebp-98h]
;counter+1
..text:7F00FE7E                 mov     ecx, [ebp-98h]
..text:7F00FE84                 cmp     ecx, [ebp-88h]		;cmp
total "PointtStruct" number
..text:7F00FE8A                 jb      short loc_7F00FE4F
;traverse all "PointtStruct"
..text:7F00FE8C
..text:7F00FE8C loc_7F00FE8C:                          
		; CODE
XREF: PlayMetaFileRecord+C46j
..text:7F00FE8C                                        
		;
PlayMetaFileRecord+14D8j
..text:7F00FE8C                 cmp     dword ptr [ebp-94h], 0
..text:7F00FE93                 jnz     loc_7F022BA2
..text:7F00FE99                 cmp     edi, 0FFFFFFDh
..text:7F00FE9F                 jnb     loc_7F022BA2
..text:7F00FEA5                 mov     eax, [ebp-8Ch]
..text:7F00FEAB                 add     eax, 2
..text:7F00FEAE                 shl     eax, 4
..text:7F00FEB1                 mov     [ebp-9Ch], eax
..text:7F00FEB7                 push    eax             ; uBytes
..text:7F00FEB8                 push    0               ; uFlags
..text:7F00FEBA                 call    ds:LocalAlloc		;will
allocate memory normally.
..text:7F00FEC0                 mov     edi, eax

so when we set
"Parameters.All_PointtStruct_Num","PointtStruct.PointNum"
big enough,but not many enough "PointtStruct" structure,will trigger a
memory access error on 7F00FE4F.


2.ExtEscape POSTSCRIPT_INJECTION result in memory overrun
vulnerability
int ExtEscape(
  hdc,                  // handle to DC (HDC)
  POSTSCRIPT_INJECTION, // nEscape param of ExtEscape
  cbInput,              // size of input buffer
  lpszInData,           // pointer to input (PSINJECTDATA *)
  0,                    // cbOutput param of ExtEscape
  NULL                  // lpszOutData param of ExtEscape
);

we can control cbInput and szInData,so when we set cbInput big
enough(like 0xffff),but set szInData very small,will trigger a memory
access error(7F027358) likely.

..text:7F027312 loc_7F027312:                           ; CODE XREF:
ExtEscape+11Ej
..text:7F027312                                         ;
ExtEscape+12Aj
..text:7F027312                 test    byte ptr [ecx+4], 40h
..text:7F027316                 jnz     loc_7F017CEC
..text:7F02731C                 mov     ebx,
[ebp+arg_8]		;we can
cotrol this:cbSize
..text:7F02731F                 add     ebx, 1Ah
;cbSize+0x1a
..text:7F027322                 and     ebx, 0FFFFFFFCh
;cbSize+0x1a-4
..text:7F027325                 mov     eax, large fs:18h
..text:7F02732B                 mov     eax, [eax+30h]
..text:7F02732E                 push    ebx
..text:7F02732F                 push    0
..text:7F027331                 push    dword ptr [eax+18h]
..text:7F027334                 call    ds:RtlAllocateHeap
;allocate memory size=cbSize+0x16
..text:7F02733A                 test    eax, eax
..text:7F02733C                 jz      short loc_7F027385
..text:7F02733E                 mov     ecx, [ebp+arg_4]
..text:7F027341                 mov     [eax+0Ch], ecx
..text:7F027344                 mov     ecx, [ebp+arg_8]
..text:7F027347                 mov     [eax+10h], ecx
..text:7F02734A                 mov     edx, ecx
..text:7F02734C                 shr     ecx, 2
..text:7F02734F                 sub     ebx, 8
..text:7F027352                 mov     [eax+8], ebx
..text:7F027355                 lea     edi, [eax+14h]
..text:7F027358                 rep movsd
;copy,here will trigger a memory error likely**
..text:7F02735A                 mov     ecx, edx
..text:7F02735C                 and     ecx, 3
..text:7F02735F                 rep movsb
..text:7F027361                 mov     ecx, [ebp-4]
..text:7F027364                 mov     edi, [ebp+arg_14]
..text:7F027367                 lea     edx, [ecx+48h]
..text:7F02736A                 mov     esi, [edx+4]
..text:7F02736D                 mov     [eax+4], esi

Exploit:
first vul can test like this:
 
....05020000FF0044444444444444444444FFFF33333333333333333333FFFF41424344.
...
second vul can test like this:
  ...0502000026001610FFFF4444444444444444...
my blog can not be opened now:p,i will upload the exploit files to
xfocus(www.xfocus.net) later,have fun:)

Solution:
Microsoft has not develop the patch,please unregister the Windows
Picture and Fax Viewer (Shimgvw.dll)(see MS06-001).

Thanks:
thanks all my friends,Happy Weekday:)

-EOF-


*** *** *** *** *** *** *** *** *** ***
  CONFIDENTIALITY NOTICE  
This e-mail is intended for the sole use of the individual(s) to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law.  You are hereby notified that any dissemination, duplication, or distribution of this transmission by someone other than the intended addressee or its designated agent is strictly prohibited.  If you receive this e-mail in error, please notify me immediately by replying to this e-mail.
*** *** *** *** *** *** *** *** *** ***


From ge at linuxbox.org  Tue Jan 10 16:40:14 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Tue, 10 Jan 2006 23:40:14 +0200
Subject: [SC-L] ZDNet: Microsoft to hunt for new species of Windows bug
In-Reply-To: <20060110043525.7728A3C01C9@berkshire.machshav.com>
References: <20060110043525.7728A3C01C9@berkshire.machshav.com>
Message-ID: <43C429BE.2070601@linuxbox.org>

Steven M. Bellovin wrote:
> I like this line: "This kind of threat has not been anticipated before",
> from Microsoft.  Mobile code hasn't been anticipated?  C'mon!

I think they meant 'features that allow you to execute code have not 
been seen as a security issue before. We have no idea where and how many 
such instances there are.'

Reminds you of anything? ;)

	Gadi.


From ken at krvw.com  Wed Jan 11 10:45:12 2006
From: ken at krvw.com (Kenneth R. van Wyk)
Date: Wed, 11 Jan 2006 10:45:12 -0500 (EST)
Subject: [SC-L] DHS funding open source security scanning
Message-ID: <4287.12.46.199.242.1136994312.squirrel@mail.krvw.com>

FYI, interesting article out on ZDNet (full text at
http://news.zdnet.com/2100-1009_22-6025579.html) announcing the U.S. Dept. of Homeland
Security funding of a joint Stanford/Symantec/Coverity project over three years.  The
project aims to provide periodic scans of popular open source software using Coverity's
commercial scanner and Symantec's security intelligence service.

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com




From Ken at krvw.com  Tue Jan 17 10:52:57 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Tue, 17 Jan 2006 10:52:57 -0500
Subject: [SC-L] Any interest in an informal SC-L BoF at S3?
Message-ID: <200601171052.57561@KRvW>

Hi folks,

I'm not sure if there's enough critical mass here AND going to S3 
(http://www.s3-con.com), but it's worth a shot...

If anyone is interested in an informal SC-L gathering for drinks and/or dinner 
at the Software Security Symposium in La Jolla, California next month, I'd be 
happy to volunteer to organize one.  It'll be a self-pay thing, so please 
bring some cash so that we can divide the bill easily.

When/where:

Tuesday, 7 Feb 2006
6-8 PM (UTC -0700)
Rock Bottom Brewery
8980 Villa La Jolla Drive
La Jolla, CA 92037

The Rock Bottom is just a stone's throw down the road from the conference 
hotel.  It's across the highway interchange, so it might be a bit of a 
challenging walk, but it's a very short drive.

No sales droids, please.  Just an informal chat about software security (or 
other topics of interest) for anyone interested in joining in.

If you want to attend, please let me know.  Once I have sufficient attendees 
(say 4 or more people), I'll confirm the arrangements with them directly.  
Otherwise, I'll just cancel and hope that we get enough people at the next 
event.

Hope to see a few SC-Lers there!

Cheers,

Ken van Wyk
--
KRvW Associates, LLC
http://www.KRvW.com


From Ken at krvw.com  Tue Jan 17 10:58:19 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Tue, 17 Jan 2006 10:58:19 -0500
Subject: [SC-L] (fwd) Secure Java apps on Linux using MD5 crypt
Message-ID: <200601171058.20340@KRvW>

The title ("Secure Java apps on Linux using MD5 crypt") is a bit misleading, 
since the article is really about using a native Java MD5 module for 
authenticating Linux apps, but it's still worth a look-see for any Java/Linux 
folks, FYI:

http://www-128.ibm.com/developerworks/linux/library/l-md5crypt/?ca=dgr-lnxwLinuxCrypt

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com


From Ken at KRvW.com  Thu Jan 19 17:02:35 2006
From: Ken at KRvW.com (Kenneth R. van Wyk)
Date: Thu, 19 Jan 2006 17:02:35 -0500
Subject: [SC-L] Any interest in an informal SC-L BoF at S3?
In-Reply-To: <200601171052.57561@KRvW>
References: <200601171052.57561@KRvW>
Message-ID: <43D00C7B.4070704@KRvW.com>

Kenneth R. van Wyk wrote:

> I'm not sure if there's enough critical mass here AND going to S3 
> (http://www.s3-con.com), but it's worth a shot...
>
Oops, it was pointed out to me that my citation above is incorrect, 
sorry.  The correct URL for the Software Security Symposium is in fact 
http://www.s-3con.com   Sorry for any confusion, and I hope to see some 
SC-L folks out in sunny La Jolla.  Please stop by and say hello if 
you're there, even if you can't attend our BoF.

Cheers,

Ken van Wyk



From ge at linuxbox.org  Thu Jan 19 15:53:01 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Thu, 19 Jan 2006 22:53:01 +0200
Subject: [SC-L] heap protection in glibc - some questions
Message-ID: <43CFFC2D.2030306@linuxbox.org>

A friend of mine grabbed my attention to this today. I sent this to 
another list earlier and decided it may be more fitting here on Ken's list.

In version 2.3.4 of glibc...

if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0) ||
__builtin_expect ((uintptr_t) p & MALLOC_ALIGN_MASK, 0))

^^^ This line was added.

There is also a comment on it:

+  /* Little security check which won't hurt performance: the
+     allocator never wrapps around at the end of the address space.
+     Therefore we can exclude some size values which might appear
+     here by accident or by "design" from some intruder.  */
+  if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0)
+      || __builtin_expect ((uintptr_t) p & MALLOC_ALIGN_MASK, 0))
+    {
+      errstr = "free(): invalid pointer";
+    errout:
+      malloc_printerr (check_action, errstr, mem);
+      return;
+    }

It was mentioned on http://www.securityfocus.com/columnists/359.

Now, my questions if some of you can be so kind as to try and answer:
In your estimation, how many people actually heard about this (outside
the tight circle of secure coding maniacs)?

In your estimation, how many people actually go through the pain of
upgrading glibc?

This seems effective to me. In retrospect, how effective did it prove to
be over the past year, in your experience? Is it too early to tell?

Heard of this? http://www.cs.ucsb.edu/~wkr/projects/heap_protection/
What's your take on it, and how do you compare the two?

I'd appreciate your input if you have the time.

A friend of mine might also write on this, but I would like some more
opinions.

Thanks guys!

	Gadi.



From gem at cigital.com  Thu Jan 19 17:41:48 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 19 Jan 2006 17:41:48 -0500
Subject: [SC-L] Any interest in an informal SC-L BoF at S3?
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F134E@va-mail.cigital.com>

hi all,

http://www.s-3con.com 

I'll be there (as you can tell by that mugshot on the website).  I hope
that a bunch of you sc-l people are planning to go.  We need to get
ourselves a decent conference, and this may just be the way to do it.  

gem



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From yyounan at fort-knox.org  Sun Jan 22 04:11:18 2006
From: yyounan at fort-knox.org (Yves Younan)
Date: Sun, 22 Jan 2006 10:11:18 +0100
Subject: [SC-L] heap protection in glibc - some questions
In-Reply-To: <43CFFC2D.2030306@linuxbox.org>
References: <43CFFC2D.2030306@linuxbox.org>
Message-ID: <D4CABDC7-7825-4BC5-9975-17B89B4CF7BB@fort-knox.org>

On 19 Jan 2006, at 21:53, Gadi Evron wrote:

> A friend of mine grabbed my attention to this today. I sent this to  
> another list earlier and decided it may be more fitting here on  
> Ken's list.
>
> In version 2.3.4 of glibc...
>
Actually glibc2.3.4 was the first to get these checks, but glibc  
2.3.5 has a lot more checks. The nice part about these checks is that  
they are very cheap.

> This seems effective to me. In retrospect, how effective did it  
> prove to
> be over the past year, in your experience? Is it too early to tell?
Phantasmal Phantasmagoria has released a paper detailing how to  
bypass these checks (in 2.3.5):
http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/ 
2005-10/0127.html

> Heard of this? http://www.cs.ucsb.edu/~wkr/projects/heap_protection/
> What's your take on it, and how do you compare the two?
I've looked at both, they are both interesting techniques, the  
robertson protection however relies on a global secret number. If an  
attacker is able to discover what the value is, he could bypass the  
protection. If he could print out the management information for any  
chunk, he could calculate the checksum value for that chunk and xor  
it with the magic for that chunk and then retrieve the global random  
value. He could then use this global random value to calculate a  
correct magic value for a different chunk (one that he can overwrite).

We've also released a paper in which we describe a new technique to  
protect the memory management information from heap-based buffer  
overflows.
It does not suffer from the randomness problem. The paper is at  
http://fort-knox.org/CW419.pdf. The implementation of our allocator  
(based on Doug Lea's memory allocator) is available from:
http://fort-knox.org/dnmalloc-1.0.beta4.tar.gz. I'll be releasing  
beta5 at the beginning of february though.
The main idea is to store the management information in a different  
part of memory and then ensuring that there's a mapping from one to  
another, this means that the management information is safe from  
attack. However as with both the other protection techniques, it does  
not protect the contents of the chunks, but only the management  
information. What's also nice about our solution is that it could be  
combined with the secret number technique by storing a secret number  
at the top of the chunk and mirror that secret number in the  
management information, this would allow for a per-chunk random  
number. The random number could then be used to detect an attack, but  
the security of the allocator would not rely on this number remaining  
secret, it would be in addition. I'll be adding this to beta6 some  
time during february.

Any comments you may have on our proposed countermeasure are, of  
course, very welcome.

- YY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20060122/8a804455/attachment.bin 

From jeff.williams at aspectsecurity.com  Wed Jan 25 17:18:25 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Wed, 25 Jan 2006 17:18:25 -0500
Subject: [SC-L] PHP and insecurity
Message-ID: <003f01c621fd$42f17240$9604a8c0@intranet.aspectsecurity.com>

FYI -- Andrew van der Stock (OWASP Guide project lead) has posted a
challenge (http://www.greebo.net/?p=320) to the PHP community -- get secure
or become irrelevant. The tradeoffs being discussed between power,
simplicity, and security are relevant to all environments. In fact, anyone
designing an API for anything should read the discussion
(http://shiflett.org/archive/185) and think about whether it encourages
secure software. 

 

"After writing PHP forum software for three years now, I've come to the
conclusion that it is basically impossible for normal programmers to write
secure PHP code. It takes far too much effort. PHP needs a proper security
architecture, and support for newbie programmers. PHP's raison d'etre is
that it is simple to pick up and make it do something useful. There needs to
be a major push by the PHP Development team to take this advantage, and make
it safe for the likely level of programmers - newbies. Newbies have zero
chance of writing secure software unless their language is safe. 

... 

There are so many ways to break PHP that it is impossible for even
experienced security professionals like me to code in it securely all the
time. There are nearly 4000 function calls, and many of them have unintended
consequences or have been inappropriately extended by something else. At
every turn, the PHP Development Team have made truly terrible "security"
choices: register_globals, magic_quotes_gpc (and friends), PHP wrappers,
safe mode, output, XML, LDAP, and SQL interfaces that intermingle data and
query elements, which by their very nature are impossible to protect against
injection attacks. All of these are broken. They are disjunct and have no
security model. Some of the features, like PHP wrappers, are not well
documented, and are a clear and present danger to PHP scripts and worse,
they do not obey the weak "safe" mode restrictions. I bet few PHP coders are
aware of them, let alone their security impacts. 

... 

PHP must now mature and take on a proper security architecture, an over
arching security model which prevents or limits attack surface area until
the application explicitly asks for it. There can be no other way. If you
look at Bugtraq, every day, 10-50 PHP applications are broken mercilessly.
This cannot continue. Hosters cannot pay the price for the PHP development
team's lack of security expertise."

 

--Jeff

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060125/ed67e5d1/attachment.html 

From Ken at krvw.com  Fri Jan 27 11:20:04 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Fri, 27 Jan 2006 11:20:04 -0500
Subject: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS X
	Exploits"
Message-ID: <200601271120.04646@KRvW>

Interesting article, I suppose, but I'm not convinced of its conclusion:

http://www.eweek.com/article2/0,1895,1915923,00.asp

The article claims that Apple's use of Intel chips will result in more 
software exploits because, "'Attackers have been focused on the [Intel] x86 
for over a decade. Macintosh will have a lot more exposure than when it was 
on PowerPC,' said Oliver Friedrichs, a senior manager at Symantec Corp. 
Security Response."

I was hoping to find some hint of a hardware architectural feature that the 
powerpc has that provided an additional means of protection, but the article 
mentions none.  Instead, the only reason that it cites for the (presumed) 
increase in software exploits is attackers' knowledge and experience base.

After all, didn't attackers also have access to powerpc systems to build 
attacks on during the same timeframe that Symantec suggests?  Does the 
powerpc architecture provide some inherent protection against (say) stack 
smashing than the x86 does?

Am I missing something here?

Cheers,

Ken
-- 
KRvW Associates, LLC
http://www.KRvW.com


From arjones at simultan.dyndns.org  Fri Jan 27 12:04:10 2006
From: arjones at simultan.dyndns.org (Andrew Rucker Jones)
Date: Fri, 27 Jan 2006 18:04:10 +0100
Subject: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS
	X	Exploits"
In-Reply-To: <200601271120.04646@KRvW>
References: <200601271120.04646@KRvW>
Message-ID: <43DA528A.50905@simultan.dyndns.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> After all, didn't attackers also have access to powerpc systems to build 
> attacks on during the same timeframe that Symantec suggests?  Does the 
> powerpc architecture provide some inherent protection against (say) stack 
> smashing than the x86 does?

I'm not a PowerPC expert, but everything i have read indicates that it
is not any more secure than the x86 architecture. No NX bit, for
example. I think the comments are based solely on the comparative
installed user base, as You observed.

		-&

- --
GPG key / Schl?ssel -- http://simultan.dyndns.org/~arjones/gpgkey.txt
Encrypt everything. / Alles verschl?sseln.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFD2lKIoI7tqy5bNGMRA/EvAJ9HXD+ojMPQIIP6bwbzbtb5ce/+AACgnblz
iXHGvSO4Ttv+HOKrYwzhd9o=
=89q4
-----END PGP SIGNATURE-----


From crispin at novell.com  Fri Jan 27 12:06:36 2006
From: crispin at novell.com (Crispin Cowan)
Date: Fri, 27 Jan 2006 09:06:36 -0800
Subject: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS
	X	Exploits"
In-Reply-To: <200601271120.04646@KRvW>
References: <200601271120.04646@KRvW>
Message-ID: <43DA531C.2040307@novell.com>

Kenneth R. van Wyk wrote:
> Interesting article, I suppose, but I'm not convinced of its conclusion:
>
> http://www.eweek.com/article2/0,1895,1915923,00.asp
>
> The article claims that Apple's use of Intel chips will result in more 
> software exploits because, "'Attackers have been focused on the [Intel] x86 
> for over a decade. Macintosh will have a lot more exposure than when it was 
> on PowerPC,' said Oliver Friedrichs, a senior manager at Symantec Corp. 
> Security Response."
> ...
> Am I missing something here?
>   
Security by obscurity. It is lame, but for fending off bulk infections,
it works well. I agree with the article that Macs will get more exposure
and attack now.

However, Mac OS X (and Linux and *BSD) still hold the major advantage
over Windows that it is uncommon to run the mail client as
root/administrator, so the infection rate will remain much lower than on
Windows. Only when attackers have an actual exploit for the Mac/*NIX can
they 0wn the machine. On Windows, they just need a good line and a user
dumb enough to click on the attachment.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption



From pmeunier at cerias.purdue.edu  Fri Jan 27 11:55:49 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Fri, 27 Jan 2006 11:55:49 -0500
Subject: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS X
	Exploits"
In-Reply-To: <200601271120.04646@KRvW>
Message-ID: <BFFFBAC5.FC4C%pmeunier@cerias.purdue.edu>

On 1/27/06 11:20 AM, "Kenneth R. van Wyk" <Ken at krvw.com> wrote:

> Interesting article, I suppose, but I'm not convinced of its conclusion:
> 
> http://www.eweek.com/article2/0,1895,1915923,00.asp
> 
> The article claims that Apple's use of Intel chips will result in more
> software exploits because, "'Attackers have been focused on the [Intel] x86
> for over a decade. Macintosh will have a lot more exposure than when it was
> on PowerPC,' said Oliver Friedrichs, a senior manager at Symantec Corp.
> Security Response."
> 
> I was hoping to find some hint of a hardware architectural feature that the
> powerpc has that provided an additional means of protection, but the article
> mentions none.  Instead, the only reason that it cites for the (presumed)
> increase in software exploits is attackers' knowledge and experience base.
> 
> After all, didn't attackers also have access to powerpc systems to build
> attacks on during the same timeframe that Symantec suggests?  Does the
> powerpc architecture provide some inherent protection against (say) stack
> smashing than the x86 does?
> 
> Am I missing something here?
It resembles a speculative economic argument.  The main point is the
possible re-use of assembly code knowledge and tools.  A barrier to entry
(the cost of learning PowerPC assembly code and developing support tools for
it) has been removed for some individuals, due to the change to Intel.
Presumably, if you lower the cost, more people will do it.  Whether this
will make a significant difference is pure opinion.

Cheers,
Pascal




From mouse at Rodents.Montreal.QC.CA  Fri Jan 27 12:55:30 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Fri, 27 Jan 2006 12:55:30 -0500 (EST)
Subject: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS X
	Exploits"
In-Reply-To: <200601271120.04646@KRvW>
References: <200601271120.04646@KRvW>
Message-ID: <200601271800.NAA19927@Sparkle.Rodents.Montreal.QC.CA>

> The article claims that Apple's use of Intel chips will result in
> more software exploits because, "'Attackers have been focused on the
> [Intel] x86 for over a decade. Macintosh will have a lot more
> exposure than when it was on PowerPC,'

Sounds likely.

> I was hoping to find some hint of a hardware architectural feature
> that the powerpc has that provided an additional means of protection,
> but the article mentions none.  Instead, the only reason that it
> cites for the (presumed) increase in software exploits is attackers'
> knowledge and experience base.

I think that's probably fair.  PPC is probably a little harder to work
with because it's RISC, making it harder to write code without NULs
(and a lot of injection mechanisms won't work if you have embedded
NULs).

However, it's not really very much harder, and attackers would have
done it if the PPC target had been as big as the x86 target.

> After all, didn't attackers also have access to powerpc systems to
> build attacks on during the same timeframe that Symantec suggests?

Sure, but less motivation to do so, because most of the machines out
there were, and are, x86.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From ljknews at mac.com  Fri Jan 27 12:56:20 2006
From: ljknews at mac.com (ljknews)
Date: Fri, 27 Jan 2006 12:56:20 -0500
Subject: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS X
	Exploits"
In-Reply-To: <200601271120.04646@KRvW>
References: <200601271120.04646@KRvW>
Message-ID: <p05200f1ac0000eb1d0fc@[192.168.1.254]>

At 11:20 AM -0500 1/27/06, Kenneth R. van Wyk wrote:
> Interesting article, I suppose, but I'm not convinced of its conclusion:
> 
> http://www.eweek.com/article2/0,1895,1915923,00.asp
> 
> The article claims that Apple's use of Intel chips will result in more 
> software exploits because, "'Attackers have been focused on the [Intel] x86 
> for over a decade. Macintosh will have a lot more exposure than when it was 
> on PowerPC,' said Oliver Friedrichs, a senior manager at Symantec Corp. 
> Security Response."
> 
> I was hoping to find some hint of a hardware architectural feature that the 
> powerpc has that provided an additional means of protection, but the article 
> mentions none.  Instead, the only reason that it cites for the (presumed) 
> increase in software exploits is attackers' knowledge and experience base.
> 
> After all, didn't attackers also have access to powerpc systems to build 
> attacks on during the same timeframe that Symantec suggests?  Does the 
> powerpc architecture provide some inherent protection against (say) stack 
> smashing than the x86 does?
> 
> Am I missing something here?

The most charitable (to the writer of the article) interpretation I can
think of is that the sociopaths have experience dealing with BIOS and
that sort of thing.

But I do not know that Intel Macintoshes boot the same way Intel PCs
do -- certainly they have aspects to support MacOS running that are
missing from Intel PCs.
-- 
Larry Kilgallen


From jose at monkey.org  Fri Jan 27 12:54:22 2006
From: jose at monkey.org (Jose Nazario)
Date: Fri, 27 Jan 2006 12:54:22 -0500 (EST)
Subject: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS X
	Exploits"
In-Reply-To: <43DA531C.2040307@novell.com>
References: <200601271120.04646@KRvW> <43DA531C.2040307@novell.com>
Message-ID: <Pine.BSO.4.58.0601271252200.6912@naughty.monkey.org>

some docs on buffer overflows on PPC:

	http://www.xfocus.org/documents/200408/5.html


also:

"The independent data and instruction caches of the PowerPC processor can
cause a variety of problems with exploit and shellcode development."
source: http://www.uninformed.org/?v=1&a=1&t=txt by HD Moore


in short it's not quite as straightforward as it seems, but obviously
possible, and that has been one of the hindrences to people developing
attacks for the chip. unfortunately, there is no shortage of bugs to
exploit on most common PPC OSes (AIX, OS X mainly).

________
jose nazario, ph.d.			jose at monkey.org
http://monkey.org/~jose/ 		http://infosecdaily.net/
					http://www.wormblog.com/


From BlueBoar at thievco.com  Fri Jan 27 14:24:24 2006
From: BlueBoar at thievco.com (Blue Boar)
Date: Fri, 27 Jan 2006 11:24:24 -0800
Subject: [SC-L] eWeek says "Apple's Switch to Intel Could Allow
	OS	X	Exploits"
In-Reply-To: <43DA531C.2040307@novell.com>
References: <200601271120.04646@KRvW> <43DA531C.2040307@novell.com>
Message-ID: <43DA7368.8030406@thievco.com>

Crispin Cowan wrote:
> However, Mac OS X (and Linux and *BSD) still hold the major advantage
> over Windows that it is uncommon to run the mail client as
> root/administrator, so the infection rate will remain much lower than on
> Windows.

You don't need to be root to infect and spread.

						BB


From pmeunier at cerias.purdue.edu  Fri Jan 27 14:51:18 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Fri, 27 Jan 2006 14:51:18 -0500
Subject: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS X
	Exploits"
In-Reply-To: <43DA531C.2040307@novell.com>
Message-ID: <BFFFE3E6.FC7C%pmeunier@cerias.purdue.edu>




On 1/27/06 12:06 PM, "Crispin Cowan" <crispin at novell.com> wrote:

> 
> However, Mac OS X (and Linux and *BSD) still hold the major advantage
> over Windows that it is uncommon to run the mail client as
> root/administrator, so the infection rate will remain much lower than on
> Windows. Only when attackers have an actual exploit for the Mac/*NIX can
> they 0wn the machine. On Windows, they just need a good line and a user
> dumb enough to click on the attachment.


Not to mention other design issues such as the search path for dlls and
executables being different in Windows, and exhibiting complex behavior that
varies from update to update, with poor documentation of those changes (or
ignorance on my part of where they are documented, as they are not easily
found with Google).  A pet peeve of mine is how the recommendation to not
have "." in your PATH in UNIX is impossible to translate for the Windows
world.  The search path for executables (at the command line prompt, anyway)
in Windows *always* includes the current directory (the search path for dlls
can be made to exclude the current directory with a special call with a NULL
parameter).  I noticed a change for the worst just recently: now the current
directory is searched before any directory in the PATH environment variable,
even if PATH contains ";." as the last item (it used to be that you could
make the current directory searched last by having ";." as the last item in
the PATH).

Pascal




From gem at cigital.com  Fri Jan 27 15:34:19 2006
From: gem at cigital.com (Gary McGraw)
Date: Fri, 27 Jan 2006 15:34:19 -0500
Subject: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS
	XExploits"
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F1581@va-mail.cigital.com>

Hi all,

We talk about different targets and payloads in Exploiting Software.  Bottom line, my opinion is that it's not that much harder.  So the switch should be a wash.

gem

 -----Original Message-----
From: 	der Mouse [mailto:mouse at rodents.montreal.qc.ca]
Sent:	Fri Jan 27 15:29:59 2006
To:	SC-L at securecoding.org
Subject:	Re: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS XExploits"

> The article claims that Apple's use of Intel chips will result in
> more software exploits because, "'Attackers have been focused on the
> [Intel] x86 for over a decade. Macintosh will have a lot more
> exposure than when it was on PowerPC,'

Sounds likely.

> I was hoping to find some hint of a hardware architectural feature
> that the powerpc has that provided an additional means of protection,
> but the article mentions none.  Instead, the only reason that it
> cites for the (presumed) increase in software exploits is attackers'
> knowledge and experience base.

I think that's probably fair.  PPC is probably a little harder to work
with because it's RISC, making it harder to write code without NULs
(and a lot of injection mechanisms won't work if you have embedded
NULs).

However, it's not really very much harder, and attackers would have
done it if the PPC target had been as big as the x86 target.

> After all, didn't attackers also have access to powerpc systems to
> build attacks on during the same timeframe that Symantec suggests?

Sure, but less motivation to do so, because most of the machines out
there were, and are, x86.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From Ken at krvw.com  Mon Jan 30 13:09:29 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Mon, 30 Jan 2006 13:09:29 -0500
Subject: [SC-L] eWeek: AJAX Poses Security, Performance Risks
Message-ID: <200601301309.30078@KRvW>

Any AJAX experts here want to comment on the eWeek article cited below?

http://www.eweek.com/article2/0,1895,1916673,00.asp

It claims, among other things that, "AJAX dramatically increases the amount of 
XML network traffic being transmitted, exposing applications to Web services 
vulnerabilities".

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com


From gem at cigital.com  Mon Jan 30 13:29:56 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 30 Jan 2006 13:29:56 -0500
Subject: [SC-L] Bugs and flaws
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4210AD@va-mail.cigital.com>

Hi all,

If the WMF vulnerability teaches us anything, it teaches us that we need
to pay more attention to flaws.  We spend lots of time talking about
bugs in software security (witness the perpetual flogging of the buffer
overflow), but architectural problems are just as important and deserve
just as much airplay.

My IT Architect column slated to appear in March makes this point a bit
more forcefully:
http://www.cigital.com/papers/download/3sec.ita.pdf

BTW, the final countdown for the release of my new book "Software
Security" has begun (I have yet to see an actual copy).  I'll keep you
posted.

gem

p.s. Hope to see many of you in person at the Software Security Summit
in La Jolla next week.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From pmeunier at cerias.purdue.edu  Mon Jan 30 13:48:42 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Mon, 30 Jan 2006 13:48:42 -0500
Subject: [SC-L] eWeek: AJAX Poses Security, Performance Risks
In-Reply-To: <200601301309.30078@KRvW>
Message-ID: <C003C9BA.FD21%pmeunier@cerias.purdue.edu>

On 1/30/06 1:09 PM, "Kenneth R. van Wyk" <Ken at krvw.com> wrote:

> Any AJAX experts here want to comment on the eWeek article cited below?
> 
> http://www.eweek.com/article2/0,1895,1916673,00.asp
> 
> It claims, among other things that, "AJAX dramatically increases the amount of
> XML network traffic being transmitted, exposing applications to Web services
> vulnerabilities".
> 
> Cheers,
> 
> Ken van Wyk

AJAX bothers me strongly for none of the reasons mentioned, which are
"curiously" limited to the capabilities of the "solution" from the same
source as the alert.  AJAX:

- Forces people to open their browsers to potentially malicious client-side
scripts from other sites, unless users actively manage their IE zones (I've
rarely found people who even know how to use them) or use something like the
NoScript firefox extension (and even then it needs better SSL support as it
depends and trusts DNS unless you specify the fully-qualified url).
JavaScript is a notorious attack vector.  I have the same issue with Windows
Media Player 10 (the internet radio part requires JavaScript to work) and
any site that forces visitors to use JavaScript to access content.
Requiring JavaScript is unconscionable, security-wise, in my opinion.

- Tempts software developers to assume that it's their code that is running
on the client, and trust it with input validation, access control, and
sensitive values.  This is a repeated, typical mistake in client-side
scripting.  Why tempt people into doing stupid things?

Cheers,
Pascal




From ljknews at mac.com  Mon Jan 30 14:21:24 2006
From: ljknews at mac.com (ljknews)
Date: Mon, 30 Jan 2006 14:21:24 -0500
Subject: [SC-L] eWeek: AJAX Poses Security, Performance Risks
In-Reply-To: <200601301309.30078@KRvW>
References: <200601301309.30078@KRvW>
Message-ID: <p05200f12c0041746babe@[192.168.1.254]>

At 1:09 PM -0500 1/30/06, Kenneth R. van Wyk wrote:
> Any AJAX experts here want to comment on the eWeek article cited below?
> 
> http://www.eweek.com/article2/0,1895,1916673,00.asp
> 
> It claims, among other things that, "AJAX dramatically increases the amount of 
> XML network traffic being transmitted, exposing applications to Web services 
> vulnerabilities".

I have been involved in a dialog with AJAX fans (which is different from
experts) who say "you security folks just have to bow to the inevitable
and figure out how to secure whatever mechanism we come up with.

As for the article, it is obviously self-serving for someone's product.
-- 
Larry Kilgallen


From jose at monkey.org  Mon Jan 30 14:28:41 2006
From: jose at monkey.org (Jose Nazario)
Date: Mon, 30 Jan 2006 14:28:41 -0500 (EST)
Subject: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS X
	Exploits"
In-Reply-To: <Pine.BSO.4.58.0601271252200.6912@naughty.monkey.org>
References: <200601271120.04646@KRvW> <43DA531C.2040307@novell.com>
	<Pine.BSO.4.58.0601271252200.6912@naughty.monkey.org>
Message-ID: <Pine.BSO.4.58.0601301427530.23178@naughty.monkey.org>

a couple of technical resources i forgot:

http://www.phrack.org/phrack/63/p63-0x10_PowerPC_Cracking_on_OSX_with_GDB.txt
Reverse engineering - PowerPC Cracking on OSX with GDB

http://www.phrack.org/phrack/63/p63-0x05_OSX_Heap_Exploitation_Technqiues.txt
OS X heap exploitation techniques



________
jose nazario, ph.d.			jose at monkey.org
http://monkey.org/~jose/ 		http://infosecdaily.net/
					http://www.wormblog.com/


From crispin at novell.com  Wed Feb  1 01:31:42 2006
From: crispin at novell.com (Crispin Cowan)
Date: Tue, 31 Jan 2006 22:31:42 -0800
Subject: [SC-L] eWeek: AJAX Poses Security, Performance Risks
In-Reply-To: <p05200f12c0041746babe@[192.168.1.254]>
References: <200601301309.30078@KRvW> <p05200f12c0041746babe@[192.168.1.254]>
Message-ID: <43E055CE.3060705@novell.com>

ljknews wrote:
> I have been involved in a dialog with AJAX fans (which is different from
> experts) who say "you security folks just have to bow to the inevitable
> and figure out how to secure whatever mechanism we come up with.
>   
This attitude is not unique to AJAX advocates. I remember holding this
view myself, while wrestling with the problems of producing a truly
transparent distributed operating system in the late 1980s and early
1990s; security was a bother that made things hard(er).

Of course, this is just lifetime employment for security people :) I
have certainly made a career out of securing things that are inherently
insecure.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption




From crispin at novell.com  Wed Feb  1 02:36:45 2006
From: crispin at novell.com (Crispin Cowan)
Date: Tue, 31 Jan 2006 23:36:45 -0800
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4210AD@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4210AD@va-mail.cigital.com>
Message-ID: <43E0650D.7000205@novell.com>

Gary McGraw wrote:
> If the WMF vulnerability teaches us anything, it teaches us that we need
> to pay more attention to flaws.
The "flaw" in question seems to be "validate inputs", i.e. don't just
trust network input (esp. from an untrusted source) to be well-formed.

Of special importance to the Windows family of platforms seems to be the
propensity to do security controls based on the file type extension (the
letters after the dot in the file name, such as .wmf) but to choose the
application to interpret the data based on some magic file typing based
on looking at the content.

My favorite ancient form of this flaw: .rtf files are much safer than
doc files, because the RTF standard does not allow you to attach
VBscript (where "VB" stands for "Virus Broadcast" :) while .doc files
do. Unfortunately, this safety feature is nearly useless, because if you
take an infected whatever.doc file, and just *rename* it to whatever.rtf
and send it, then MS Word will cheerfully open the file for you when you
double click on the attachment, ignore the mismatch between the file
extension and the actual file type, and run the fscking VB embedded within.

I am less familiar with the WMF flaw, but it smells like the same thing.

Validate your inputs.

There are automatic tools (taint and equivalent) that will check whether
you have validated your inputs. But they do *not* check the *quality* of
your validation of the input. Doing a consistency check on the file name
extension and the data interpreter type for the file is beyond (most?)
such checkers.

>   We spend lots of time talking about
> bugs in software security (witness the perpetual flogging of the buffer
> overflow), but architectural problems are just as important and deserve
> just as much airplay.
>   
IMHO the difference between "bugs" and "architecture" is just a
continuous grey scale of degree.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption



From bellovin at acm.org  Wed Feb  1 11:53:48 2006
From: bellovin at acm.org (Steven M. Bellovin)
Date: Wed, 01 Feb 2006 11:53:48 -0500
Subject: [SC-L] Bugs and flaws 
Message-ID: <20060201165348.F21C23C0229@berkshire.machshav.com>

In message <43E0650D.7000205 at novell.com>, Crispin Cowan writes:
> Unfortunately, this safety feature is nearly useless, because if you
>take an infected whatever.doc file, and just *rename* it to whatever.rtf
>and send it, then MS Word will cheerfully open the file for you when you
>double click on the attachment, ignore the mismatch between the file
>extension and the actual file type, and run the fscking VB embedded within.
>

That actually illustrates a different principle: don't have two 
different ways of checking for the same thing.

		--Steve Bellovin, http://www.stevebellovin.com




From dwheeler at ida.org  Wed Feb  1 13:36:24 2006
From: dwheeler at ida.org (David A. Wheeler)
Date: Wed, 01 Feb 2006 13:36:24 -0500
Subject: [SC-L] Bugs and flaws -- Micro-tainting
References: <200602011700.k11H03lb013102@ratsass.krvw.com>
Message-ID: <43E0FFA8.2070407@ida.org>

Crispin Cowan declared:
 >...Validate your inputs.
 >There are automatic tools (taint and equivalent) that will check whether
 >you have validated your inputs. But they do *not* check the *quality* of
 >your validation of the input. Doing a consistency check on the file name
 >extension and the data interpreter type for the file is beyond (most?)
 >such checkers.

Aleks Kissinger (who interned here) and I have actually
done research in that direction, which we call "micro-tainting".
Instead of declaring an entire field as "tainted" or not,
you track individual units (typically individual characters).
If the character came from an untrusted source, it's tainted;
if it came from a trusted source (e.g., program constants) it's not.

You can do this dynamically by using a different string library
or changing the implementation of the standard string library
for the language you're using.  It's particularly easy if
you use 32bits for unicode characters, because you already
have some unused bits.  We've done this, and we're not the
only ones.  There's also PHP module that does this;
it even stores the taint information in a database,
so later data retrievals STILL know which characters came from
untrusted sources.  (The PHP folks came up with the idea
independently of us; we only learned of each other via Usenix,
after we'd both developed the idea further.)

More interesting to us was doing this _statically_, i.e.,
determining before run-time.  Aleks' ACSAC 2005 public talk
primarily discussed how to do it statically.

Of course, just tracking tainting isn't enough... you still need
to know what is acceptable to "output", and to WHERE.
But this only requires identifying specific output functions
that can be dangerous (system(), etc.) and a spec of WHAT
is okay.  We found regular expressions were actually a
simple and convenient way to express where taint would be
allowed (and where it wouldn't), though BNFs and any other
language definition system works just fine too.

Oh, and here's an interesting tidbit.  For the static case,
if you work backwards, when the check ?fails? you can
even trivially derive the input patterns that cause
security failures (and from that information it
should be easy to figure out how to fix it).

This was presented at ACSAC 2005 in the "Works in Progress" session.

Of course, this is all WAY beyond what typical language
implementations provide developers today.  But it's worth
knowing about.

--- David A. Wheeler




From jsteven at cigital.com  Wed Feb  1 16:58:41 2006
From: jsteven at cigital.com (John Steven)
Date: Wed, 01 Feb 2006 16:58:41 -0500
Subject: [SC-L] Bugs and flaws
In-Reply-To: <43E0650D.7000205@novell.com>
Message-ID: <C0069941.9CD8%jsteven@cigital.com>

I'm not sure there's any value in discussing this minutia further, but here
goes:

1) Crispin, I think you've nailed one thing. The continuum from:

Architecture --> Design --> Low-level Design --> (to) Implementation

is a blurry one, and certainly slippery as you move from 'left' to 'right'.
But, we all should understand that there's commensurate blur in our analysis
techniques (aka architecture and code review) to assure that as we sweep
over software that we uncover both bugs and architectural flaws.
  
2) Flaws are different in important ways bugs when it comes to presentation,
prioritization, and mitigation. Let's explore by physical analog first.

I nearly fell through one of my consultant's tables as I leaned on it this
morning. We explored: "Bug or flaw?".

A bolt's head had been sheered. The sheer had allowed the bolt to wiggle
loose and made the table top wobble.

IMPL. BUG: The bolt's head was weak-enough to sheer*
* Some readers will complain that the bolt manufacturer should have made the
bolt stronger. Don't get bogged down, we're building a table 'system' here,
and we can't control the bolt any more than we can control IBM's
implementation of Websphere. With respect to this table 'system', we have a
bug.

Was there a masked bug? Was the truss' metal cut but not buffed in a way
that caused an otherwise strong-enough bolt to score over time and
eventually sheer under normal load?

ARCH. FLAW: [Some aspect of the table's design] caused the bolt to sheer.
ARCH. FLAW: The table's design is not resilient to a sheered bolt.

As Crispin, Steve, and myself would likely agree... Good application of
techniques involved in common architectural and code-based analyses would
have likely found all of these problems. Remember, my thesis is that the
real difference is what we do w/ the vulns., not now they're identified.

In my experience, where overlap between bugs and flaws exist, mitigating the
flaw is almost always warranted.

As a table architect, I could have calculated the forces the table would
face (through misuse case def.) and realized that my requirements warranted
a stronger bolt. I can't control the strength of the bolt, but I could pick
a stronger one (Maybe Jboss resists an attack that Websphere doesn't).

Alternatively, I could have designed my system so that the bolt's relative
weakness wasn't exposed. Specifically, I could have introduced more support
trusses into the legs, used additional bolts, pegs, or [whatever] at the
same interface, or scrapped my table design, and started over in an attempt
to avoid that weakness.

'Wondering why a Cigitalite is spending so much time on a table? I'm
beginning to as well; onto Struts:

A valid user accesses a web-app, recognizes that the URLs are predictable,
and tries out www.victim.com/this/that/admin ... It works! He uses the
available interface to change another user's password, then impersonates the
other user's identity.

Regardless of how we unravel this, we know that there was a failure in
authorization of authenticated users.

Which of the following more aptly characterizes the problem?:

IMPL. BUG: Insufficient security-constraint existed on the admin Servlet in
the app's deployment descriptor.

ARCH. FLAW: No fa?ade component gated privileged functionality
-alternatively- 
ARCH. FLAW: Privileged functionality incapable of judging Principal's
entitlement (both fine, one user changing another's password, or coarse,
application functionality improperly accessed)

All of the above statements are ostensibly true... The difference in the
characterization is bias--each implying a different fix. At a workflow
level, I always verify that applications I'm reviewing do, in-fact, possess
the abilities to evaluate Principal identity, and authorize their access to
functionality and data. So, I might be prone to reporting the problem as the
last flaw.

In the case of this example, the bigot in me might get wound up with
labeling the problem as the first architectural flaw. Does the fa?ade
pattern (for security purposes or not) break the Struts pattern of
parameterized dispatch of ActionController Servlets? <shrug> I can't say
conclusively at THIS level of analysis.

Certainly, the implied fix is easiest if I'd characterized the problem as
the security-constraint bug.

Summarizing, my characterization of a vulnerability as a bug or a flaw has
important implications towards how it's mitigated. In the case of the Struts
example, the bug-based fix is easiest--but in so characterizing the problem
I may (or may not) miss other instances of this vulnerability within the
application's code base.

How do I know how to characterize a vulnerability along the continuum of
bugs-->flaws?  I don't know for sure, but I've taken to using my experience
over a number of assessments to "upcast" typically endemic problems as flaws
(and solve them in the design or architecture) and "downcast" those problems
that have glaring quick-fixes. In circumstances where both those heuristics
apply, I suggest a tactical fix to the bug, while prescribing that further
analysis take the tack of further fleshing out the flaw.

Is this at all helpful?


-----
John Steven        
Principal, Software Security Group
Technical Director, Office of the CTO
703 404 5726 - Direct | 703 727 4034 - Cell
Cigital Inc.          | jsteven at cigital.com

4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908


> From: Crispin Cowan <crispin at novell.com>
> 
> Gary McGraw wrote:
>> If the WMF vulnerability teaches us anything, it teaches us that we need
>> to pay more attention to flaws.
> The "flaw" in question seems to be "validate inputs", i.e. don't just
> trust network input (esp. from an untrusted source) to be well-formed.
> 
> Of special importance to the Windows family of platforms seems to be the
> propensity to do security controls based on the file type extension (the
> letters after the dot in the file name, such as .wmf) but to choose the
> application to interpret the data based on some magic file typing based
> on looking at the content.
> 
> My favorite ancient form of this flaw: .rtf files are much safer than
> doc files, because the RTF standard does not allow you to attach
> VBscript (where "VB" stands for "Virus Broadcast" :) while .doc files
> do. Unfortunately, this safety feature is nearly useless, because if you
> take an infected whatever.doc file, and just *rename* it to whatever.rtf
> and send it, then MS Word will cheerfully open the file for you when you
> double click on the attachment, ignore the mismatch between the file
> extension and the actual file type, and run the fscking VB embedded within.
> 
> I am less familiar with the WMF flaw, but it smells like the same thing.
> 
> Validate your inputs.
> 
> There are automatic tools (taint and equivalent) that will check whether
> you have validated your inputs. But they do *not* check the *quality* of
> your validation of the input. Doing a consistency check on the file name
> extension and the data interpreter type for the file is beyond (most?)
> such checkers.
> 
>>   We spend lots of time talking about
>> bugs in software security (witness the perpetual flogging of the buffer
>> overflow), but architectural problems are just as important and deserve
>> just as much airplay.
>>   
> IMHO the difference between "bugs" and "architecture" is just a
> continuous grey scale of degree.



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From crispin at novell.com  Wed Feb  1 17:07:29 2006
From: crispin at novell.com (Crispin Cowan)
Date: Wed, 01 Feb 2006 14:07:29 -0800
Subject: [SC-L] Bugs and flaws
In-Reply-To: <C0069941.9CD8%jsteven@cigital.com>
References: <C0069941.9CD8%jsteven@cigital.com>
Message-ID: <43E13121.9060804@novell.com>

John Steven wrote:
> I'm not sure there's any value in discussing this minutia further, but here
> goes:
>   
We'll let the moderator decide that :)

> 1) Crispin, I think you've nailed one thing. The continuum from:
>
> Architecture --> Design --> Low-level Design --> (to) Implementation
>
> is a blurry one, and certainly slippery as you move from 'left' to 'right'.
>   
Cool.

> But, we all should understand that there's commensurate blur in our analysis
> techniques (aka architecture and code review) to assure that as we sweep
> over software that we uncover both bugs and architectural flaws.
>   
Also agreed.

> 2) Flaws are different in important ways bugs when it comes to presentation,
> prioritization, and mitigation. Let's explore by physical analog first.
>   
I disagree with the word usage. To me, "bug" and "flaw" are exactly
synonyms. The distinction being drawn here is between "implementation
flaws" vs. "design flaws". You are just creating confusing jargon to
claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect
::= bug. A vulnerability is a special subset of flaws/defects/bugs that
has the property of being exploitable.

> I nearly fell through one of my consultant's tables as I leaned on it this
> morning. We explored: "Bug or flaw?".
>   
The wording issue aside, at the implementation level you try to
code/implement to prevent flaws, by doing things such as using higher
quality steel (for bolts) and good coding practices (for software). At
the design level, you try to design so as to *mask* flaws by avoiding
single points of failure, doing things such as using 2 bolts (for
tables) and using access controls to limit privilege escalation (for
software).

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption



From gunnar at arctecgroup.net  Wed Feb  1 17:53:02 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Wed, 1 Feb 2006 16:53:02 -0600
Subject: [SC-L] Bugs and flaws
In-Reply-To: <C0069941.9CD8%jsteven@cigital.com>
References: <C0069941.9CD8%jsteven@cigital.com>
Message-ID: <6A703E5C-6104-41CB-8C94-57ADBCDF59D7@arctecgroup.net>

>
Hi John,

> Which of the following more aptly characterizes the problem?:
>
> IMPL. BUG: Insufficient security-constraint existed on the admin  
> Servlet in
> the app's deployment descriptor.
>
> ARCH. FLAW: No fa?ade component gated privileged functionality
> -alternatively-
> ARCH. FLAW: Privileged functionality incapable of judging Principal's
> entitlement (both fine, one user changing another's password, or  
> coarse,
> application functionality improperly accessed)

Clausewitz said to be strong, first in general, and then at the  
decisive point. Assuming you consider authentication and  
authorization on admin functions a decisive point, then this scenario  
is a failure in both instances. The question you raise is locating  
the responsibility to deal with this problem. In a distributed  
system, there are many potential areas to locate those controls.  
Problems do not necessarily have to be solved (and in some cases  
cannot be) at the same logical layer they were created (http:// 
1raindrop.typepad.com/1_raindrop/2005/11/thinking_in_lay.html). Would  
an authenticating reverse proxy have prevented this problem? How  
about stronger identity protocols?

-gp


From Kevin.Wall at qwest.com  Thu Feb  2 08:53:56 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Thu, 2 Feb 2006 07:53:56 -0600
Subject: [SC-L] Bugs and flaws
References: <C0069941.9CD8%jsteven@cigital.com> <43E13121.9060804@novell.com>
Message-ID: <CF8B26B8B49184429CB084616B00193001588C2C@itomae2km05.AD.QINTRA.COM>

John Steven wrote:
...
> 2) Flaws are different in important ways bugs when it comes to presentation,
> prioritization, and mitigation. Let's explore by physical analog first.

Crispin Cowan responded:  
> I disagree with the word usage. To me, "bug" and "flaw" are exactly
> synonyms. The distinction being drawn here is between "implementation
> flaws" vs. "design flaws". You are just creating confusing jargon to
> claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect
> ::= bug. A vulnerability is a special subset of flaws/defects/bugs that
> has the property of being exploitable.

I'm not sure if this will clarify things or further muddy the waters,
but... partial definitions taken SWEBOK
(http://www.swebok.org/ironman/pdf/Swebok_Ironman_June_23_%202004.pdf)
which in turn were taken from the IEEE standard glossary
(IEEE610.12-90) are:
+ Error: "A difference
between a computed result and the correct result"
+ Fault: "An incorrect step, process, or data definition
          in a computer program"
+ Failure: "The [incorrect] result of a fault"
+ Mistake: "A human action that produces an incorrect result"

Not all faults are manifested as errors. I can't find an online
version of the glossary anywhere, and the one I have is about 15-20 years old
and buried somewhere deep under a score of other rarely used books.

My point is though, until we start with some standard terminology this
field of information security is never going to mature. I propose that
we build on the foundational definitions of the IEEE-CS (unless there
definitions have "bugs" ;-).

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit



From jsteven at cigital.com  Thu Feb  2 09:12:32 2006
From: jsteven at cigital.com (John Steven)
Date: Thu, 02 Feb 2006 09:12:32 -0500
Subject: [SC-L] Bugs and flaws
In-Reply-To: <CF8B26B8B49184429CB084616B00193001588C2C@itomae2km05.AD.QINTRA.COM>
Message-ID: <C0077D80.9CFD%jsteven@cigital.com>

Kevin,

Jeff Payne and I were talking about this last night. Jeff's position was,
"...Or, you could just use the existing quality assurance terminology and
avoid the problem altogether." I agree with you and him; standardizing
terminology is a great start to obviating confusing discussions about what
type of problem the software faces.

Re-reading my post, I realize that it came off as heavy support for
additional terminology. Truth is, we've found that the easiest way to
communicate this concept to our Consultants and Clients here at Cigital has
been to build the two buckets (flaws and bugs).

What I was really trying to present was that Security people could stand to
be a bit more thorough about how they synthesize the results of their
analysis before they communicate the vulnerabilities they've found, and what
mitigating strategies they suggest.

I guess, in my mind, the most important things with regard to classifying
the mistakes software people make that lead to vulnerability (the piety of
vulnerability taxonomies aside) is to support:

1) Selection of the most effective mitigating strategy -and-
2) Root cause analysis that will result in changes in software development
that prevent software folk from making the same mistake again.

-----
John Steven        
Principal, Software Security Group
Technical Director, Office of the CTO
703 404 5726 - Direct | 703 727 4034 - Cell
Cigital Inc.          | jsteven at cigital.com

4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

> From: "Wall, Kevin" <Kevin.Wall at qwest.com>
> 
> John Steven wrote:
> ...
>> 2) Flaws are different in important ways bugs when it comes to presentation,
>> prioritization, and mitigation. Let's explore by physical analog first.
> 
> Crispin Cowan responded:
>> I disagree with the word usage. To me, "bug" and "flaw" are exactly
>> synonyms. The distinction being drawn here is between "implementation
>> flaws" vs. "design flaws". You are just creating confusing jargon to
>> claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect
>> ::= bug. A vulnerability is a special subset of flaws/defects/bugs that
>> has the property of being exploitable.
> 
> I'm not sure if this will clarify things or further muddy the waters,
> but... partial definitions taken SWEBOK
> (http://www.swebok.org/ironman/pdf/Swebok_Ironman_June_23_%202004.pdf)
> which in turn were taken from the IEEE standard glossary
> (IEEE610.12-90) are:
> + Error: "A difference.between a computed result and the correct result"
> + Fault: "An incorrect step, process, or data definition
>           in a computer program"
> + Failure: "The [incorrect] result of a fault"
> + Mistake: "A human action that produces an incorrect result"
> 
> Not all faults are manifested as errors. I can't find an online
> version of the glossary anywhere, and the one I have is about 15-20 years old
> and buried somewhere deep under a score of other rarely used books.
> 
> My point is though, until we start with some standard terminology this
> field of information security is never going to mature. I propose that
> we build on the foundational definitions of the IEEE-CS (unless there
> definitions have "bugs" ;-).
> 
> -kevin
> ---
> Kevin W. Wall  Qwest Information Technology, Inc.
> Kevin.Wall at qwest.com Phone: 614.215.4788
> "The reason you have people breaking into your software all
> over the place is because your software sucks..."
>  -- Former whitehouse cybersecurity advisor, Richard Clarke,
>     at eWeek Security Summit



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Thu Feb  2 11:02:36 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 2 Feb 2006 11:02:36 -0500
Subject: [SC-L] Bugs and flaws
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4210B1@va-mail.cigital.com>

Hi all,

When I introduced the "bugs" and "flaws" nomenclature into the
literature, I did so in an article about the software security workshop
I chaired in 2003 (see http://www.cigital.com/ssw/).  This was
ultimately written up in an "On the Horizon" paper published by IEEE
Security & Privacy.

Nancy Mead and I queried the SWEBOK and looked around to see if the new
usage caused collision.  It did not.  The reason I think it is important
to distinguish the two ends of the rather slippery range (crispy is
right about that) is that software security as a field is not paying
enough attention to architecture.  By identifying flaws as a subcategory
of defects (according the the SWEBOK), we can focus some attention on
the problem.

>From the small glossary in "Software Security" (my new book out
tomorrow):

Bug-A bug is an implementation-level software problem. Bugs may exist in
code but never be executed. Though the term bug is applied quite
generally
by many software practitioners, I reserve use of the term to encompass
fairly
simple implementation errors. Bugs are implementation-level problems
that
can be easily discovered and remedied. See Chapter 1.

Flaw-A design-level or architectural software defect. High-level defects
cause 50% of software security problems. See Chapter 1.

In any case, I intend to still use these terms like this, and I would be
very pleased if you would all join me.

gem



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From weld at vulnwatch.org  Thu Feb  2 16:35:16 2006
From: weld at vulnwatch.org (Chris Wysopal)
Date: Thu, 2 Feb 2006 16:35:16 -0500 (EST)
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4210B1@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4210B1@va-mail.cigital.com>
Message-ID: <Pine.BSO.4.55.0602021528460.9430@vikki.vulnwatch.org>


In the manufacturing world, which is far more mature than the software
development world, they use the terminology of "design defect" and
"manufacturing defect".  So this distinction is useful and has stood the
test of time.

Flaw and defect are synonymous. We should just pick one. You could say
that the term for manufacturing software is "implementation".

So why do we need to change the terms for the software world?  Wouldn't
"design defect" and "implementation defect" be clearer and more in line
with the manufacturing quality discipline, which the software quality
discipline should be working towards emulating. (When do we get to Six
Sigma?)

I just don't see the usefulness of calling a "design defect" a "flaw".
"Flaw" by itself is overloaded.  And in the software world, "bug" can mean
an implementation or design problem, so "bug" alone is overloaded for
describing an implementation defect.

At @stake the Application Center of Excellence used the terminology
"design flaw" and "implementation flaw".  It well understood by our
customers.

As Crispin said in an earlier post on the subject, the line is sometimes
blurry.  I am sure this is the case in manufacturing too.  Architecture
flaws can be folded into the design flaw category for simplicity.

My vote is for a less overloaded and clearer terminology.

-Chris

P.S. My father managed a non-destructive test lab at a jet engine
manufacturer. They had about the highest quality requirements in the
world. So for many hours I was regaled with tales about the benefits of
performing static analysis on individual components early in the
manufacturing cycle.

They would dip cast parts in a fluorescent liquid and look at them under
ultraviolet light to illuminate cracks caused during casting process.
For critical parts which would receive more stress, such as the fan
blades, they would x-ray each part to inspect for internal cracks. A more
expensive process but warranted due to the increased risk of total system
failure for a defect in those parts.

The static testing was obviously much cheaper and delivered better quality
than just bolting the parts together and doing dynamic testing in a test
cell.  It's a wonder that it has taken the software security world so long
to catch onto the benefits of static testing of implementation.  I think
we can learn a lot more from the manufacturing world.

On Thu, 2 Feb 2006, Gary McGraw wrote:

> Hi all,
>
> When I introduced the "bugs" and "flaws" nomenclature into the
> literature, I did so in an article about the software security workshop
> I chaired in 2003 (see http://www.cigital.com/ssw/).  This was
> ultimately written up in an "On the Horizon" paper published by IEEE
> Security & Privacy.
>
> Nancy Mead and I queried the SWEBOK and looked around to see if the new
> usage caused collision.  It did not.  The reason I think it is important
> to distinguish the two ends of the rather slippery range (crispy is
> right about that) is that software security as a field is not paying
> enough attention to architecture.  By identifying flaws as a subcategory
> of defects (according the the SWEBOK), we can focus some attention on
> the problem.
>
> >>From the small glossary in "Software Security" (my new book out
> tomorrow):
>
> Bug-A bug is an implementation-level software problem. Bugs may exist in
> code but never be executed. Though the term bug is applied quite
> generally
> by many software practitioners, I reserve use of the term to encompass
> fairly
> simple implementation errors. Bugs are implementation-level problems
> that
> can be easily discovered and remedied. See Chapter 1.
>
> Flaw-A design-level or architectural software defect. High-level defects
> cause 50% of software security problems. See Chapter 1.
>
> In any case, I intend to still use these terms like this, and I would be
> very pleased if you would all join me.
>
> gem
>
>
>
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>


From gem at cigital.com  Thu Feb  2 15:46:15 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 2 Feb 2006 15:46:15 -0500
Subject: [SC-L] Bugs and flaws
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F16FF@va-mail.cigital.com>

Hi Weld,

You make a very good point.  I think we have lots to learn from
manufacturing.  

As a matter of practice, I usually use the terms that you suggested as
modifiers and say:

implementation bug
design flaw

software defect

As long as there is a clear way to separate the two ends of the slippery
spectrum, I will be happy.  But I'm still gonna say "bug" and "flaw" for
short even when I mean the really long involved things above!  Simplify.

gem



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From mgavin at forrester.com  Thu Feb  2 17:46:33 2006
From: mgavin at forrester.com (Gavin, Michael)
Date: Thu, 2 Feb 2006 17:46:33 -0500
Subject: [SC-L] Bugs and flaws
Message-ID: <79769518040B6B45A46C0AD390FD5A83020396BA@CAMB-EX.forrester.loc>

"Architecture" is also an overloaded term, often meaning either a design
(the output of architects) or the implementation of certain types of
design (the output of engineers). 

Hoping to clarify Chris's comment on architecture flaws: architecture
defects as in the defects in the output produced by architects are
"design flaws"; architecture defects as in the defects in the output of
programmers/coders/engineers are "implementation flaws".

FWIW, I agree with Chris, "design flaw" and "implementation flaw" seem
better/more descriptive/less confusing than revised definitions for
"flaw" and "bug". (Then again, I once worked at @stake..., on the other
hand, IIRC this terminology is more consistent with what you find in
Ross Anderson's classic "Security Engineering".)

Michael

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Chris Wysopal
Sent: Thursday, February 02, 2006 4:35 PM
To: Gary McGraw
Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws


In the manufacturing world, which is far more mature than the software
development world, they use the terminology of "design defect" and
"manufacturing defect".  So this distinction is useful and has stood the
test of time.

Flaw and defect are synonymous. We should just pick one. You could say
that the term for manufacturing software is "implementation".

So why do we need to change the terms for the software world?  Wouldn't
"design defect" and "implementation defect" be clearer and more in line
with the manufacturing quality discipline, which the software quality
discipline should be working towards emulating. (When do we get to Six
Sigma?)

I just don't see the usefulness of calling a "design defect" a "flaw".
"Flaw" by itself is overloaded.  And in the software world, "bug" can
mean
an implementation or design problem, so "bug" alone is overloaded for
describing an implementation defect.

At @stake the Application Center of Excellence used the terminology
"design flaw" and "implementation flaw".  It well understood by our
customers.

As Crispin said in an earlier post on the subject, the line is sometimes
blurry.  I am sure this is the case in manufacturing too.  Architecture
flaws can be folded into the design flaw category for simplicity.

My vote is for a less overloaded and clearer terminology.

-Chris

P.S. My father managed a non-destructive test lab at a jet engine
manufacturer. They had about the highest quality requirements in the
world. So for many hours I was regaled with tales about the benefits of
performing static analysis on individual components early in the
manufacturing cycle.

They would dip cast parts in a fluorescent liquid and look at them under
ultraviolet light to illuminate cracks caused during casting process.
For critical parts which would receive more stress, such as the fan
blades, they would x-ray each part to inspect for internal cracks. A
more
expensive process but warranted due to the increased risk of total
system
failure for a defect in those parts.

The static testing was obviously much cheaper and delivered better
quality
than just bolting the parts together and doing dynamic testing in a test
cell.  It's a wonder that it has taken the software security world so
long
to catch onto the benefits of static testing of implementation.  I think
we can learn a lot more from the manufacturing world.

On Thu, 2 Feb 2006, Gary McGraw wrote:

> Hi all,
>
> When I introduced the "bugs" and "flaws" nomenclature into the
> literature, I did so in an article about the software security
workshop
> I chaired in 2003 (see http://www.cigital.com/ssw/).  This was
> ultimately written up in an "On the Horizon" paper published by IEEE
> Security & Privacy.
>
> Nancy Mead and I queried the SWEBOK and looked around to see if the
new
> usage caused collision.  It did not.  The reason I think it is
important
> to distinguish the two ends of the rather slippery range (crispy is
> right about that) is that software security as a field is not paying
> enough attention to architecture.  By identifying flaws as a
subcategory
> of defects (according the the SWEBOK), we can focus some attention on
> the problem.
>
> >>From the small glossary in "Software Security" (my new book out
> tomorrow):
>
> Bug-A bug is an implementation-level software problem. Bugs may exist
in
> code but never be executed. Though the term bug is applied quite
> generally
> by many software practitioners, I reserve use of the term to encompass
> fairly
> simple implementation errors. Bugs are implementation-level problems
> that
> can be easily discovered and remedied. See Chapter 1.
>
> Flaw-A design-level or architectural software defect. High-level
defects
> cause 50% of software security problems. See Chapter 1.
>
> In any case, I intend to still use these terms like this, and I would
be
> very pleased if you would all join me.
>
> gem
>
>
>
>
------------------------------------------------------------------------
----
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is
intended
> solely for the recipient and use by any other party is not authorized.
If
> you are not the intended recipient (or otherwise authorized to receive
this
> message by the intended recipient), any disclosure, copying,
distribution or
> use of the contents of the information is prohibited.  If you have
received
> this electronic message transmission in error, please contact the
sender by
> reply email and delete all copies of this message.  Cigital, Inc.
accepts no
> responsibility for any loss or damage resulting directly or indirectly
from
> the use of this email or its contents.
> Thank You.
>
------------------------------------------------------------------------
----
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
> List charter available at -
http://www.securecoding.org/list/charter.php
>
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php



From gunnar at arctecgroup.net  Thu Feb  2 17:24:13 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Thu,  2 Feb 2006 16:24:13 -0600
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4210B1@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4210B1@va-mail.cigital.com>
Message-ID: <1138919053.43e2868d5a935@my.visi.com>

So from a countermeasure standpoint, a bug can and should be fixed locally,
while a flaw may require that the countermeasure exists at a different level of
abstraction. For example, I assume no one thinks (in OO at least) that input
validation is resident in every method, but rather called externally.

-gp

Quoting Gary McGraw <gem at cigital.com>:

> Hi all,
>
> When I introduced the "bugs" and "flaws" nomenclature into the
> literature, I did so in an article about the software security workshop
> I chaired in 2003 (see http://www.cigital.com/ssw/).  This was
> ultimately written up in an "On the Horizon" paper published by IEEE
> Security & Privacy.
>
> Nancy Mead and I queried the SWEBOK and looked around to see if the new
> usage caused collision.  It did not.  The reason I think it is important
> to distinguish the two ends of the rather slippery range (crispy is
> right about that) is that software security as a field is not paying
> enough attention to architecture.  By identifying flaws as a subcategory
> of defects (according the the SWEBOK), we can focus some attention on
> the problem.
>
> >From the small glossary in "Software Security" (my new book out
> tomorrow):
>
> Bug-A bug is an implementation-level software problem. Bugs may exist in
> code but never be executed. Though the term bug is applied quite
> generally
> by many software practitioners, I reserve use of the term to encompass
> fairly
> simple implementation errors. Bugs are implementation-level problems
> that
> can be easily discovered and remedied. See Chapter 1.
>
> Flaw-A design-level or architectural software defect. High-level defects
> cause 50% of software security problems. See Chapter 1.
>
> In any case, I intend to still use these terms like this, and I would be
> very pleased if you would all join me.
>
> gem
>
>
>
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>



From dcrocker at eschertech.com  Thu Feb  2 17:50:02 2006
From: dcrocker at eschertech.com (David Crocker)
Date: Thu, 2 Feb 2006 22:50:02 -0000
Subject: [SC-L] Bugs and flaws
In-Reply-To: <Pine.BSO.4.55.0602021528460.9430@vikki.vulnwatch.org>
Message-ID: <028401c6284b$0161c240$cb00000a@escheradmin>

I don't think this analogy between software development and manufacturing holds.
There are no "manufacturing defects" in software construction, unless one counts
a buggy chip (e.g. Pentium FPU or similar) or perhaps a buggy compiler. Software
instructions execute predictably and are not subject to the problems of
defective materials, difficulties in keeping dimensions within a precise
tolerance, or wear and tear.

If some small bolt in my car fails because the bolt met its manufacturer's
specification but was not strong enough to withstand the loads it was subjected
to, that is a low-level design error, not a manufacturing error. Similarly, I
view coding errors as low-level design errors.

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com



-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On
Behalf Of Chris Wysopal
Sent: 02 February 2006 21:35
To: Gary McGraw
Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws



In the manufacturing world, which is far more mature than the software
development world, they use the terminology of "design defect" and
"manufacturing defect".  So this distinction is useful and has stood the test of
time.

Flaw and defect are synonymous. We should just pick one. You could say that the
term for manufacturing software is "implementation".

So why do we need to change the terms for the software world?  Wouldn't "design
defect" and "implementation defect" be clearer and more in line with the
manufacturing quality discipline, which the software quality discipline should
be working towards emulating. (When do we get to Six
Sigma?)

I just don't see the usefulness of calling a "design defect" a "flaw". "Flaw" by
itself is overloaded.  And in the software world, "bug" can mean an
implementation or design problem, so "bug" alone is overloaded for describing an
implementation defect.

At @stake the Application Center of Excellence used the terminology "design
flaw" and "implementation flaw".  It well understood by our customers.

As Crispin said in an earlier post on the subject, the line is sometimes blurry.
I am sure this is the case in manufacturing too.  Architecture flaws can be
folded into the design flaw category for simplicity.

My vote is for a less overloaded and clearer terminology.

-Chris

P.S. My father managed a non-destructive test lab at a jet engine manufacturer.
They had about the highest quality requirements in the world. So for many hours
I was regaled with tales about the benefits of performing static analysis on
individual components early in the manufacturing cycle.

They would dip cast parts in a fluorescent liquid and look at them under
ultraviolet light to illuminate cracks caused during casting process. For
critical parts which would receive more stress, such as the fan blades, they
would x-ray each part to inspect for internal cracks. A more expensive process
but warranted due to the increased risk of total system failure for a defect in
those parts.

The static testing was obviously much cheaper and delivered better quality than
just bolting the parts together and doing dynamic testing in a test cell.  It's
a wonder that it has taken the software security world so long to catch onto the
benefits of static testing of implementation.  I think we can learn a lot more
from the manufacturing world.

On Thu, 2 Feb 2006, Gary McGraw wrote:

> Hi all,
>
> When I introduced the "bugs" and "flaws" nomenclature into the 
> literature, I did so in an article about the software security 
> workshop I chaired in 2003 (see http://www.cigital.com/ssw/).  This 
> was ultimately written up in an "On the Horizon" paper published by 
> IEEE Security & Privacy.
>
> Nancy Mead and I queried the SWEBOK and looked around to see if the 
> new usage caused collision.  It did not.  The reason I think it is 
> important to distinguish the two ends of the rather slippery range 
> (crispy is right about that) is that software security as a field is 
> not paying enough attention to architecture.  By identifying flaws as 
> a subcategory of defects (according the the SWEBOK), we can focus some 
> attention on the problem.
>
> >>From the small glossary in "Software Security" (my new book out
> tomorrow):
>
> Bug-A bug is an implementation-level software problem. Bugs may exist 
> in code but never be executed. Though the term bug is applied quite 
> generally by many software practitioners, I reserve use of the term to 
> encompass fairly
> simple implementation errors. Bugs are implementation-level problems
> that
> can be easily discovered and remedied. See Chapter 1.
>
> Flaw-A design-level or architectural software defect. High-level 
> defects cause 50% of software security problems. See Chapter 1.
>
> In any case, I intend to still use these terms like this, and I would 
> be very pleased if you would all join me.
>
> gem
>
>
>
> ----------------------------------------------------------------------
> ------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




From crispin at novell.com  Thu Feb  2 17:12:49 2006
From: crispin at novell.com (Crispin Cowan)
Date: Thu, 02 Feb 2006 14:12:49 -0800
Subject: [SC-L] Bugs and flaws
In-Reply-To: <C0077D80.9CFD%jsteven@cigital.com>
References: <C0077D80.9CFD%jsteven@cigital.com>
Message-ID: <43E283E1.4070806@novell.com>

John Steven wrote:
> Re-reading my post, I realize that it came off as heavy support for
> additional terminology. Truth is, we've found that the easiest way to
> communicate this concept to our Consultants and Clients here at Cigital has
> been to build the two buckets (flaws and bugs).
>   
My main problem with this terminology is that I have only ever seen it
coming from Cigital people. The rest of the world seems to treat "flaw"
and "bug" as synonyms.

The distinction here is between "design flaw" and "implementation flaw".
There doesn't seem to be anything in these words that suggest one is
larger scale than the other.

>From dictionary.com we have:

flaw^1 <http://www.answers.com/flaw&r=67>(fl?) pronunciation
/n./

   1. An imperfection, often concealed, that impairs soundness: /a flaw
      in the crystal that caused it to shatter./ See synonyms at blemish
      <http://www.answers.com/main/ntquery;jsessionid=75e32c5vb2csr?method=4&dsid=1555&dekey=B0319900&gwp=8&curtab=1555_1&sbid=lc04b>.
   2. A defect or shortcoming in something intangible: /They share the
      character flaw of arrogance./
   3. A defect in a legal document that can render it invalid.

"Bug" <http://www.answers.com/bug&r=67> is a little more arcane, and the
only relevant part is far down the document where it discusses the
history with Grace Hopper:

    bug

    An unwanted and unintended property of a program or piece of
    hardware, esp. one that causes it to malfunction. Antonym of
    /feature/
    <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FF%2Ffeature.html&gwp=8&curtab=2291_1>.
    Examples: ?There's a bug in the editor: it writes things out
    backwards.? ?The system crashed because of a hardware bug.? ?Fred is
    a winner, but he has a few bugs? (i.e., Fred is a good guy, but he
    has a few personality problems).

    Historical note: Admiral Grace Hopper (an early computing pioneer
    better known for inventing /COBOL/
    <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FC%2FCOBOL.html&gwp=8&curtab=2291_1>)
    liked to tell a story in which a technician solved a /glitch/
    <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FG%2Fglitch.html&gwp=8&curtab=2291_1>
    in the Harvard Mark II machine by pulling an actual insect out from
    between the contacts of one of its relays, and she subsequently
    promulgated /bug/
    <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FB%2Fbug.html&gwp=8&curtab=2291_1>
    in its hackish sense as a joke about the incident (though, as she
    was careful to admit, she was not there when it happened). For many
    years the logbook associated with the incident and the actual bug in
    question (a moth) sat in a display case at the Naval Surface Warfare
    Center (NSWC). The entire story, with a picture of the logbook and
    the moth taped into it, is recorded in the /Annals of the History of
    Computing/, Vol. 3, No. 3 (July 1981), pp. 285--286.


> What I was really trying to present was that Security people could stand to
> be a bit more thorough about how they synthesize the results of their
> analysis before they communicate the vulnerabilities they've found, and what
> mitigating strategies they suggest.
>   
Definitely. I think there is a deep cultural problem that people who fix
bugs or flaws tend to over-focus on the micro issue, fixing the specific
coding vulnerability, and ignore the larger architectural error that
allows the coding defect to be exploitable and cause damage. In the case
at hand, the WMF bug would be much less dangerous if there were not so
many ways to induce IE to invoke WMF decoding without asking the user.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption



From Ken at krvw.com  Thu Feb  2 18:55:56 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Thu, 2 Feb 2006 18:55:56 -0500
Subject: [SC-L] Administrative: whitelisting on SC-L
Message-ID: <200602021855.56542@KRvW>

Hi SC-L folks:

I don't mean to intrude in the "bug and flaw" debate, but I do want to make 
sure that you're all aware of the whitelisting that I'm doing on the list 
these days, since I switched the list management from Majordomo to Mailman.  

Specifically, in order to cut down on spam, I have Mailman set to drop any 
posting sent from _any_ address that is not explicitly subscribed to the 
list.  That means, for example, if you subscribe via an email exploder or 
alias at your site, that your submissions get automatically /dev/nulled.

The solution, for anyone that wants to post and is subscribed similarly to the 
above scenario, is to subscribe your personal address and set it to NOT 
receive SC-L postings.  That way, your mail alias/exploder will continue to 
function as you set it up, AND you'll be able to post.

Since I get ZERO notification when messages (mostly spam) are dropped by the 
whitelist, I have no way of knowing who is in this situation.  So, if you 
want the ability to post, drop me a note and I'll be happy to set you up with 
a no-mail subscription.  (Don't worry, you won't/shouldn't get duplicates.)

Cheers,

Ken van Wyk
SC-L Moderator


From jeff.williams at aspectsecurity.com  Thu Feb  2 19:12:32 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Thu, 2 Feb 2006 19:12:32 -0500
Subject: [SC-L] Bugs and flaws
In-Reply-To: <43E13121.9060804@novell.com>
Message-ID: <007501c62856$8719c7b0$ea04a8c0@intranet.aspectsecurity.com>

At the risk of piling on here, there's no question that it's critical to
consider security problems across the continuum. While we're at it, the
analysis should start back even further with the requirements or even the
whole system concept.

All of the representations across the continuum (rqmts, arch, design, code)
are just models of the same thing.  They start more abstract and end up as
code.  A *single* problem could exist in all these models at the same time.

Higher-level representations of systems are generally eclipsed by lower
level ones fairly rapidly.  For example, it's a rare group that updates
their design docs as implementation progresses. So once you've got code, the
architecture-flaws don't come from architecture documents (which lie). The
best place to look for them (if you want truth) is to look in the code.

To me, the important thing here is to give software teams good advice about
the level of effort they're going to have to put into fixing a problem. If
it helps to give a security problem a label to let them know they're going
to have to go back to the drawing board, I think saying 'architecture-flaw'
or 'design-flaw' is fine. But I agree with others that saying 'flaw' alone
doesn't help distinguish it from 'bug' in the minds of most developers or
architects.

--Jeff

Jeff Williams, CEO
Aspect Security
http://www.aspectsecurity.com


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Crispin Cowan
Sent: Wednesday, February 01, 2006 5:07 PM
To: John Steven
Cc: Will Kruse; Secure Coding Mailing List
Subject: Re: [SC-L] Bugs and flaws

John Steven wrote:
> I'm not sure there's any value in discussing this minutia further, but
here
> goes:
>   
We'll let the moderator decide that :)

> 1) Crispin, I think you've nailed one thing. The continuum from:
>
> Architecture --> Design --> Low-level Design --> (to) Implementation
>
> is a blurry one, and certainly slippery as you move from 'left' to
'right'.
>   
Cool.

> But, we all should understand that there's commensurate blur in our
analysis
> techniques (aka architecture and code review) to assure that as we sweep
> over software that we uncover both bugs and architectural flaws.
>   
Also agreed.

> 2) Flaws are different in important ways bugs when it comes to
presentation,
> prioritization, and mitigation. Let's explore by physical analog first.
>   
I disagree with the word usage. To me, "bug" and "flaw" are exactly
synonyms. The distinction being drawn here is between "implementation
flaws" vs. "design flaws". You are just creating confusing jargon to
claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect
::= bug. A vulnerability is a special subset of flaws/defects/bugs that
has the property of being exploitable.

> I nearly fell through one of my consultant's tables as I leaned on it this
> morning. We explored: "Bug or flaw?".
>   
The wording issue aside, at the implementation level you try to
code/implement to prevent flaws, by doing things such as using higher
quality steel (for bolts) and good coding practices (for software). At
the design level, you try to design so as to *mask* flaws by avoiding
single points of failure, doing things such as using 2 bolts (for
tables) and using access controls to limit privilege escalation (for
software).

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php



From brian at fortifysoftware.com  Thu Feb  2 20:51:37 2006
From: brian at fortifysoftware.com (Brian Chess)
Date: Thu, 02 Feb 2006 17:51:37 -0800
Subject: [SC-L] Bugs and flaws
Message-ID: <C007F729.D623%brian@fortifysoftware.com>

I spent Phase One of both my academic and professional careers
working on hardware fault models and design for testability.
In fact, the first static analysis tool I wrote was for hardware:
it analyzed Verilog looking for design mistakes that would make
it difficult or impossible to perform design verification or to
apply adequate manufacturing tests.  Some observations:

- The hardware guys are indeed ahead.  Chip designers budget for
test and verification from day one.  They also do a fair amount
of thinking about what's going to go wrong.  Somebody's going to
give you 5 volts instead of 3.3 volts.  What's going to happen?
The transistors are going to switch at a different rate when the
chip is cold.  What's going to happen?  A speck of dust is going
to fall on the wafer between the time the metal 2 layer goes down
and the time the metal 3 layer goes down.  What's going to happen?

- The difference between a manufacturing defect and a design
defect is not always immediately obvious.  Maybe two wires got
bridged because a piece of dust fell in exactly the right spot.
Maybe two wires got bridged because you made a mistake in your
process physics and you need 50 nm of tolerance instead of 0.5 nm.
You'd better figure it out before you go into full-swing
manufacturing, or big batches of defective chips could kill your
profit margins and drive your customers away at the same time.
For that reason, diagnosing the cause of failure is an important
topic.

Brian

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On
Behalf Of Chris Wysopal
Sent: 02 February 2006 21:35
To: Gary McGraw
Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws



In the manufacturing world, which is far more mature than the software
development world, they use the terminology of "design defect" and
"manufacturing defect".  So this distinction is useful and has stood the
test of
time.

Flaw and defect are synonymous. We should just pick one. You could say that
the
term for manufacturing software is "implementation".

So why do we need to change the terms for the software world?  Wouldn't
"design
defect" and "implementation defect" be clearer and more in line with the
manufacturing quality discipline, which the software quality discipline
should
be working towards emulating. (When do we get to Six
Sigma?)

I just don't see the usefulness of calling a "design defect" a "flaw".
"Flaw" by
itself is overloaded.  And in the software world, "bug" can mean an
implementation or design problem, so "bug" alone is overloaded for
describing an
implementation defect.

At @stake the Application Center of Excellence used the terminology "design
flaw" and "implementation flaw".  It well understood by our customers.

As Crispin said in an earlier post on the subject, the line is sometimes
blurry.
I am sure this is the case in manufacturing too.  Architecture flaws can be
folded into the design flaw category for simplicity.

My vote is for a less overloaded and clearer terminology.

-Chris

P.S. My father managed a non-destructive test lab at a jet engine
manufacturer.
They had about the highest quality requirements in the world. So for many
hours
I was regaled with tales about the benefits of performing static analysis on
individual components early in the manufacturing cycle.

They would dip cast parts in a fluorescent liquid and look at them under
ultraviolet light to illuminate cracks caused during casting process. For
critical parts which would receive more stress, such as the fan blades, they
would x-ray each part to inspect for internal cracks. A more expensive
process
but warranted due to the increased risk of total system failure for a defect
in
those parts.

The static testing was obviously much cheaper and delivered better quality
than
just bolting the parts together and doing dynamic testing in a test cell.
It's
a wonder that it has taken the software security world so long to catch onto
the
benefits of static testing of implementation.  I think we can learn a lot
more
from the manufacturing world.

On Thu, 2 Feb 2006, Gary McGraw wrote:

> Hi all,
>
> When I introduced the "bugs" and "flaws" nomenclature into the
> literature, I did so in an article about the software security
> workshop I chaired in 2003 (see http://www.cigital.com/ssw/).  This
> was ultimately written up in an "On the Horizon" paper published by
> IEEE Security & Privacy.
>
> Nancy Mead and I queried the SWEBOK and looked around to see if the
> new usage caused collision.  It did not.  The reason I think it is
> important to distinguish the two ends of the rather slippery range
> (crispy is right about that) is that software security as a field is
> not paying enough attention to architecture.  By identifying flaws as
> a subcategory of defects (according the the SWEBOK), we can focus some
> attention on the problem.
>
> >>From the small glossary in "Software Security" (my new book out
> tomorrow):
>
> Bug-A bug is an implementation-level software problem. Bugs may exist
> in code but never be executed. Though the term bug is applied quite
> generally by many software practitioners, I reserve use of the term to
> encompass fairly
> simple implementation errors. Bugs are implementation-level problems
> that
> can be easily discovered and remedied. See Chapter 1.
>
> Flaw-A design-level or architectural software defect. High-level
> defects cause 50% of software security problems. See Chapter 1.
>
> In any case, I intend to still use these terms like this, and I would
> be very pleased if you would all join me.
>
> gem
>
>
>



From gem at cigital.com  Thu Feb  2 20:49:37 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 2 Feb 2006 20:49:37 -0500
Subject: [SC-L] Bugs and flaws
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F173B@va-mail.cigital.com>

I'm sorry, but it is just not possible to find design flaws by staring at code.

gem

 -----Original Message-----
From: 	Jeff Williams [mailto:jeff.williams at aspectsecurity.com]
Sent:	Thu Feb 02 20:32:29 2006
To:	'Secure Coding Mailing List'
Subject:	RE: [SC-L] Bugs and flaws

At the risk of piling on here, there's no question that it's critical to
consider security problems across the continuum. While we're at it, the
analysis should start back even further with the requirements or even the
whole system concept.

All of the representations across the continuum (rqmts, arch, design, code)
are just models of the same thing.  They start more abstract and end up as
code.  A *single* problem could exist in all these models at the same time.

Higher-level representations of systems are generally eclipsed by lower
level ones fairly rapidly.  For example, it's a rare group that updates
their design docs as implementation progresses. So once you've got code, the
architecture-flaws don't come from architecture documents (which lie). The
best place to look for them (if you want truth) is to look in the code.

To me, the important thing here is to give software teams good advice about
the level of effort they're going to have to put into fixing a problem. If
it helps to give a security problem a label to let them know they're going
to have to go back to the drawing board, I think saying 'architecture-flaw'
or 'design-flaw' is fine. But I agree with others that saying 'flaw' alone
doesn't help distinguish it from 'bug' in the minds of most developers or
architects.

--Jeff

Jeff Williams, CEO
Aspect Security
http://www.aspectsecurity.com


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Crispin Cowan
Sent: Wednesday, February 01, 2006 5:07 PM
To: John Steven
Cc: Will Kruse; Secure Coding Mailing List
Subject: Re: [SC-L] Bugs and flaws

John Steven wrote:
> I'm not sure there's any value in discussing this minutia further, but
here
> goes:
>   
We'll let the moderator decide that :)

> 1) Crispin, I think you've nailed one thing. The continuum from:
>
> Architecture --> Design --> Low-level Design --> (to) Implementation
>
> is a blurry one, and certainly slippery as you move from 'left' to
'right'.
>   
Cool.

> But, we all should understand that there's commensurate blur in our
analysis
> techniques (aka architecture and code review) to assure that as we sweep
> over software that we uncover both bugs and architectural flaws.
>   
Also agreed.

> 2) Flaws are different in important ways bugs when it comes to
presentation,
> prioritization, and mitigation. Let's explore by physical analog first.
>   
I disagree with the word usage. To me, "bug" and "flaw" are exactly
synonyms. The distinction being drawn here is between "implementation
flaws" vs. "design flaws". You are just creating confusing jargon to
claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect
::= bug. A vulnerability is a special subset of flaws/defects/bugs that
has the property of being exploitable.

> I nearly fell through one of my consultant's tables as I leaned on it this
> morning. We explored: "Bug or flaw?".
>   
The wording issue aside, at the implementation level you try to
code/implement to prevent flaws, by doing things such as using higher
quality steel (for bolts) and good coding practices (for software). At
the design level, you try to design so as to *mask* flaws by avoiding
single points of failure, doing things such as using 2 bolts (for
tables) and using access controls to limit privilege escalation (for
software).

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From jeff.williams at aspectsecurity.com  Thu Feb  2 20:59:18 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Thu, 2 Feb 2006 20:59:18 -0500
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F173B@va-mail.cigital.com>
Message-ID: <00f301c62865$71e3a4b0$ea04a8c0@intranet.aspectsecurity.com>

Um, so if there is no documentation you can't find design flaws?

--Jeff

-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com] 
Sent: Thursday, February 02, 2006 8:50 PM
To: Jeff Williams; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws

I'm sorry, but it is just not possible to find design flaws by staring at
code.

gem

 -----Original Message-----
From: 	Jeff Williams [mailto:jeff.williams at aspectsecurity.com]
Sent:	Thu Feb 02 20:32:29 2006
To:	'Secure Coding Mailing List'
Subject:	RE: [SC-L] Bugs and flaws

At the risk of piling on here, there's no question that it's critical to
consider security problems across the continuum. While we're at it, the
analysis should start back even further with the requirements or even the
whole system concept.

All of the representations across the continuum (rqmts, arch, design, code)
are just models of the same thing.  They start more abstract and end up as
code.  A *single* problem could exist in all these models at the same time.

Higher-level representations of systems are generally eclipsed by lower
level ones fairly rapidly.  For example, it's a rare group that updates
their design docs as implementation progresses. So once you've got code, the
architecture-flaws don't come from architecture documents (which lie). The
best place to look for them (if you want truth) is to look in the code.

To me, the important thing here is to give software teams good advice about
the level of effort they're going to have to put into fixing a problem. If
it helps to give a security problem a label to let them know they're going
to have to go back to the drawing board, I think saying 'architecture-flaw'
or 'design-flaw' is fine. But I agree with others that saying 'flaw' alone
doesn't help distinguish it from 'bug' in the minds of most developers or
architects.

--Jeff

Jeff Williams, CEO
Aspect Security
http://www.aspectsecurity.com


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Crispin Cowan
Sent: Wednesday, February 01, 2006 5:07 PM
To: John Steven
Cc: Will Kruse; Secure Coding Mailing List
Subject: Re: [SC-L] Bugs and flaws

John Steven wrote:
> I'm not sure there's any value in discussing this minutia further, but
here
> goes:
>   
We'll let the moderator decide that :)

> 1) Crispin, I think you've nailed one thing. The continuum from:
>
> Architecture --> Design --> Low-level Design --> (to) Implementation
>
> is a blurry one, and certainly slippery as you move from 'left' to
'right'.
>   
Cool.

> But, we all should understand that there's commensurate blur in our
analysis
> techniques (aka architecture and code review) to assure that as we sweep
> over software that we uncover both bugs and architectural flaws.
>   
Also agreed.

> 2) Flaws are different in important ways bugs when it comes to
presentation,
> prioritization, and mitigation. Let's explore by physical analog first.
>   
I disagree with the word usage. To me, "bug" and "flaw" are exactly
synonyms. The distinction being drawn here is between "implementation
flaws" vs. "design flaws". You are just creating confusing jargon to
claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect
::= bug. A vulnerability is a special subset of flaws/defects/bugs that
has the property of being exploitable.

> I nearly fell through one of my consultant's tables as I leaned on it this
> morning. We explored: "Bug or flaw?".
>   
The wording issue aside, at the implementation level you try to
code/implement to prevent flaws, by doing things such as using higher
quality steel (for bolts) and good coding practices (for software). At
the design level, you try to design so as to *mask* flaws by avoiding
single points of failure, doing things such as using 2 bolts (for
tables) and using access controls to limit privilege escalation (for
software).

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Thu Feb  2 21:05:51 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 2 Feb 2006 21:05:51 -0500
Subject: [SC-L] Bugs and flaws
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F173C@va-mail.cigital.com>

Not unless you talk to the designer.  You might get lucky and find a design problem or two by looking at code, but that usually doesn't work.

That's not to say that all systems have adequate documentation about design (not to mention requirements that you correctly cited before)!  They don't.  When they don't, you have to try to construct them.  Doing them from code is very difficult at best.

gem

 -----Original Message-----
From: 	Jeff Williams [mailto:jeff.williams at aspectsecurity.com]
Sent:	Thu Feb 02 20:59:14 2006
To:	Gary McGraw; 'Secure Coding Mailing List'
Subject:	RE: [SC-L] Bugs and flaws

Um, so if there is no documentation you can't find design flaws?

--Jeff

-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com] 
Sent: Thursday, February 02, 2006 8:50 PM
To: Jeff Williams; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws

I'm sorry, but it is just not possible to find design flaws by staring at
code.

gem

 -----Original Message-----
From: 	Jeff Williams [mailto:jeff.williams at aspectsecurity.com]
Sent:	Thu Feb 02 20:32:29 2006
To:	'Secure Coding Mailing List'
Subject:	RE: [SC-L] Bugs and flaws

At the risk of piling on here, there's no question that it's critical to
consider security problems across the continuum. While we're at it, the
analysis should start back even further with the requirements or even the
whole system concept.

All of the representations across the continuum (rqmts, arch, design, code)
are just models of the same thing.  They start more abstract and end up as
code.  A *single* problem could exist in all these models at the same time.

Higher-level representations of systems are generally eclipsed by lower
level ones fairly rapidly.  For example, it's a rare group that updates
their design docs as implementation progresses. So once you've got code, the
architecture-flaws don't come from architecture documents (which lie). The
best place to look for them (if you want truth) is to look in the code.

To me, the important thing here is to give software teams good advice about
the level of effort they're going to have to put into fixing a problem. If
it helps to give a security problem a label to let them know they're going
to have to go back to the drawing board, I think saying 'architecture-flaw'
or 'design-flaw' is fine. But I agree with others that saying 'flaw' alone
doesn't help distinguish it from 'bug' in the minds of most developers or
architects.

--Jeff

Jeff Williams, CEO
Aspect Security
http://www.aspectsecurity.com


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Crispin Cowan
Sent: Wednesday, February 01, 2006 5:07 PM
To: John Steven
Cc: Will Kruse; Secure Coding Mailing List
Subject: Re: [SC-L] Bugs and flaws

John Steven wrote:
> I'm not sure there's any value in discussing this minutia further, but
here
> goes:
>   
We'll let the moderator decide that :)

> 1) Crispin, I think you've nailed one thing. The continuum from:
>
> Architecture --> Design --> Low-level Design --> (to) Implementation
>
> is a blurry one, and certainly slippery as you move from 'left' to
'right'.
>   
Cool.

> But, we all should understand that there's commensurate blur in our
analysis
> techniques (aka architecture and code review) to assure that as we sweep
> over software that we uncover both bugs and architectural flaws.
>   
Also agreed.

> 2) Flaws are different in important ways bugs when it comes to
presentation,
> prioritization, and mitigation. Let's explore by physical analog first.
>   
I disagree with the word usage. To me, "bug" and "flaw" are exactly
synonyms. The distinction being drawn here is between "implementation
flaws" vs. "design flaws". You are just creating confusing jargon to
claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect
::= bug. A vulnerability is a special subset of flaws/defects/bugs that
has the property of being exploitable.

> I nearly fell through one of my consultant's tables as I leaned on it this
> morning. We explored: "Bug or flaw?".
>   
The wording issue aside, at the implementation level you try to
code/implement to prevent flaws, by doing things such as using higher
quality steel (for bolts) and good coding practices (for software). At
the design level, you try to design so as to *mask* flaws by avoiding
single points of failure, doing things such as using 2 bolts (for
tables) and using access controls to limit privilege escalation (for
software).

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------





----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From jeff.williams at aspectsecurity.com  Thu Feb  2 21:21:49 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Thu, 2 Feb 2006 21:21:49 -0500
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F173C@va-mail.cigital.com>
Message-ID: <00f701c62868$974a8130$ea04a8c0@intranet.aspectsecurity.com>

That's not my experience. I believe there are many design problems you can
find more quickly and, more importantly, accurately by using the code. I
find this to be true even when there is a documented design -- but there's
no question in the case where all you have is code.

In fact, if the design isn't fairly obvious in the code, then that's a
security problem in itself. Unless it's clear, developers won't understand
it and will make more mistakes.

Static analysis tools can help a lot here. Used properly, they can provide
design-level insight into a software baseline. The huge advantage is that
it's correct.

--Jeff 

-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com] 
Sent: Thursday, February 02, 2006 9:06 PM
To: jeff.williams at aspectsecurity.com; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws

Not unless you talk to the designer.  You might get lucky and find a design
problem or two by looking at code, but that usually doesn't work.

That's not to say that all systems have adequate documentation about design
(not to mention requirements that you correctly cited before)!  They don't.
When they don't, you have to try to construct them.  Doing them from code is
very difficult at best.

gem

 -----Original Message-----
From: 	Jeff Williams [mailto:jeff.williams at aspectsecurity.com]
Sent:	Thu Feb 02 20:59:14 2006
To:	Gary McGraw; 'Secure Coding Mailing List'
Subject:	RE: [SC-L] Bugs and flaws

Um, so if there is no documentation you can't find design flaws?

--Jeff

-----Original Message-----
From: Gary McGraw [mailto:gem at cigital.com] 
Sent: Thursday, February 02, 2006 8:50 PM
To: Jeff Williams; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws

I'm sorry, but it is just not possible to find design flaws by staring at
code.

gem

 -----Original Message-----
From: 	Jeff Williams [mailto:jeff.williams at aspectsecurity.com]
Sent:	Thu Feb 02 20:32:29 2006
To:	'Secure Coding Mailing List'
Subject:	RE: [SC-L] Bugs and flaws

At the risk of piling on here, there's no question that it's critical to
consider security problems across the continuum. While we're at it, the
analysis should start back even further with the requirements or even the
whole system concept.

All of the representations across the continuum (rqmts, arch, design, code)
are just models of the same thing.  They start more abstract and end up as
code.  A *single* problem could exist in all these models at the same time.

Higher-level representations of systems are generally eclipsed by lower
level ones fairly rapidly.  For example, it's a rare group that updates
their design docs as implementation progresses. So once you've got code, the
architecture-flaws don't come from architecture documents (which lie). The
best place to look for them (if you want truth) is to look in the code.

To me, the important thing here is to give software teams good advice about
the level of effort they're going to have to put into fixing a problem. If
it helps to give a security problem a label to let them know they're going
to have to go back to the drawing board, I think saying 'architecture-flaw'
or 'design-flaw' is fine. But I agree with others that saying 'flaw' alone
doesn't help distinguish it from 'bug' in the minds of most developers or
architects.

--Jeff

Jeff Williams, CEO
Aspect Security
http://www.aspectsecurity.com


-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Crispin Cowan
Sent: Wednesday, February 01, 2006 5:07 PM
To: John Steven
Cc: Will Kruse; Secure Coding Mailing List
Subject: Re: [SC-L] Bugs and flaws

John Steven wrote:
> I'm not sure there's any value in discussing this minutia further, but
here
> goes:
>   
We'll let the moderator decide that :)

> 1) Crispin, I think you've nailed one thing. The continuum from:
>
> Architecture --> Design --> Low-level Design --> (to) Implementation
>
> is a blurry one, and certainly slippery as you move from 'left' to
'right'.
>   
Cool.

> But, we all should understand that there's commensurate blur in our
analysis
> techniques (aka architecture and code review) to assure that as we sweep
> over software that we uncover both bugs and architectural flaws.
>   
Also agreed.

> 2) Flaws are different in important ways bugs when it comes to
presentation,
> prioritization, and mitigation. Let's explore by physical analog first.
>   
I disagree with the word usage. To me, "bug" and "flaw" are exactly
synonyms. The distinction being drawn here is between "implementation
flaws" vs. "design flaws". You are just creating confusing jargon to
claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect
::= bug. A vulnerability is a special subset of flaws/defects/bugs that
has the property of being exploitable.

> I nearly fell through one of my consultant's tables as I leaned on it this
> morning. We explored: "Bug or flaw?".
>   
The wording issue aside, at the implementation level you try to
code/implement to prevent flaws, by doing things such as using higher
quality steel (for bolts) and good coding practices (for software). At
the design level, you try to design so as to *mask* flaws by avoiding
single points of failure, doing things such as using 2 bolts (for
tables) and using access controls to limit privilege escalation (for
software).

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------





----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From weld at vulnwatch.org  Thu Feb  2 23:17:34 2006
From: weld at vulnwatch.org (Chris Wysopal)
Date: Thu, 2 Feb 2006 23:17:34 -0500 (EST)
Subject: [SC-L] Bugs and flaws
In-Reply-To: <028401c6284b$0161c240$cb00000a@escheradmin>
References: <028401c6284b$0161c240$cb00000a@escheradmin>
Message-ID: <Pine.BSO.4.55.0602022236460.9430@vikki.vulnwatch.org>


In the manufacturing world, manufacturing defects are defects that were
not intended by the design. With software, an implementation defect is a
defect that is not indended by the design.  That is where I see the
analogy. A factory worker forgetting to put on a washer or installing a
polarized capacitor backwards is similar to a programmer neglecting to
check a return code or being off by one in a length calculation.

In both disciplines, to increase quality you could say "don't do that",
you could add a quality process that tests for the correct implementation,
or best, you could make it impossible for the mistake to happen. So I
guess I see a lot of similarities between the manufacturing process and
the software implementation process.

Sure its not a perfect analogy.  Nothing seems to be between the physical
and digital worlds.  As you say, many of the flaws created during what is
traditionally known as implementation are low-level design errors but at
the very end of the continuum they are simply mistakes.

-Chris


On Thu, 2 Feb 2006, David Crocker wrote:

> I don't think this analogy between software development and
> manufacturing holds. There are no "manufacturing defects" in software
> construction, unless one counts a buggy chip (e.g. Pentium FPU or
> similar) or perhaps a buggy compiler. Software instructions execute
> predictably and are not subject to the problems of defective materials,
> difficulties in keeping dimensions within a precise tolerance, or wear
> and tear.
>
> If some small bolt in my car fails because the bolt met its
> manufacturer's specification but was not strong enough to withstand the
> loads it was subjected to, that is a low-level design error, not a
> manufacturing error. Similarly, I view coding errors as low-level design
> errors.
>
> David Crocker, Escher Technologies Ltd.
> Consultancy, contracting and tools for dependable software development
> www.eschertech.com
>
>
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On
> Behalf Of Chris Wysopal
> Sent: 02 February 2006 21:35
> To: Gary McGraw
> Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List
> Subject: RE: [SC-L] Bugs and flaws
>
>
>
> In the manufacturing world, which is far more mature than the software
> development world, they use the terminology of "design defect" and
> "manufacturing defect".  So this distinction is useful and has stood the test of
> time.
>
> Flaw and defect are synonymous. We should just pick one. You could say that the
> term for manufacturing software is "implementation".
>
> So why do we need to change the terms for the software world?  Wouldn't "design
> defect" and "implementation defect" be clearer and more in line with the
> manufacturing quality discipline, which the software quality discipline should
> be working towards emulating. (When do we get to Six
> Sigma?)
>
> I just don't see the usefulness of calling a "design defect" a "flaw". "Flaw" by
> itself is overloaded.  And in the software world, "bug" can mean an
> implementation or design problem, so "bug" alone is overloaded for describing an
> implementation defect.
>
> At @stake the Application Center of Excellence used the terminology "design
> flaw" and "implementation flaw".  It well understood by our customers.
>
> As Crispin said in an earlier post on the subject, the line is sometimes blurry.
> I am sure this is the case in manufacturing too.  Architecture flaws can be
> folded into the design flaw category for simplicity.
>
> My vote is for a less overloaded and clearer terminology.
>
> -Chris
>
> P.S. My father managed a non-destructive test lab at a jet engine manufacturer.
> They had about the highest quality requirements in the world. So for many hours
> I was regaled with tales about the benefits of performing static analysis on
> individual components early in the manufacturing cycle.
>
> They would dip cast parts in a fluorescent liquid and look at them under
> ultraviolet light to illuminate cracks caused during casting process. For
> critical parts which would receive more stress, such as the fan blades, they
> would x-ray each part to inspect for internal cracks. A more expensive process
> but warranted due to the increased risk of total system failure for a defect in
> those parts.
>
> The static testing was obviously much cheaper and delivered better quality than
> just bolting the parts together and doing dynamic testing in a test cell.  It's
> a wonder that it has taken the software security world so long to catch onto the
> benefits of static testing of implementation.  I think we can learn a lot more
> from the manufacturing world.
>
> On Thu, 2 Feb 2006, Gary McGraw wrote:
>
> > Hi all,
> >
> > When I introduced the "bugs" and "flaws" nomenclature into the
> > literature, I did so in an article about the software security
> > workshop I chaired in 2003 (see http://www.cigital.com/ssw/).  This
> > was ultimately written up in an "On the Horizon" paper published by
> > IEEE Security & Privacy.
> >
> > Nancy Mead and I queried the SWEBOK and looked around to see if the
> > new usage caused collision.  It did not.  The reason I think it is
> > important to distinguish the two ends of the rather slippery range
> > (crispy is right about that) is that software security as a field is
> > not paying enough attention to architecture.  By identifying flaws as
> > a subcategory of defects (according the the SWEBOK), we can focus some
> > attention on the problem.
> >
> > >>From the small glossary in "Software Security" (my new book out
> > tomorrow):
> >
> > Bug-A bug is an implementation-level software problem. Bugs may exist
> > in code but never be executed. Though the term bug is applied quite
> > generally by many software practitioners, I reserve use of the term to
> > encompass fairly
> > simple implementation errors. Bugs are implementation-level problems
> > that
> > can be easily discovered and remedied. See Chapter 1.
> >
> > Flaw-A design-level or architectural software defect. High-level
> > defects cause 50% of software security problems. See Chapter 1.
> >
> > In any case, I intend to still use these terms like this, and I would
> > be very pleased if you would all join me.
> >
> > gem
> >
> >
> >
> > ----------------------------------------------------------------------
> > ------
> > This electronic message transmission contains information that may be
> > confidential or privileged.  The information contained herein is intended
> > solely for the recipient and use by any other party is not authorized.  If
> > you are not the intended recipient (or otherwise authorized to receive this
> > message by the intended recipient), any disclosure, copying, distribution or
> > use of the contents of the information is prohibited.  If you have received
> > this electronic message transmission in error, please contact the sender by
> > reply email and delete all copies of this message.  Cigital, Inc. accepts no
> > responsibility for any loss or damage resulting directly or indirectly from
> > the use of this email or its contents.
> > Thank You.
> > ----------------------------------------------------------------------------
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org
> > List information, subscriptions, etc -
> > http://krvw.com/mailman/listinfo/sc-l
> > List charter available at - http://www.securecoding.org/list/charter.php
> >
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>


From BlueBoar at thievco.com  Thu Feb  2 23:56:39 2006
From: BlueBoar at thievco.com (Blue Boar)
Date: Thu, 02 Feb 2006 20:56:39 -0800
Subject: [SC-L] Bugs and flaws
In-Reply-To: <028401c6284b$0161c240$cb00000a@escheradmin>
References: <028401c6284b$0161c240$cb00000a@escheradmin>
Message-ID: <43E2E287.3020902@thievco.com>

David Crocker wrote:
> I don't think this analogy between software development and manufacturing holds.
> There are no "manufacturing defects" in software construction

For software:
A design defect is when you correctly implement what you wanted, and you 
wanted the wrong thing.  A "manufacturing defect" is when you 
incorrectly implement what you wanted.

						BB


From jsteven at cigital.com  Fri Feb  3 00:04:53 2006
From: jsteven at cigital.com (John Steven)
Date: Fri, 03 Feb 2006 00:04:53 -0500
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F173B@va-mail.cigital.com>
Message-ID: <C0084EA5.9D4C%jsteven@cigital.com>

Ah,

The age-old Gary vs. jOHN debate. I do believe along the continuum of
architecture-->design-->impl. that I've shown the ability to discern flawed
design from source code in source code reviews.

Cigital guys reading this thread have an advantage in that they know both
the shared and exclusive activities defined as part of our architectural and
code review processes. The bottom line is this: as you look at source code,
given enough gift for architecture, you can identify _some_ of the design
(whether intended or implemented) from the implementation, and find _some_
flaws. Before you get wound up and say, "Maybe you jOHN" tongue fully
in-cheek, the Struts example I gave is one case. Looking at a single class
file (the privileged Servlet definition), you can determine that the Lead
Developer/Architect has not paid enough attention to authorization when
he/she designed how the application's functionality was organized.
Admittedly, _some_ (other) architectural flaws do demand attention paid only
through activities confined to architectural analysis--not code review.
 
Think back again to my original email. The situations I present (both with
the physical table and Struts) present a 'mistake' (IEEE parlance) that can
manifest itself in terms of both an architectural flaw and implementation
bug (Cigital parlance).

I believe that the concept that Jeff (Payne), Cowan, Wysopal, and even
Peterson (if you bend it correctly) present is that the 'mistake' may
cross-cut the SDLC--manifesting itself in each of the phases' artifacts. IE:
If the mistake was in requirements, it will manifest itself in design
deficiency (flaw), as well as in the implementation (bug).

Jeff (Williams) indicates that, since progress roles downstream in the SDLC,
you _could_ fix the 'mistake' in any of the phases it manifests itself, but
that an efficiency argument demands you look in the code. I implore the
reader recall my original email. I mention that when characterized as a bug,
the level of effort required to fix the 'mistake' is probably less than if
it's characterized as a flaw. However, in doing so, you may miss other
instances of the mistake throughout the code.

I whole-heartedly agree with Jeff (Williams) that:

1) Look to the docs. for the 'right' answer.
2) Look to the code for the 'truth'.
3) Look to the deployed bins. for 'God's Truth'.
 
The variance in these artifacts is a key element in Cigital's architectural
analysis.

Second, (a point I made in my original email) the objective is to give the
most practical advise as possible to developers for fixing the problem. I'll
just copy-paste it from the original:
-----
Summarizing, my characterization of a vulnerability as a bug or a flaw has
important implications towards how it's mitigated. In the case of the Struts
example, the bug-based fix is easiest--but in so characterizing the problem
I may (or may not) miss other instances of this vulnerability within the
application's code base.

How do I know how to characterize a vulnerability along the continuum of
bugs-->flaws?  I don't know for sure, but I've taken to using my experience
over a number of assessments to "upcast" typically endemic problems as flaws
(and solve them in the design or architecture) and "downcast" those problems
that have glaring quick-fixes. In circumstances where both those heuristics
apply, I suggest a tactical fix to the bug, while prescribing that further
analysis take the tack of further fleshing out the flaw.
-----

Where my opinion differs from the other posters is this: I believe:
"Where a 'mistake' manifests itself in multiple phases of the software
development lifecycle, you're most apt to completely MITIGATE its effects by
characterizing it as early in the lifecycle as possible, as design or even
requirements. As Williams indicates, to the contrary, you may FIND the
problem most easily later in the lifecycle. Perhaps in the code itself."

Look, 
McGraw put forth the 'bug' and 'flaw' nomenclature. It's useful because
there is value in explicitly pinning the vulnerability in architecture,
design, or code if it helps the dev. org. get things sorted out securely and
throughout their application. My experience is that this value is real.

The message of the  'defect'/'mistake' purist resonates with me as well:
it's all simply a mistake some human made along the path of developing the
application. But! I can assure you, to the extent that root-cause analysis
is valuable, telling a dev. team where to most effectively contend with a
vulnerability is also valuable.

In other words, "smart guys will always find the problems--by hook, or by
crook--but it takes classification to aid in efficient and thorough
mitigation".
 
-----
John Steven        
Principal, Software Security Group
Technical Director, Office of the CTO
703 404 5726 - Direct | 703 727 4034 - Cell
Cigital Inc.          | jsteven at cigital.com

4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908


> From: Gary McGraw <gem at cigital.com>
> 
> I'm sorry, but it is just not possible to find design flaws by staring at
> code.
> 
>  -----Original Message-----
> From:  Jeff Williams [mailto:jeff.williams at aspectsecurity.com]
> 
> At the risk of piling on here, there's no question that it's critical to
> consider security problems across the continuum. While we're at it, the
> analysis should start back even further with the requirements or even the
> whole system concept.
> 
> All of the representations across the continuum (rqmts, arch, design, code)
> are just models of the same thing.  They start more abstract and end up as
> code.  A *single* problem could exist in all these models at the same time.
> 
> Higher-level representations of systems are generally eclipsed by lower
> level ones fairly rapidly.  For example, it's a rare group that updates
> their design docs as implementation progresses. So once you've got code, the
> architecture-flaws don't come from architecture documents (which lie). The
> best place to look for them (if you want truth) is to look in the code.
> 
> To me, the important thing here is to give software teams good advice about
> the level of effort they're going to have to put into fixing a problem. If
> it helps to give a security problem a label to let them know they're going
> to have to go back to the drawing board, I think saying 'architecture-flaw'
> or 'design-flaw' is fine. But I agree with others that saying 'flaw' alone
> doesn't help distinguish it from 'bug' in the minds of most developers or
> architects.
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> 
> John Steven wrote:
>> I'm not sure there's any value in discussing this minutia further, but
> here
>> goes:
>>   
> We'll let the moderator decide that :)
> 
>> 1) Crispin, I think you've nailed one thing. The continuum from:
>> 
>> Architecture --> Design --> Low-level Design --> (to) Implementation
>> 
>> is a blurry one, and certainly slippery as you move from 'left' to
> 'right'.
>>   
> Cool.
> 
>> But, we all should understand that there's commensurate blur in our
> analysis
>> techniques (aka architecture and code review) to assure that as we sweep
>> over software that we uncover both bugs and architectural flaws.
>>   
> Also agreed.
> 
>> 2) Flaws are different in important ways bugs when it comes to
> presentation,
>> prioritization, and mitigation. Let's explore by physical analog first.
>>   
> I disagree with the word usage. To me, "bug" and "flaw" are exactly
> synonyms. The distinction being drawn here is between "implementation
> flaws" vs. "design flaws". You are just creating confusing jargon to
> claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect
> ::= bug. A vulnerability is a special subset of flaws/defects/bugs that
> has the property of being exploitable.
> 
>> I nearly fell through one of my consultant's tables as I leaned on it this
>> morning. We explored: "Bug or flaw?".
>>   
> The wording issue aside, at the implementation level you try to
> code/implement to prevent flaws, by doing things such as using higher
> quality steel (for bolts) and good coding practices (for software). At
> the design level, you try to design so as to *mask* flaws by avoiding
> single points of failure, doing things such as using 2 bolts (for
> tables) and using access controls to limit privilege escalation (for
> software).
> 
> Crispin
> -- 
> Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
> Director of Software Engineering, Novell  http://novell.com
> Olympic Games: The Bi-Annual Festival of Corruption
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From mouse at Rodents.Montreal.QC.CA  Fri Feb  3 02:10:06 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Fri, 3 Feb 2006 02:10:06 -0500 (EST)
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F173B@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F173B@va-mail.cigital.com>
Message-ID: <200602030713.CAA12148@Sparkle.Rodents.Montreal.QC.CA>

> I'm sorry, but it is just not possible to find design flaws by
> staring at code.

I strongly disagree with this, largely because I've done it myself.
It's the primary way I find design flaws in code, in fact.

Even if you add "unmotivated by a misbehaviour example", I've still
done it, though on only a few occasions.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From wietse at porcupine.org  Fri Feb  3 09:39:37 2006
From: wietse at porcupine.org (Wietse Venema)
Date: Fri, 3 Feb 2006 09:39:37 -0500 (EST)
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F173B@va-mail.cigital.com>
	"from Gary McGraw at Feb 2, 2006 08:49:37 pm"
Message-ID: <20060203143937.CDCE3BC1B4@spike.porcupine.org>

Gary McGraw:
> I'm sorry, but it is just not possible to find design flaws by
> staring at code.

My experience is otherwise. Without detailed documentation I can
usually see where in the life cycle the mistake was made: analysis
(e.g., solving the wrong problem), design (e.g., using an inappropriate
solution) or coding.

	Wietse


From Ken at KRvW.com  Fri Feb  3 10:24:54 2006
From: Ken at KRvW.com (Kenneth R. van Wyk)
Date: Fri, 03 Feb 2006 10:24:54 -0500
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F16FF@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F16FF@va-mail.cigital.com>
Message-ID: <43E375C6.4070108@KRvW.com>

This thread sure has opened up some lively debate...

Gary McGraw wrote:

>As a matter of practice, I usually use the terms that you suggested as
>modifiers and say:
>
>implementation bug
>design flaw
>software defect
>  
>
FWIW, I like to use the nomenclature "security defect" as an 
all-encompassing term, irrespective of design vs. implementation.  Then, 
quite frankly, I think that the choice of "bug" or "flaw" is far less 
important than putting them into the appropriate _context_ -- which is 
why I also generally use the above "implementation bug" and "design flaw". 

I do think that the distinction is important, even though I agree with 
the thought that it's pretty much of a continuum across the spectrum.  
 From a pragmatic viewpoint, one of the important distinctions is how 
one would go about rectifying the defect.  An implementation bug can 
often times be fixed in a couple lines of code (e.g., strncpy vs. 
strcpy), whereas a design flaw may well require going "back to the 
drawing board" and fixing an underlying architectural weakness.  This 
is, of course, irrespective of how the problem was found.

I'll also point out that none of three of the above terms even mention 
security.  They could be functional defects as well as security defects, 
which is just fine, IMHO.

Cheers,

Ken van Wyk



From gem at cigital.com  Fri Feb  3 11:13:08 2006
From: gem at cigital.com (Gary McGraw)
Date: Fri, 3 Feb 2006 11:13:08 -0500
Subject: [SC-L] Bugs and flaws
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F175C@va-mail.cigital.com>

To cycle this all back around to the original posting, lets talk about
the WMF flaw in particular.  Do we believe that the best way for
Microsoft to find similar design problems is to do code review?  Or
should they use a higher level approach?

Were they correct in saying (officially) that flaws such as WMF are hard
to anticipate? 

gem



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Fri Feb  3 11:19:33 2006
From: gem at cigital.com (Gary McGraw)
Date: Fri, 3 Feb 2006 11:19:33 -0500
Subject: [SC-L] Software Security (the book)
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4210B9@va-mail.cigital.com>

Hi sc-lers,

The new book is being released today and is finally available.  For
information on the book see www.swsec.com.  You might enjoy reading Dan
Geer's foreword (http://www.swsec.com/book/foreword/), which is both
erudite and entertaining as geer's writing tends to be.  The Table of
Contents is on the website too.  You'll find that the book talks all
about the touchpoints (big surprise).

"Software Security" is also being released as part of a three book set
called "The Software Security Library".  The box set will anchor a new
series from Addison-Wesley called the Addison-Wesley Software Security
Series (http://www.buildsecurityin.com/).  I am the editor of the new
series, and we are actively seeking proposals and contributors.  In
particular, I would love to see a solid treatment of risk-based security
testing and a book on abuse cases.  Who wants to write a book?

Hope you like it!

gem


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From al.eridani at gmail.com  Fri Feb  3 11:20:56 2006
From: al.eridani at gmail.com (Al Eridani)
Date: Fri, 3 Feb 2006 08:20:56 -0800
Subject: [SC-L] Bugs and flaws
In-Reply-To: <028401c6284b$0161c240$cb00000a@escheradmin>
References: <Pine.BSO.4.55.0602021528460.9430@vikki.vulnwatch.org>
	<028401c6284b$0161c240$cb00000a@escheradmin>
Message-ID: <af0358420602030820s1f5697f7g1f9b344511b1dff2@mail.gmail.com>

On 2/2/06, David Crocker <dcrocker at eschertech.com> wrote:
> If some small bolt in my car fails because the bolt met its manufacturer's
> specification but was not strong enough to withstand the loads it was subjected
> to, that is a low-level design error, not a manufacturing error.

I agree.

> Similarly, I view coding errors as low-level design errors.

I disagree.

If the design says "For each fund that the user owns, do X" and my
code does X for
all the funds but it skips the most recently acquired fund, I see it as a
"manufacturing" error.

On the other hand, if a user sells all of her funds and the design
does not properly
contemplate the situation where no funds are owned and therefore the software
misbehaves, I see it as a "design" error.



From Greg.Beeley at LightSys.org  Fri Feb  3 12:19:16 2006
From: Greg.Beeley at LightSys.org (Greg Beeley)
Date: Fri, 03 Feb 2006 12:19:16 -0500
Subject: [SC-L] Bugs and flaws
In-Reply-To: <20060203143937.CDCE3BC1B4@spike.porcupine.org>
References: <20060203143937.CDCE3BC1B4@spike.porcupine.org>
Message-ID: <43E39094.6000604@LightSys.org>

Wietse Venema wrote:
> My experience is otherwise. Without detailed documentation I can
> usually see where in the life cycle the mistake was made: analysis
> (e.g., solving the wrong problem), design (e.g., using an inappropriate
> solution) or coding.

I tend to agree - for *many* design related problems.  But I think it
is only true for design flaws that are violations of well-recognized
approaches to things (for instance, putting too much trust in a source
IP address for authentication, or blatant misuse of cryptography), or
when the problem being "solved" by the software is self-evident enough
that the auditor essentially repeats much of the software engineering
process, albeit (possibly) very informally, just by auditing the code.

Other design related defects are hard to find if you don't have a
well-defined problem - the old "validation" vs "verification" issue.
When the problem being solved by the software is an uncommon one, or
unique to the software, it is more likely that a design flaw will go
undetected by an auditor (for instance, your average code auditor
won't catch a design flaw in how retinal scanning software authenticates
a person, without having studied how it is supposed to work in the
first place).

- Greg

03-Feb-2006



From james.stibbards at cloakware.com  Fri Feb  3 12:16:08 2006
From: james.stibbards at cloakware.com (James Stibbards)
Date: Fri, 3 Feb 2006 12:16:08 -0500
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F175C@va-mail.cigital.com>
Message-ID: <200602031717.k13HHdOn009520@mail.cloakware.com>

Hi Gary,

In one of your prior posts you mentioned documentation.  I believe that the
problem with WMF was that someone had not examined WMF as a postential
source of vulnerabilities, since the embedded code was an legacy capability.

My belief is that one of the keys to finding flaws lies in the proper
capture of the requirements/contract of a software component, and then
examining and testing against that. Without the proper requirements that
speak clearly to security,  we can inspect and examine, but we won't know
what we're measuring against.  That doesn't solve the problem of knowing
when we're done, I realize.

See you at SSS.
- James

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Gary McGraw
Sent: Friday, February 03, 2006 11:13 AM
To: Kenneth R. van Wyk; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws

To cycle this all back around to the original posting, lets talk about the
WMF flaw in particular.  Do we believe that the best way for Microsoft to
find similar design problems is to do code review?  Or should they use a
higher level approach?

Were they correct in saying (officially) that flaws such as WMF are hard to
anticipate? 

gem



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php



From jleffler at us.ibm.com  Fri Feb  3 14:24:13 2006
From: jleffler at us.ibm.com (Jonathan Leffler)
Date: Fri, 3 Feb 2006 11:24:13 -0800
Subject: [SC-L] Re: Software Security (the book)
In-Reply-To: <200602031841.k13If4ED051259@ratsass.krvw.com>
Message-ID: <OF5D594B0F.B26595E4-ON8825710A.006A135B-8825710A.006A83E3@us.ibm.com>

Gary McGraw <gem at cigital.com> wrote:
>The new book is being released today and is finally available.

My copy arrived from AW y'day in the mail (there's a story behind how I 
got to request it; suffice to say it wasn't quite a routine order), so I 
was a little surprised to see that it was only officially released today.

I only started to read it last night, but it looked good so far.  Geer's 
intro is indeed interesting.  It will end up on the shelf next to BSS and 
ES once read.

--
Jonathan Leffler (jleffler at us.ibm.com)
STSM, Informix Database Engineering, IBM Information Management Division
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921   Tie-Line: 630-6921
      "I don't suffer from insanity; I enjoy every minute of it!"




From jsteven at cigital.com  Fri Feb  3 13:39:36 2006
From: jsteven at cigital.com (John Steven)
Date: Fri, 03 Feb 2006 13:39:36 -0500
Subject: [SC-L] The role static analysis tools play in uncovering elements
	of design 
Message-ID: <C0090D98.9D72%jsteven@cigital.com>

Jeff,

An unpopular opinion I?ve held is that static analysis tools, while very
helpful in finding problems, inhibit a reviewer?s ability to find collect as
much information about the structure, flow, and idiom of code?s design as
the reviewer might find if he/she spelunks the code manually.

I find it difficult to use tools other than source code navigators (source
insight) and scripts to facilitate my code understanding (at the
design-level). 

Perhaps you can give some examples of static analysis library/tool use that
overcomes my prejudice<or are you referring to the navigator tools as well?

-----
John Steven        
Principal, Software Security Group
Technical Director, Office of the CTO
703 404 5726 - Direct | 703 727 4034 - Cell
Cigital Inc.          | jsteven at cigital.com

4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

  
----snipped----
Static analysis tools can help a lot here. Used properly, they can provide
design-level insight into a software baseline. The huge advantage is that
it's correct.

--Jeff 
----snipped----



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060203/c0f08904/attachment.html 

From crispin at novell.com  Fri Feb  3 15:12:08 2006
From: crispin at novell.com (Crispin Cowan)
Date: Fri, 03 Feb 2006 12:12:08 -0800
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F175C@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F175C@va-mail.cigital.com>
Message-ID: <43E3B918.1050107@novell.com>

Gary McGraw wrote:
> To cycle this all back around to the original posting, lets talk about
> the WMF flaw in particular.  Do we believe that the best way for
> Microsoft to find similar design problems is to do code review?  Or
> should they use a higher level approach?
>
> Were they correct in saying (officially) that flaws such as WMF are hard
> to anticipate? 
>   
I have heard some very insightful security researchers from Microsoft
pushing an abstract notion of "attack surface", which is the amount of
code/data/API/whatever that is exposed to the attacker. To design for
security, among other things, reduce your attack surface.

The WMF design defect seems to be that IE has too large of an attack
surface. There are way too many ways for unauthenticated remote web
servers to induce the client to run way too much code with parameters
provided by the attacker. The implementation flaw is that the WMF API in
particular is vulnerable to malicious content.

None of which strikes me as surprising, but maybe that's just me :)

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption




From dana at vulscan.com  Fri Feb  3 18:28:29 2006
From: dana at vulscan.com (Dana Epp)
Date: Fri, 3 Feb 2006 15:28:29 -0800
Subject: [SC-L] Bugs and flaws
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F175C@va-mail.cigital.com>
	<43E3B918.1050107@novell.com>
Message-ID: <9AE3FC06F0A89A43A4D6F667955082C46FFD@sbsmain.Vulscan.local>

I think I would word that differently. The design defect was when Microsoft decided to allow meta data to call GDI functions. 
 
Around 1990 when this was introduced the threat profile was entirely different; the operating system could trust the metadata. Well, actually I would argue that they couldn't, but no one knew any better yet. At the time SetAbortProc() was an important function to allow for print cancellation in the co-operative multitasking environment that was Windows 3.0.
 
To be clear, IE was NOT DIRECTLY vulnerable to the WMF attack vector everyone likes to use as a test case for this discussion. IE actually refuses to process any type of metadata that supported META_ESCAPE records (which SetAbortProc relies on). Hence why its not possible to exploit the vulnerability by simply calling a WMF image via HTML. So how is IE vulnerable then? It's not actually. The attack vector uses IE as a conduit to actually call out to secondary library code that will process it. In the case of the exploits that hit the Net, attackers used an IFRAME hack to call out to the shell to process it. The shell would look up the handler for WMF, which was the Windows Picture Viewer that did the processing in shimgvw.dll. When the dll processed the WMF, it would convert it to a printable EMF format, and bam... we ran into problems.
 
With the design defect being the fact metadata can call arbitrary GDI code, the implementation flaw is the fact applications like IE rely so heavily on calling out to secondary libraries that just can't be trusted. Even if IE has had a strong code review, it is extremely probable that most of the secondary library code has not had the same audit scrutiny. This is a weakness to all applications, not just IE. When you call out to untrusted code that you don't control, you put the application at risk. No different than any other operating system. Only problem is Windows is riddled with these potential holes because its sharing so much of the same codebase. And in the past the teams rarely talk to each other to figure this out.
 
Code reuse is one thing, but some of the components in Windows are carry over from 15 years ago, and will continue to put us at risk due to the implementation flaws that haven't yet been found. But with such a huge master sources to begin with, its not something that will be fixed over night.
 
---
Regards,
Dana Epp [Microsoft Security MVP]
Blog: http://silverstr.ufies.org/blog/

________________________________

From: sc-l-bounces at securecoding.org on behalf of Crispin Cowan
Sent: Fri 2/3/2006 12:12 PM
To: Gary McGraw
Cc: Kenneth R. van Wyk; Secure Coding Mailing List
Subject: Re: [SC-L] Bugs and flaws



Gary McGraw wrote:
> To cycle this all back around to the original posting, lets talk about
> the WMF flaw in particular.  Do we believe that the best way for
> Microsoft to find similar design problems is to do code review?  Or
> should they use a higher level approach?
>
> Were they correct in saying (officially) that flaws such as WMF are hard
> to anticipate?
>  
I have heard some very insightful security researchers from Microsoft
pushing an abstract notion of "attack surface", which is the amount of
code/data/API/whatever that is exposed to the attacker. To design for
security, among other things, reduce your attack surface.

The WMF design defect seems to be that IE has too large of an attack
surface. There are way too many ways for unauthenticated remote web
servers to induce the client to run way too much code with parameters
provided by the attacker. The implementation flaw is that the WMF API in
particular is vulnerable to malicious content.

None of which strikes me as surprising, but maybe that's just me :)

Crispin
--
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
        Olympic Games: The Bi-Annual Festival of Corruption


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060203/6cfd986a/attachment.html 

From brian at fortifysoftware.com  Fri Feb  3 20:01:15 2006
From: brian at fortifysoftware.com (Brian Chess)
Date: Fri, 03 Feb 2006 17:01:15 -0800
Subject: [SC-L] Re: SC-L Digest, Vol 2, Issue 17
In-Reply-To: <200602032359.k13Nx7ds055282@ratsass.krvw.com>
Message-ID: <C0093CDB.D6E2%brian@fortifysoftware.com>

John, I think this has to do with what you want to achieve when you explore
code.

A static analysis tool is a fancy sort of pattern matcher.  If the kinds of
patterns you're interested in aren't that fancy, ("does the program use
function X()?"; "what is the class hierarchy?") then a fancy pattern matcher
is overkill.

If your version of code exploration include things like "is function A()
always called before function B()?" or "is it possible for this data
structure Z to be populated with the result of function X()?"  then you're
in the realm where a static analysis tool might help.

Of course, a static analysis tool allows you to take shortcuts, so you may
learn less about the code than you would if you had to answer these
questions the hard way.

Brian


Date: Fri, 03 Feb 2006 13:39:36 -0500
From: "John Steven" <jsteven at cigital.com>
Subject: [SC-L] The role static analysis tools play in uncovering
    elements    of design
To: "Jeff Williams" <jeff.williams at aspectsecurity.com>,    "Secure Coding
    Mailing List" <SC-L at securecoding.org>
Message-ID: <C0090D98.9D72%jsteven at cigital.com>
Content-Type: text/plain; charset="iso-8859-1"

Jeff,

An unpopular opinion I?ve held is that static analysis tools, while very
helpful in finding problems, inhibit a reviewer?s ability to find collect as
much information about the structure, flow, and idiom of code?s design as
the reviewer might find if he/she spelunks the code manually.

I find it difficult to use tools other than source code navigators (source
insight) and scripts to facilitate my code understanding (at the
design-level). 

Perhaps you can give some examples of static analysis library/tool use that
overcomes my prejudice<or are you referring to the navigator tools as well?

-----
John Steven        
Principal, Software Security Group
Technical Director, Office of the CTO
703 404 5726 - Direct | 703 727 4034 - Cell
Cigital Inc.          | jsteven at cigital.com

4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908




From brian at fortifysoftware.com  Fri Feb  3 20:51:41 2006
From: brian at fortifysoftware.com (Brian Chess)
Date: Fri, 03 Feb 2006 17:51:41 -0800
Subject: [SC-L] Bugs and flaws
Message-ID: <C00948AD.D6F4%brian@fortifysoftware.com>

The best definition for "flaw" and "bug" I've heard so far is that a flaw is
a successful implementation of your intent, while a bug is unintentional.  I
think I've also heard "a bug is small", a flaw is big", but that definition
is awfully squishy.

If the difference between a bug and a flaw is indeed one of intent, then I
don't think it's a useful distinction.  Intent rarely brings with it other
dependable characteristics.

I've also heard "bugs are things that a static analysis tool can find", but
I don't think that really captures it either.  For example, it's easy for a
static analysis tool to point out that the following Java statement implies
that the program is using weak cryptography:

    SecretKey key = KeyGenerator.getInstance("DES").generateKey();

Brian



From nick at virus-l.demon.co.uk  Fri Feb  3 19:22:59 2006
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Date: Sat, 04 Feb 2006 13:22:59 +1300
Subject: [SC-L] Bugs and flaws
In-Reply-To: <200602031841.k13If4EE051259@ratsass.krvw.com>
Message-ID: <43E4AAB3.439.1BAF4C63@nick.virus-l.demon.co.uk>

"Gary McGraw" <gem at cigital.com> wrote:

> To cycle this all back around to the original posting, lets talk about
> the WMF flaw in particular.  Do we believe that the best way for
> Microsoft to find similar design problems is to do code review?  Or
> should they use a higher level approach?

I'll leave that to those with relevant specification/design/ 
implementation/review experiences...

> Were they correct in saying (officially) that flaws such as WMF are hard
> to anticipate? 

No.

That claim is totally bogus on its face.

It is an very well-established "rule" that you commingle code and data 
_at extreme risk_.

We have also known for a very long time that our historically preferred 
use of (simple) von Neumann architectures make maintaining that 
distinction rather tricky.

However, neither absolves us of the duty of care to be aware of these 
issues and to take suitable measures to ensure we don't design systems 
apparently intent on shooting themselves in the feet.

I'd wager that even way back then, some designer and/or developer at 
MS, when doing the WMF design/implementation back in Win16 days (Win 
3.0, no?) experienced one of those "We really shouldn't be doing that 
like this..." moments, but then dismissed it as an unnecessary concern 
"because it's only for a personal computer" (or some other cosmically 
shallow reason -- "if I get this done by Friday I'll have a weekend for 
a change", "if I get this done by Friday I'll make a nice bonus", 
"usability is more important than anything else", "performance is more 
important than anything else", etc, etc, etc).

Given the intended userbase and extant computing environment at that 
time, the design probably was "quite acceptable".  The real fault is 
that it was then, repeatedly and apparently largely unquestioningly, 
ported into new implementations (Win 3.1, NT3x, Win9x, NT4, ME, Win2K, 
XP, XPSP2, W2K3) _including_ the ones done after Billy Boy's "security 
is now more important than anything" memo.  At some point in that 
evolution, several someone's should have been raising their hands and 
saying, "You know, now is the time we should fix this...".  Someone on 
one of the the IE teams obviously noticed and flagged the issue, but 
why didn't that flag get raised bigger, higher, brighter?

...

It is bogus for another reason too -- some of the people at MS making 
that official claim also said "this is the first such flaw of this 
kind", and that's just BS.  Long before WM/Concept.A (or its 
forerunner, the oft-forgotten WM/DMV.A) many security and antivirus 
folk were warning that embedding the more powerful, complex programming 
language and architecture macros (such as WordBasic, VBA and 
AccessBasic) into their associated "document" files was an inherently 
flawed design and would only lead to trouble.

So, not only have we long-understood the theoretical reasons for why 
the underlying causes of WMF are inherently bad design and best avoided 
if at all possible, BUT MS has had its own, self-inflicted stupidities 
of exactly the same kind.

If MS truly could not anticipate, at some point along the Win3x to W2K3 
development timeline earlier than 28 Dec 2005, that this WMF design 
"feature" would cause trouble, one has to ask if MS should be allowed 
to make software for general consumption...


Regards,

Nick FitzGerald



From nick at virus-l.demon.co.uk  Fri Feb  3 22:59:56 2006
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Date: Sat, 04 Feb 2006 16:59:56 +1300
Subject: [SC-L] Bugs and flaws
In-Reply-To: <200602031841.k13If4EE051259@ratsass.krvw.com>
Message-ID: <43E4DD8C.7295.1C75E99B@nick.virus-l.demon.co.uk>

Al Eridani <al.eridani at gmail.com> wrote:

> If the design says "For each fund that the user owns, do X" and my
> code does X for
> all the funds but it skips the most recently acquired fund, I see it as a
> "manufacturing" error.
> 
> On the other hand, if a user sells all of her funds and the design
> does not properly
> contemplate the situation where no funds are owned and therefore the software
> misbehaves, I see it as a "design" error.

Maybe I'm confused, but...

If the design in your second case is still the same one -- "For each 
fund that the user owns, do X" -- then this second example, like your 
first, is NOT a design error but an implementation (or "manufacturing" 
if you prefer) error.  (Both are (probably) due to some or other form 
of improper bounds checking, and probably due to na?ve use of zero-
based counters controlling a loop...  8-) )

The design "For each fund that the user owns, do X" clearly (well, to 
me -- am I odd in this?) says that NOTHING be done if the number of 
funds is zero, hence the second result is an implemention error.


Regards,

Nick FitzGerald




From jeff.williams at aspectsecurity.com  Sat Feb  4 00:26:23 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Sat, 4 Feb 2006 00:26:23 -0500
Subject: [SC-L] RE: The role static analysis tools play in uncovering
	elements of design 
In-Reply-To: <C0090D98.9D72%jsteven@cigital.com>
Message-ID: <00a801c6294b$89b42b50$ba04a8c0@intranet.aspectsecurity.com>

I think there's a lot more that static analysis can do than what you're
describing. They're not (necessarily) just fancy pattern matchers.

Static analysis can add security meta-information to a software baseline. If
the tool knows which methods are related to which security mechanisms, it
can help you find, navigate, and understand their design. The tools help me
generate a security 'view' of a software baseline.

Does the application do encryption? Is it centralized? What algorithms are
used? What data flows are affected? Are there any paths around the
encryption? Where are the keys stored? Is there proper error handling and
logging for the encryption mechanism? Static analysis tools make answering
all these questions easier.

Today's static analysis tools are only starting to help here. Tools focused
on dumping out a list of vulnerabilities don't work well for me. Too many
false alarms.  Maybe that's what you meant by 'inhibit'.

--Jeff
?
Jeff Williams, CEO
Aspect Security
http://www.aspectsecurity.com
email: jeff.williams at aspectsecurity.com
phone: 410-707-1487
?
________________________________________
From: John Steven [mailto:jsteven at cigital.com] 
Sent: Friday, February 03, 2006 1:40 PM
To: Jeff Williams; Secure Coding Mailing List
Subject: The role static analysis tools play in uncovering elements of
design 

Jeff,

An unpopular opinion I?ve held is that static analysis tools, while very
helpful in finding problems, inhibit a reviewer?s ability to find collect as
much information about the structure, flow, and idiom of code?s design as
the reviewer might find if he/she spelunks the code manually.

I find it difficult to use tools other than source code navigators (source
insight) and scripts to facilitate my code understanding (at the
design-level). 

Perhaps you can give some examples of static analysis library/tool use that
overcomes my prejudice?or are you referring to the navigator tools as well?

-----
John Steven ??????????????????????????????????
Principal, Software Security Group
Technical Director, Office of the CTO
703 404 5726 - Direct | 703 727 4034 - Cell
Cigital Inc. ?????????| jsteven at cigital.com

4772 F7F3 1019 4668 62AD ?94B0 AE7F EEF4 62D5 F908

??
----snipped----
Static analysis tools can help a lot here. Used properly, they can provide
design-level insight into a software baseline. The huge advantage is that
it's correct.

--Jeff 
----snipped----
________________________________________
This electronic message transmission contains information that may be
confidential or privileged. The information contained herein is intended
solely for the recipient and use by any other party is not authorized. If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited. If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message. Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
________________________________________




From brian at fortifysoftware.com  Sun Feb  5 12:21:03 2006
From: brian at fortifysoftware.com (Brian Chess)
Date: Sun, 05 Feb 2006 09:21:03 -0800
Subject: [SC-L] RE: The role static analysis tools play in uncovering
	elements of design
In-Reply-To: <200602041700.k14H02fJ064986@ratsass.krvw.com>
Message-ID: <C00B73FF.DFA2%brian@fortifysoftware.com>

"Jeff Williams" <jeff.williams at aspectsecurity.com> wrote:

> I think there's a lot more that static analysis can do than what you're
> describing. They're not (necessarily) just fancy pattern matchers.


Jeff, you raise a important point.  Getting good value out of static
analysis requires a second component in addition to a fancy pattern
matcher.  You also need a good set of fancy patterns (aka rules)
to match against.

Understand that when I say ?fancy pattern?, I don?t mean ?regular
expression?.  More formally, I mean "program property".  Taint
propagation, state transitions, feasible control flow paths,
alias analysis, etc. are all important if you?d like to build
a tool, but if you?re contemplating how to best apply a tool,
all of your interaction will be of the form

?Show me places in the program where property X holds?

and the goal of the tool is to match the code against the property
you've specified.  For a good initial user experience, a tool
needs to come with a well-constructed default set of rules.  For
aiding in program understanding, it needs to allow you to easily
add new rules of your own construction.

The number of false alarms you get from a good static analysis
tool is directly related to how aggressive the tool is in finding
constructs that might be what you're looking for. As an example, I'll
use a question you posed: "are there any paths around the
encryption?"  If you're going to bet your life that there aren't
any such paths, then you'd like the tool to make conservative
assumptions and allow you to manually review anything that might
possibly match the pattern you've specified. If you only have a
passing interest in the property, then you'd prefer the tool weed
out paths that, while not impossible, are not likely to be of
interest.  Maybe some code will help illustrate my point:

  if (b) {
    panic();
  else {
    buf = encrypt(buf);
  }
  return buf;

Would you like to be warned that buf may be returned unencrypted?
This code fragment guarantees that either buf is encrypted or
panic() is called.  But usually control doesn't return from a
function named panic().  The problem is, that's not universally
true; sometimes panic() just sets a flag and the system reboot
happens shortly thereafter.

Whether or not you want to see this path depends on how important
it really is to you that encryption is absolutely never bypassed.
Your tolerance for noise is dictated by the level of assurance
you require.

Brian




From jeff.williams at aspectsecurity.com  Sun Feb  5 23:32:51 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Sun, 5 Feb 2006 23:32:51 -0500
Subject: [SC-L] RE: The role static analysis tools play in
	uncoveringelements of design
In-Reply-To: <C00B73FF.DFA2%brian@fortifysoftware.com>
Message-ID: <005201c62ad6$6410d330$0e04a8c0@intranet.aspectsecurity.com>

Brian,

>?Show me places in the program where property X holds?

Yes. That's it exactly. Current tools can answer this type of question to
some extent, but they're not really designed for it. The interaction
contemplated by most of the tools is more like "show me the line of code the
vulnerability is on." This doesn't really help verify the security of an
application and doesn't work at the design level. The "property X" approach
does both.

> aiding in program understanding, it needs to allow you to easily
> add new rules of your own construction.

This is absolutely critical. In addition to creating new rules, we need to
be able to "tag" custom libraries and methods with their security
properties. This will allow existing rules to be applied in new contexts.
E.g. tagging a custom validation method with "untaint" so existing data
validation rules now include it.

> Whether or not you want to see this path depends on how important
> it really is to you that encryption is absolutely never bypassed.
> Your tolerance for noise is dictated by the level of assurance
> you require.

Absolutely. The encryption example demonstrates your point well. Still, I
wouldn't want anyone to get the impression that there's a direct
relationship between the signal-to-noise setting on the tool and the level
of assurance one gets in an application. This is because the tools tend to
find the problems that are easiest for them to find, not the ones that
represent the biggest risk.

For example, access control problems in web applications are difficult to
find automatically, because the implementations are generally complex and
distributed across a software baseline. So even if I only want a typical
commercial level of assurance in a web application, I have to turn up the
volume on the tools all the way. And even that might not make them visible.

--Jeff






From Arian.Evans at fishnetsecurity.com  Mon Feb  6 10:52:54 2006
From: Arian.Evans at fishnetsecurity.com (Evans, Arian)
Date: Mon, 6 Feb 2006 09:52:54 -0600
Subject: [SC-L] Bugs and flaws
Message-ID: <8654C851B1DAFA4FA18A9F150145F925054D2A60@FNEX01.fishnetsecurity.com>


> Sent: Thursday, February 02, 2006 7:50 PM
> 
> I'm sorry, but it is just not possible to find design flaws 
> by staring at code.
> 
> gem

 
That is simply not true. <anecdotal_examples>

[...]
(I originally wrote out some anecdotal stuffs here that on reflection
implied more organizational issues with providing poor design specification,
...and leaving design up to implementation choices...than providing
examples of design choices that are obvious from implementation review.)

</anecdotal>

So while I politely disagree, my insufficient examples reinforce
that there is a slippery inference slope here.

This has been one of the more stimulating dialogues on SCL; thanks.

-ae

p.s.--the original response bounced the list due to being subscribed
under an older email alias.



>  -----Original Message-----
> From: 	Jeff Williams [mailto:jeff.williams at aspectsecurity.com]
> Sent:	Thu Feb 02 20:32:29 2006
> To:	'Secure Coding Mailing List'
> Subject:	RE: [SC-L] Bugs and flaws
> 
> At the risk of piling on here, there's no question that it's 
> critical to
> consider security problems across the continuum. While we're 
> at it, the
> analysis should start back even further with the requirements 
> or even the
> whole system concept.
> 
> All of the representations across the continuum (rqmts, arch, 
> design, code)
> are just models of the same thing.  They start more abstract 
> and end up as
> code.  A *single* problem could exist in all these models at 
> the same time.
> 
> Higher-level representations of systems are generally 
> eclipsed by lower
> level ones fairly rapidly.  For example, it's a rare group 
> that updates
> their design docs as implementation progresses. So once 
> you've got code, the
> architecture-flaws don't come from architecture documents 
> (which lie). The
> best place to look for them (if you want truth) is to look in 
> the code.
> 
> To me, the important thing here is to give software teams 
> good advice about
> the level of effort they're going to have to put into fixing 
> a problem. If
> it helps to give a security problem a label to let them know 
> they're going
> to have to go back to the drawing board, I think saying 
> 'architecture-flaw'
> or 'design-flaw' is fine. But I agree with others that saying 
> 'flaw' alone
> doesn't help distinguish it from 'bug' in the minds of most 
> developers or
> architects.
> 
> --Jeff
> 
> Jeff Williams, CEO
> Aspect Security
> http://www.aspectsecurity.com
> 
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Crispin Cowan
> Sent: Wednesday, February 01, 2006 5:07 PM
> To: John Steven
> Cc: Will Kruse; Secure Coding Mailing List
> Subject: Re: [SC-L] Bugs and flaws
> 
> John Steven wrote:
> > I'm not sure there's any value in discussing this minutia 
> further, but
> here
> > goes:
> >   
> We'll let the moderator decide that :)
> 
> > 1) Crispin, I think you've nailed one thing. The continuum from:
> >
> > Architecture --> Design --> Low-level Design --> (to) Implementation
> >
> > is a blurry one, and certainly slippery as you move from 'left' to
> 'right'.
> >   
> Cool.
> 
> > But, we all should understand that there's commensurate blur in our
> analysis
> > techniques (aka architecture and code review) to assure 
> that as we sweep
> > over software that we uncover both bugs and architectural flaws.
> >   
> Also agreed.
> 
> > 2) Flaws are different in important ways bugs when it comes to
> presentation,
> > prioritization, and mitigation. Let's explore by physical 
> analog first.
> >   
> I disagree with the word usage. To me, "bug" and "flaw" are exactly
> synonyms. The distinction being drawn here is between "implementation
> flaws" vs. "design flaws". You are just creating confusing jargon to
> claim that "flaw" is somehow more abstract than "bug". Flaw ::= defect
> ::= bug. A vulnerability is a special subset of 
> flaws/defects/bugs that
> has the property of being exploitable.
> 
> > I nearly fell through one of my consultant's tables as I 
> leaned on it this
> > morning. We explored: "Bug or flaw?".
> >   
> The wording issue aside, at the implementation level you try to
> code/implement to prevent flaws, by doing things such as using higher
> quality steel (for bolts) and good coding practices (for software). At
> the design level, you try to design so as to *mask* flaws by avoiding
> single points of failure, doing things such as using 2 bolts (for
> tables) and using access controls to limit privilege escalation (for
> software).
> 
> Crispin
> -- 
> Crispin Cowan, Ph.D.                      
> http://crispincowan.com/~crispin/
> Director of Software Engineering, Novell  http://novell.com
> 	Olympic Games: The Bi-Annual Festival of Corruption
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 
> 
> 
> 
> --------------------------------------------------------------
> --------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein 
> is intended
> solely for the recipient and use by any other party is not 
> authorized.  If
> you are not the intended recipient (or otherwise authorized 
> to receive this
> message by the intended recipient), any disclosure, copying, 
> distribution or
> use of the contents of the information is prohibited.  If you 
> have received
> this electronic message transmission in error, please contact 
> the sender by
> reply email and delete all copies of this message.  Cigital, 
> Inc. accepts no
> responsibility for any loss or damage resulting directly or 
> indirectly from
> the use of this email or its contents.
> Thank You.
> --------------------------------------------------------------
> --------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 



From Arian.Evans at fishnetsecurity.com  Mon Feb  6 11:10:03 2006
From: Arian.Evans at fishnetsecurity.com (Evans, Arian)
Date: Mon, 6 Feb 2006 10:10:03 -0600
Subject: [SC-L] Bugs and flaws
Message-ID: <8654C851B1DAFA4FA18A9F150145F925054D2AA0@FNEX01.fishnetsecurity.com>

Original message bounced due to address; I chopped to remove WMF and rambling
to focus on the subject of language standardization:

[...wmf...]
fyi// on attack surface: http://www-2.cs.cmu.edu/~wing/

Attack surface concepts fit hand-in-glove with threat modeling concepts,
which fit hand in glove with this equivocal design/implementation dialogue.

[...]
Q. What does the bug/flaw dialogue demonstrate the need for?

There's plenty of folks on this list smarter than I am, so it is
nice to see a majority agree on what I think the key issues are:
communicating (a) accurate and (b) actionable data; expanded:

1. Defect Definition
2. Defect Classification
3. Defect Identification
4. Defect Implication (effectively communicating defect implication)

By example I mean (number corresponds to above):

1. Format String, weak crypto use, define what & why are these security defects?
2. Implementation Defect, Design Defect, bug, flaw
3. How do we identify these defects in software?
4. Implication: RTAWV (Risk, Threat, Attack, Weakness, Vuln) & communication
to both technical and non-technical audience is the goal.

I added Weakness at the TRIKE group's suggestion, and it has significantly
helped in classification instead of using two confusing vuln categories.

There is obviously a many-to-one mapping between threat->attack<-weakness
and even from vuln to weakness, depending on how we define vuln. (I have
defined vuln as "a particular instance or attackable instance of a weakness").

This is *valuable* information to the person trying to solve issues in this
problem domain, but I rarely find it well understood by *non-appsec* folks.

(Valuable in the sense that it is easier for non-appsec folks to act on a weakness,
like insufficient output encoding standards/implementation, than a list of 10,000
exploitable URLs in a large templated site representing 4 XSS variants.)

[...]

I continue to encounter equivocal uses of the words Threat, Attack, Vulnerability,
Flaw, Defect, Artifact (and associated phrases like "security-artifact"), Fault,
Bug, Error, Failure, Mistake, MFV (multi-factor vulnerability) in our collective
software security dialogue and literature.

What is the best way to work on establishing a common language? Is it reasonable
or realistic to expect such standardization?

OWASP and WASC have made strides in the webified space on defining attack classes,
and some weak patterns; Mitre has worked terminology in the unmanaged code space.

Where to go from here?

Arian J. Evans
FishNet Security

816.421.6611 [fns office]
816.701.2045 [direct] <--limited access
888.732.9406 [fns toll-free]
816.421.6677 [fns general fax]
913.710.7045 [mobile] <--best bet
aevans at fishnetsecurity.com [email]

http://www.fishnetsecurity.com





> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Crispin Cowan
> Sent: Friday, February 03, 2006 2:12 PM
> To: Gary McGraw
> Cc: Kenneth R. van Wyk; Secure Coding Mailing List
> Subject: Re: [SC-L] Bugs and flaws
> 
> 
> Gary McGraw wrote:
> > To cycle this all back around to the original posting, lets 
> talk about
> > the WMF flaw in particular.  Do we believe that the best way for
> > Microsoft to find similar design problems is to do code review?  Or
> > should they use a higher level approach?
> >
> > Were they correct in saying (officially) that flaws such as 
> WMF are hard
> > to anticipate? 
> >   
> I have heard some very insightful security researchers from Microsoft
> pushing an abstract notion of "attack surface", which is the amount of
> code/data/API/whatever that is exposed to the attacker. To design for
> security, among other things, reduce your attack surface.
> 
> The WMF design defect seems to be that IE has too large of an attack
> surface. There are way too many ways for unauthenticated remote web
> servers to induce the client to run way too much code with parameters
> provided by the attacker. The implementation flaw is that the 
> WMF API in
> particular is vulnerable to malicious content.
> 
> None of which strikes me as surprising, but maybe that's just me :)
> 
> Crispin
> -- 
> Crispin Cowan, Ph.D.                      
> http://crispincowan.com/~crispin/
> Director of Software Engineering, Novell  http://novell.com
> 	Olympic Games: The Bi-Annual Festival of Corruption
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 



From gem at cigital.com  Mon Feb  6 23:13:24 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 6 Feb 2006 23:13:24 -0500
Subject: [SC-L] Bugs and flaws
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F1AE5@va-mail.cigital.com>

Hi all,

I'm afraid I don't concur with this definition.  Here's a (rather vague) flaw example that may help clarify what I mean.  Think about an error of omission where an API is exposed with no A&A protection whatsoever.  This API may have been designed not to have been exposed originally, but somehow  became exposed only over time.

How do you find errors of omission with a static analysis tool?  

This is only one of salzer and schroeder's principles in action.  What of the other 9?

gem

P.s. Five points to whoever names the principle in question.

P.p.s. The book is out www.swsec.com

 -----Original Message-----
From: 	Brian Chess [mailto:brian at fortifysoftware.com]
Sent:	Sat Feb 04 00:56:16 2006
To:	sc-l at securecoding.org
Subject:	RE: [SC-L] Bugs and flaws

The best definition for "flaw" and "bug" I've heard so far is that a flaw is
a successful implementation of your intent, while a bug is unintentional.  I
think I've also heard "a bug is small", a flaw is big", but that definition
is awfully squishy.

If the difference between a bug and a flaw is indeed one of intent, then I
don't think it's a useful distinction.  Intent rarely brings with it other
dependable characteristics.

I've also heard "bugs are things that a static analysis tool can find", but
I don't think that really captures it either.  For example, it's easy for a
static analysis tool to point out that the following Java statement implies
that the program is using weak cryptography:

    SecretKey key = KeyGenerator.getInstance("DES").generateKey();

Brian

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Mon Feb  6 23:13:27 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 6 Feb 2006 23:13:27 -0500
Subject: [SC-L] Bugs and flaws
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F1AE6@va-mail.cigital.com>

I'm with you on this threat modeling thing...which is the process  meant to lay flaws bare.  I like to call it "risk analysis" of course (using american war nomenclature instead of british/australian).  STRIDE is an important step in the right direction, but a checklist approach has essential creativity constraints worth pondering.

My only point in making the distinction clear (bugs vs flaws) is to make sure that we don't forget design, requirements, and early lifecycle artifacts in our rush to analyze code.

Please do both (touchpoints 1 and 2 in Software Security).

gem

 -----Original Message-----
From: 	Evans, Arian [mailto:Arian.Evans at fishnetsecurity.com]
Sent:	Fri Feb 03 18:29:29 2006
To:	Crispin Cowan; Gary McGraw; Secure Coding Mailing List; Kenneth R. van Wyk
Subject:	RE: [SC-L] Bugs and flaws

per WMF// Let's face it, this was legacy, possibly deprecated code that
was likely low on the security things-to-do list. I suspect MS, like the
rest of the world, has resource limitations regarding analyzing all their
various product/api entry points for security implications.

Which is one of the reasons I think threat modeling came in vogue, and I
think a threat model would flag this in bright red for review, but you
need resources with quite a bit of knowledge and time to build that model,
and again, since this was legacy functionality...

fyi// on attack surface: http://www-2.cs.cmu.edu/~wing/

There are several ppls that have done nice work here; it fits hand-in-glove
with threat modeling concepts, which fits hand in glove with this whole
equivocal dialogue about design/implementation verbiage.

This whole discussion underscores the real issue we have, which is
a common language.

So how to fix it? A taxonomy and terminology guide; simple, concise.

There's plenty of folks on this list a lot smarter than I am, so it is
nice to see that a majority agree on what I think the key issues are:
communicating (a) accurate and (b) actionable data, or expanded:

1. Defect Definition
2. Defect Classification
3. Defect Identification
4. Defect Implication (communicating defect implication as goal)

By example I mean:

1. Format String, weak crypto use, define what & why are these security defects?
2. Implementation Defect, Design Defect, bug, flaw, blah
3. How do we identify these defects in software?
4. Implication: RTAWV (Risk, Threat, Attack, Weakness, Vuln) & communication
to both technical, and non-technical audience.

I added Weakness at the TRIKE group's suggestion, and it has significantly
helped in classification instead of using two confusing vuln categories.

There is obviously a many-to-one mapping between threat->attack<-weakness
and even from vuln to weakness, depending on how we define vuln. (I have
defined vuln as "a particular instance or attackable instance of a weakness").

This is *valuable* information to the person trying to solve issues in this
problem domain, but I rarely find it well understood by non-appsec folks.

I have attempted to address and communicate this in a short paper titled:
::Taxonomy of Software Security Analysis Types:: 

(Software Security Analysis == defined as == Software Analysis for Defects
with Security Implications, implications being contextual.)

Is significantly weakened if at the end of the day no one knows what I mean
by design weakness, implementation defect, goblins, etc. So I will need
all your help in shoring up the language.

My reason for distinction of "security as a defect implication" is that
defects are sometimes clear; the implications are not always clear and do
not always follow from the defects. Defects are neither a necessary nor
sufficient condition for security implications (obviously), but it the
implications most people solving problems care about, not defect language.

Much of this is underscored in the IEEE software defect terminology, but
look at our current industry ambiguity between attacks and vulnerabilities!

I continue to encounter wildly equivocal uses of the words Threat, Attack,
Vulnerability, Flaw, Defect, Artifact (and associated phrases like "security-
artifact"), Fault, Bug, Error, Failure, Mistake, MFV (multi-factor vulnerability)
in our collective software security dialogue and literature.

I am *not* *married* to any particular verbiage; my goal is a common
language so we can have more effective dialogue,

Arian J. Evans
FishNet Security

816.421.6611 [fns office]
816.701.2045 [direct] <--limited access
888.732.9406 [fns toll-free]
816.421.6677 [fns general fax]
913.710.7045 [mobile] <--best bet
aevans at fishnetsecurity.com [email]

http://www.fishnetsecurity.com





> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Crispin Cowan
> Sent: Friday, February 03, 2006 2:12 PM
> To: Gary McGraw
> Cc: Kenneth R. van Wyk; Secure Coding Mailing List
> Subject: Re: [SC-L] Bugs and flaws
> 
> 
> Gary McGraw wrote:
> > To cycle this all back around to the original posting, lets 
> talk about
> > the WMF flaw in particular.  Do we believe that the best way for
> > Microsoft to find similar design problems is to do code review?  Or
> > should they use a higher level approach?
> >
> > Were they correct in saying (officially) that flaws such as 
> WMF are hard
> > to anticipate? 
> >   
> I have heard some very insightful security researchers from Microsoft
> pushing an abstract notion of "attack surface", which is the amount of
> code/data/API/whatever that is exposed to the attacker. To design for
> security, among other things, reduce your attack surface.
> 
> The WMF design defect seems to be that IE has too large of an attack
> surface. There are way too many ways for unauthenticated remote web
> servers to induce the client to run way too much code with parameters
> provided by the attacker. The implementation flaw is that the 
> WMF API in
> particular is vulnerable to malicious content.
> 
> None of which strikes me as surprising, but maybe that's just me :)
> 
> Crispin
> -- 
> Crispin Cowan, Ph.D.                      
> http://crispincowan.com/~crispin/
> Director of Software Engineering, Novell  http://novell.com
> 	Olympic Games: The Bi-Annual Festival of Corruption
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From crispin at novell.com  Tue Feb  7 03:25:13 2006
From: crispin at novell.com (Crispin Cowan)
Date: Tue, 07 Feb 2006 01:25:13 -0700
Subject: [SC-L] Bugs and flaws
In-Reply-To: <9AE3FC06F0A89A43A4D6F667955082C46FFD@sbsmain.Vulscan.local>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F175C@va-mail.cigital.com>
	<43E3B918.1050107@novell.com>
	<9AE3FC06F0A89A43A4D6F667955082C46FFD@sbsmain.Vulscan.local>
Message-ID: <43E85969.2050100@novell.com>

Thanks for the very detailed and informative explanation.

However, I still think it sounds like IE has too large of an attack
surface :) It still seems to be the case that IE can be persuaded to
execute any of a large amount of code based on its raw (web) input, with
(fairly) arbitrary parameters, and this large attack surface allows
attackers to find vulnerabilities in any of the code that IE calls out to.

Crispin

Dana Epp wrote:
> I think I would word that differently. The design defect was when
> Microsoft decided to allow meta data to call GDI functions.
>  
> Around 1990 when this was introduced the threat profile was entirely
> different; the operating system could trust the metadata. Well,
> actually I would argue that they couldn't, but no one knew any better
> yet. At the time SetAbortProc() was an important function to allow for
> print cancellation in the co-operative multitasking environment that
> was Windows 3.0.
>  
> To be clear, IE was NOT DIRECTLY vulnerable to the WMF attack vector
> everyone likes to use as a test case for this discussion. IE actually
> refuses to process any type of metadata that supported META_ESCAPE
> records (which SetAbortProc relies on). Hence why its not possible to
> exploit the vulnerability by simply calling a WMF image via HTML. So
> how is IE vulnerable then? It's not actually. The attack vector uses
> IE as a conduit to actually call out to secondary library code that
> will process it. In the case of the exploits that hit the Net,
> attackers used an IFRAME hack to call out to the shell to process it.
> The shell would look up the handler for WMF, which was the Windows
> Picture Viewer that did the processing in shimgvw.dll. When the dll
> processed the WMF, it would convert it to a printable EMF format, and
> bam... we ran into problems.
>  
> With the design defect being the fact metadata can call arbitrary GDI
> code, the implementation flaw is the fact applications like IE rely so
> heavily on calling out to secondary libraries that just can't be
> trusted. Even if IE has had a strong code review, it is extremely
> probable that most of the secondary library code has not had the same
> audit scrutiny. This is a weakness to all applications, not just IE.
> When you call out to untrusted code that you don't control, you put
> the application at risk. No different than any other operating system.
> Only problem is Windows is riddled with these potential holes because
> its sharing so much of the same codebase. And in the past the teams
> rarely talk to each other to figure this out.
>  
> Code reuse is one thing, but some of the components in Windows are
> carry over from 15 years ago, and will continue to put us at risk due
> to the implementation flaws that haven't yet been found. But with such
> a huge master sources to begin with, its not something that will be
> fixed over night.
>  
> ---
> Regards,
> Dana Epp [Microsoft Security MVP]
> Blog: http://silverstr.ufies.org/blog/
>
> ------------------------------------------------------------------------
> *From:* sc-l-bounces at securecoding.org on behalf of Crispin Cowan
> *Sent:* Fri 2/3/2006 12:12 PM
> *To:* Gary McGraw
> *Cc:* Kenneth R. van Wyk; Secure Coding Mailing List
> *Subject:* Re: [SC-L] Bugs and flaws
>
> Gary McGraw wrote:
> > To cycle this all back around to the original posting, lets talk about
> > the WMF flaw in particular.  Do we believe that the best way for
> > Microsoft to find similar design problems is to do code review?  Or
> > should they use a higher level approach?
> >
> > Were they correct in saying (officially) that flaws such as WMF are hard
> > to anticipate?
> >  
> I have heard some very insightful security researchers from Microsoft
> pushing an abstract notion of "attack surface", which is the amount of
> code/data/API/whatever that is exposed to the attacker. To design for
> security, among other things, reduce your attack surface.
>
> The WMF design defect seems to be that IE has too large of an attack
> surface. There are way too many ways for unauthenticated remote web
> servers to induce the client to run way too much code with parameters
> provided by the attacker. The implementation flaw is that the WMF API in
> particular is vulnerable to malicious content.
>
> None of which strikes me as surprising, but maybe that's just me :)
>
> Crispin
> --
> Crispin Cowan, Ph.D.                     
> http://crispincowan.com/~crispin/ <http://crispincowan.com/%7Ecrispin/>
> Director of Software Engineering, Novell  http://novell.com
>         Olympic Games: The Bi-Annual Festival of Corruption
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption



From crispin at novell.com  Tue Feb  7 04:46:04 2006
From: crispin at novell.com (Crispin Cowan)
Date: Tue, 07 Feb 2006 02:46:04 -0700
Subject: [SC-L] RE: The role static analysis tools play in uncovering
	elements of design
In-Reply-To: <00a801c6294b$89b42b50$ba04a8c0@intranet.aspectsecurity.com>
References: <00a801c6294b$89b42b50$ba04a8c0@intranet.aspectsecurity.com>
Message-ID: <43E86C5C.1080700@novell.com>

Jeff Williams wrote:
> I think there's a lot more that static analysis can do than what you're
> describing. They're not (necessarily) just fancy pattern matchers.
> ...
> Today's static analysis tools are only starting to help here. Tools focused
> on dumping out a list of vulnerabilities don't work well for me. Too many
> false alarms.  Maybe that's what you meant by 'inhibit'.
>   
In the general case, I think that any kind of analysis tool (static
analyzer, fuzzing tool, debugger, whatever) focuses the analyst's
attention on whatever aspects the tool author thought was important.
Whether this is a good or bad thing depends on whether you agree with
the author.

Using no tools at all just imposes a different bias filter, as humans
are (relatively) good at spotting some kinds of patterns, and not others.

Crispin

> --Jeff
>  
> Jeff Williams, CEO
> Aspect Security
> http://www.aspectsecurity.com
> email: jeff.williams at aspectsecurity.com
> phone: 410-707-1487
>  
> ________________________________________
> From: John Steven [mailto:jsteven at cigital.com] 
> Sent: Friday, February 03, 2006 1:40 PM
> To: Jeff Williams; Secure Coding Mailing List
> Subject: The role static analysis tools play in uncovering elements of
> design 
>
> Jeff,
>
> An unpopular opinion I?ve held is that static analysis tools, while very
> helpful in finding problems, inhibit a reviewer?s ability to find collect as
> much information about the structure, flow, and idiom of code?s design as
> the reviewer might find if he/she spelunks the code manually.
>
> I find it difficult to use tools other than source code navigators (source
> insight) and scripts to facilitate my code understanding (at the
> design-level). 
>
> Perhaps you can give some examples of static analysis library/tool use that
> overcomes my prejudice?or are you referring to the navigator tools as well?
>
> -----
> John Steven                                   
> Principal, Software Security Group
> Technical Director, Office of the CTO
> 703 404 5726 - Direct | 703 727 4034 - Cell
> Cigital Inc.          | jsteven at cigital.com
>
> 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
>
>   
> ----snipped----
> Static analysis tools can help a lot here. Used properly, they can provide
> design-level insight into a software baseline. The huge advantage is that
> it's correct.
>
> --Jeff 
> ----snipped----
> ________________________________________
> This electronic message transmission contains information that may be
> confidential or privileged. The information contained herein is intended
> solely for the recipient and use by any other party is not authorized. If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited. If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message. Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ________________________________________
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>   

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption



From ljknews at mac.com  Tue Feb  7 00:21:05 2006
From: ljknews at mac.com (ljknews)
Date: Tue, 7 Feb 2006 00:21:05 -0500
Subject: [SC-L] Where to read about construction quality software
In-Reply-To: <8654C851B1DAFA4FA18A9F150145F925054D2AA0@FNEX01.fishnetsecurity.com>
References: <8654C851B1DAFA4FA18A9F150145F925054D2AA0@FNEX01.fishnetsecurity.com>
Message-ID: <p05200f06c00dddb5fffc@[192.168.1.254]>

The US Department of Homeland Security seems to be sponsoring a web site
at https://buildsecurityin.us-cert.gov/portal/ , devoted to construction
of quality software.

But feeding that URL to http://validator.w3.org/ produces a list of 277
HTML errors on that software quality page :-)

No, I don't go checking such stuff just to be ornery - it produced a blank
screen on the first browser I tried.
-- 
Larry Kilgallen


From jeff.williams at aspectsecurity.com  Tue Feb  7 09:59:23 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Tue, 7 Feb 2006 09:59:23 -0500
Subject: [SC-L] Bugs and flaws
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F1AE5@va-mail.cigital.com>
Message-ID: <04c001c62bf7$14ef9580$0e04a8c0@intranet.aspectsecurity.com>

I'm not sure which of the three definitions in Brian's message you're not
concurring with, but I think he was only listing them as strawmen anyway.

In any case, there's no reason that static analysis tools shouldn't be able
to find errors of omission. We use our tools to find these 'dogs that didn't
bark' every day.

The tools can identify, for example, places where logging, input validation,
and error handling should have been done. With a little work teaching the
tool about your application, assets, and libraries, it's easy to find places
where encryption, access control, and authentication should have been done
but haven't.

In your hypothetical, if the API isn't ever invoked with an identity and a
secret, there can't be authentication. If there's no call to an access
control component, we know at least that there's no centralized mechanism.
In this case, the tool could check whether the code follows the project's
standard access control pattern. If not, it's an error of omission.

If I remember correctly, Saltzer and Schroeder only suggested 8 principles.
Your hypo is closest to complete mediation, but touches on several others.
But, in theory, there's no reason that static analysis can't help verify all
of them in an application.

--Jeff

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Gary McGraw
Sent: Monday, February 06, 2006 11:13 PM
To: Brian Chess; sc-l at securecoding.org
Subject: RE: [SC-L] Bugs and flaws

Hi all,

I'm afraid I don't concur with this definition.  Here's a (rather vague)
flaw example that may help clarify what I mean.  Think about an error of
omission where an API is exposed with no A&A protection whatsoever.  This
API may have been designed not to have been exposed originally, but somehow
became exposed only over time.

How do you find errors of omission with a static analysis tool?  

This is only one of salzer and schroeder's principles in action.  What of
the other 9?

gem

P.s. Five points to whoever names the principle in question.

P.p.s. The book is out www.swsec.com

 -----Original Message-----
From: 	Brian Chess [mailto:brian at fortifysoftware.com]
Sent:	Sat Feb 04 00:56:16 2006
To:	sc-l at securecoding.org
Subject:	RE: [SC-L] Bugs and flaws

The best definition for "flaw" and "bug" I've heard so far is that a flaw is
a successful implementation of your intent, while a bug is unintentional.  I
think I've also heard "a bug is small", a flaw is big", but that definition
is awfully squishy.

If the difference between a bug and a flaw is indeed one of intent, then I
don't think it's a useful distinction.  Intent rarely brings with it other
dependable characteristics.

I've also heard "bugs are things that a static analysis tool can find", but
I don't think that really captures it either.  For example, it's easy for a
static analysis tool to point out that the following Java statement implies
that the program is using weak cryptography:

    SecretKey key = KeyGenerator.getInstance("DES").generateKey();

Brian

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php



From jjchryan at gwu.edu  Tue Feb  7 10:45:23 2006
From: jjchryan at gwu.edu (Julie Ryan)
Date: Tue, 7 Feb 2006 10:45:23 -0500
Subject: [SC-L] Bugs and flaws
In-Reply-To: <04c001c62bf7$14ef9580$0e04a8c0@intranet.aspectsecurity.com>
References: <04c001c62bf7$14ef9580$0e04a8c0@intranet.aspectsecurity.com>
Message-ID: <8ab41388ee33be224dc7ba175eefa24c@gwu.edu>

8 principles with 2 more from physical security that "apply only  
imperfectly to computer systems"

http://www.cap-lore.com/CapTheory/ProtInf/Basic.html


On Feb 7, 2006, at 9:59 AM, Jeff Williams wrote:

> I'm not sure which of the three definitions in Brian's message you're  
> not
> concurring with, but I think he was only listing them as strawmen  
> anyway.
>
> In any case, there's no reason that static analysis tools shouldn't be  
> able
> to find errors of omission. We use our tools to find these 'dogs that  
> didn't
> bark' every day.
>
> The tools can identify, for example, places where logging, input  
> validation,
> and error handling should have been done. With a little work teaching  
> the
> tool about your application, assets, and libraries, it's easy to find  
> places
> where encryption, access control, and authentication should have been  
> done
> but haven't.
>
> In your hypothetical, if the API isn't ever invoked with an identity  
> and a
> secret, there can't be authentication. If there's no call to an access
> control component, we know at least that there's no centralized  
> mechanism.
> In this case, the tool could check whether the code follows the  
> project's
> standard access control pattern. If not, it's an error of omission.
>
> If I remember correctly, Saltzer and Schroeder only suggested 8  
> principles.
> Your hypo is closest to complete mediation, but touches on several  
> others.
> But, in theory, there's no reason that static analysis can't help  
> verify all
> of them in an application.
>
> --Jeff
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org  
> [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Gary McGraw
> Sent: Monday, February 06, 2006 11:13 PM
> To: Brian Chess; sc-l at securecoding.org
> Subject: RE: [SC-L] Bugs and flaws
>
> Hi all,
>
> I'm afraid I don't concur with this definition.  Here's a (rather  
> vague)
> flaw example that may help clarify what I mean.  Think about an error  
> of
> omission where an API is exposed with no A&A protection whatsoever.   
> This
> API may have been designed not to have been exposed originally, but  
> somehow
> became exposed only over time.
>
> How do you find errors of omission with a static analysis tool?
>
> This is only one of salzer and schroeder's principles in action.  What  
> of
> the other 9?
>
> gem
>
> P.s. Five points to whoever names the principle in question.
>
> P.p.s. The book is out www.swsec.com
>
>  -----Original Message-----
> From: 	Brian Chess [mailto:brian at fortifysoftware.com]
> Sent:	Sat Feb 04 00:56:16 2006
> To:	sc-l at securecoding.org
> Subject:	RE: [SC-L] Bugs and flaws
>
> The best definition for "flaw" and "bug" I've heard so far is that a  
> flaw is
> a successful implementation of your intent, while a bug is  
> unintentional.  I
> think I've also heard "a bug is small", a flaw is big", but that  
> definition
> is awfully squishy.
>
> If the difference between a bug and a flaw is indeed one of intent,  
> then I
> don't think it's a useful distinction.  Intent rarely brings with it  
> other
> dependable characteristics.
>
> I've also heard "bugs are things that a static analysis tool can  
> find", but
> I don't think that really captures it either.  For example, it's easy  
> for a
> static analysis tool to point out that the following Java statement  
> implies
> that the program is using weak cryptography:
>
>     SecretKey key = KeyGenerator.getInstance("DES").generateKey();
>
> Brian
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -  
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at -  
> http://www.securecoding.org/list/charter.php
>
>
>
>
> ----------------------------------------------------------------------- 
> -----
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is  
> intended
> solely for the recipient and use by any other party is not authorized.  
>  If
> you are not the intended recipient (or otherwise authorized to receive  
> this
> message by the intended recipient), any disclosure, copying,  
> distribution or
> use of the contents of the information is prohibited.  If you have  
> received
> this electronic message transmission in error, please contact the  
> sender by
> reply email and delete all copies of this message.  Cigital, Inc.  
> accepts no
> responsibility for any loss or damage resulting directly or indirectly  
> from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------- 
> -----
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -  
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at -  
> http://www.securecoding.org/list/charter.php
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -  
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at -  
> http://www.securecoding.org/list/charter.php
>
Julie J.C.H. Ryan, D.Sc.
Assistant Professor
Engineering Management and System Engineering
George Washington University

An NSA certified Center of Academic Excellence in Information Assurance  
Education

http://www.seas.gwu.edu/~jjchryan/
http://www.seas.gwu.edu/~infosec/


From gunnar at arctecgroup.net  Tue Feb  7 17:56:26 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue,  7 Feb 2006 16:56:26 -0600
Subject: [SC-L] Bugs and flaws
In-Reply-To: <04c001c62bf7$14ef9580$0e04a8c0@intranet.aspectsecurity.com>
References: <04c001c62bf7$14ef9580$0e04a8c0@intranet.aspectsecurity.com>
Message-ID: <1139352986.43e9259a5dae4@my.visi.com>

Perhaps a useful distinction that we could to assign responsibility is to
separate concerns in algorithms from the concerns of the system as a whole.
Butler Lampson describes how designing a computer system is different from
designing an algorithm:

"The external interface (that is, the requirement) is less precisely defined,
more complex, and more subject to change.
The system has much more internal structure, and hence many internal interfaces.
The measure of success is much less clear."

In the WMF case was the system supposed to protect the algorithm or should the
algorithm have been able to defend itself?

-gp


>  -----Original Message-----
> From: 	Brian Chess [mailto:brian at fortifysoftware.com]
> Sent:	Sat Feb 04 00:56:16 2006
> To:	sc-l at securecoding.org
> Subject:	RE: [SC-L] Bugs and flaws
>
> The best definition for "flaw" and "bug" I've heard so far is that a flaw is
> a successful implementation of your intent, while a bug is unintentional.  I
> think I've also heard "a bug is small", a flaw is big", but that definition
> is awfully squishy.
>
> If the difference between a bug and a flaw is indeed one of intent, then I
> don't think it's a useful distinction.  Intent rarely brings with it other
> dependable characteristics.
>
> I've also heard "bugs are things that a static analysis tool can find", but
> I don't think that really captures it either.  For example, it's easy for a
> static analysis tool to point out that the following Java statement implies
> that the program is using weak cryptography:
>
>     SecretKey key = KeyGenerator.getInstance("DES").generateKey();
>
> Brian
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
>
>
>
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>



From Arian.Evans at fishnetsecurity.com  Wed Feb  8 13:36:32 2006
From: Arian.Evans at fishnetsecurity.com (Evans, Arian)
Date: Wed, 8 Feb 2006 12:36:32 -0600
Subject: [SC-L] (Software Risk)--was-->Bugs and flaws
Message-ID: <8654C851B1DAFA4FA18A9F150145F925055C183A@FNEX01.fishnetsecurity.com>

Before I go further, the second version of the email below
(the rewritten & readable one that made the list) has some
specific outlines and questions...there is *clearly* much
common ground here but lacking a standardized frame of reference
for language...how do we go about shoring up our terminology?

IEEE? Whitepaper? Wait until a book seeps into our collective
dialogue (if)? Completely unrealistic goal?

Per Risk, I think we have no business discussing Risk in this
context, and I avidly delete it from any scope of work I get my
hands on; we can provide raw material to enhance accuracy of Risk
analysis, but IRL Risk != CISSP def (threat of loss * likelihood
of occurrence * 3.14159). Risk = Loss (or impact, which ultimately
leads to some form of loss) to any C lvl or internal audit function.

The breakdown I have been using is RTAWV...the definitions are
currently liquid and running:

Risk (loss or impact (which usually results in loss in the long run))

Threat (what is the potential issue that creates Risk, implication of an attack?)

Attack (what vehicle to actualize a Threat; exploit vector)

Weakness (what is the pattern/condition that results in potential for Attackability?
...or, "why" can a thing be exploited and how did it get that way?)

Vulnerability (what is the particular (unique or plural instance) that can be exploited)

----

Here is a rough webified example:

Risk
Financial Loss, Repudiation, Market Goodwill (impact == loss == $$$$$)

Threat
Elevation of Privilege; Forged Transaction

Attack (A: Spoofing of User Identity)
A1 Session Fixation
A1-2 Session Token Multiple Entity Re-use

Weakness
Insecure Authorization Mechanism; session tokens not tied to authentication state
Insecure Session Handling; session tokens lack relative and absolute use conditions,
and have no entity-use restrictions

Vulnerability(ies)
Session token set a priori authentication on page X
Session token infinite harvesting by unique entity (IP) on pages X,Y

Architecture:
If there is a finding here, it is more along the lines of "you picked a
framework that abstracts the session handling to an object level that
provides you no visibility or manual control over what goes on under the
hood, and you have no technical specification concerning session handling
other than "sticky, and no explicitly defined security goals"

Implementation:
Clearly, there several simple implementation issues here, and maybe a few
tricky ones if you don't keep session state in a db or somewhere that you
can easily perform some correlation between A&A and entity & actual session
tokens in use (the cookies, perhaps).

Thoughts?

I am ultimately concerned about how we standardize the technical
language (e.g.-defect analysis and categorization discussion) since
the business language already exists.

-ae




> -----Original Message-----
> From: Gary McGraw [mailto:gem at cigital.com] 
> Sent: Monday, February 06, 2006 10:13 PM
> To: Evans, Arian; Crispin Cowan; Secure Coding Mailing List; 
> Kenneth R. van Wyk
> Subject: RE: [SC-L] Bugs and flaws
> 
> 
> I'm with you on this threat modeling thing...which is the 
> process  meant to lay flaws bare.  I like to call it "risk 
> analysis" of course (using american war nomenclature instead 
> of british/australian).  STRIDE is an important step in the 
> right direction, but a checklist approach has essential 
> creativity constraints worth pondering.
> 
> My only point in making the distinction clear (bugs vs flaws) 
> is to make sure that we don't forget design, requirements, 
> and early lifecycle artifacts in our rush to analyze code.
> 
> Please do both (touchpoints 1 and 2 in Software Security).
> 
> gem
> 
>  -----Original Message-----
> From: 	Evans, Arian [mailto:Arian.Evans at fishnetsecurity.com]
> Sent:	Fri Feb 03 18:29:29 2006
> To:	Crispin Cowan; Gary McGraw; Secure Coding Mailing List; 
> Kenneth R. van Wyk
> Subject:	RE: [SC-L] Bugs and flaws
> 
> per WMF// Let's face it, this was legacy, possibly deprecated 
> code that
> was likely low on the security things-to-do list. I suspect 
> MS, like the
> rest of the world, has resource limitations regarding 
> analyzing all their
> various product/api entry points for security implications.
> 
> Which is one of the reasons I think threat modeling came in 
> vogue, and I
> think a threat model would flag this in bright red for review, but you
> need resources with quite a bit of knowledge and time to 
> build that model,
> and again, since this was legacy functionality...
> 
> fyi// on attack surface: http://www-2.cs.cmu.edu/~wing/
> 
> There are several ppls that have done nice work here; it fits 
> hand-in-glove
> with threat modeling concepts, which fits hand in glove with 
> this whole
> equivocal dialogue about design/implementation verbiage.
> 
> This whole discussion underscores the real issue we have, which is
> a common language.
> 
> So how to fix it? A taxonomy and terminology guide; simple, concise.
> 
> There's plenty of folks on this list a lot smarter than I am, so it is
> nice to see that a majority agree on what I think the key issues are:
> communicating (a) accurate and (b) actionable data, or expanded:
> 
> 1. Defect Definition
> 2. Defect Classification
> 3. Defect Identification
> 4. Defect Implication (communicating defect implication as goal)
> 
> By example I mean:
> 
> 1. Format String, weak crypto use, define what & why are 
> these security defects?
> 2. Implementation Defect, Design Defect, bug, flaw, blah
> 3. How do we identify these defects in software?
> 4. Implication: RTAWV (Risk, Threat, Attack, Weakness, Vuln) 
> & communication
> to both technical, and non-technical audience.
> 
> I added Weakness at the TRIKE group's suggestion, and it has 
> significantly
> helped in classification instead of using two confusing vuln 
> categories.
> 
> There is obviously a many-to-one mapping between 
> threat->attack<-weakness
> and even from vuln to weakness, depending on how we define 
> vuln. (I have
> defined vuln as "a particular instance or attackable instance 
> of a weakness").
> 
> This is *valuable* information to the person trying to solve 
> issues in this
> problem domain, but I rarely find it well understood by 
> non-appsec folks.
> 
> I have attempted to address and communicate this in a short 
> paper titled:
> ::Taxonomy of Software Security Analysis Types:: 
> 
> (Software Security Analysis == defined as == Software 
> Analysis for Defects
> with Security Implications, implications being contextual.)
> 
> Is significantly weakened if at the end of the day no one 
> knows what I mean
> by design weakness, implementation defect, goblins, etc. So I 
> will need
> all your help in shoring up the language.
> 
> My reason for distinction of "security as a defect 
> implication" is that
> defects are sometimes clear; the implications are not always 
> clear and do
> not always follow from the defects. Defects are neither a 
> necessary nor
> sufficient condition for security implications (obviously), but it the
> implications most people solving problems care about, not 
> defect language.
> 
> Much of this is underscored in the IEEE software defect 
> terminology, but
> look at our current industry ambiguity between attacks and 
> vulnerabilities!
> 
> I continue to encounter wildly equivocal uses of the words 
> Threat, Attack,
> Vulnerability, Flaw, Defect, Artifact (and associated phrases 
> like "security-
> artifact"), Fault, Bug, Error, Failure, Mistake, MFV 
> (multi-factor vulnerability)
> in our collective software security dialogue and literature.
> 
> I am *not* *married* to any particular verbiage; my goal is a common
> language so we can have more effective dialogue,
> 
> Arian J. Evans
> FishNet Security
> 
> 816.421.6611 [fns office]
> 816.701.2045 [direct] <--limited access
> 888.732.9406 [fns toll-free]
> 816.421.6677 [fns general fax]
> 913.710.7045 [mobile] <--best bet
> aevans at fishnetsecurity.com [email]
> 
> http://www.fishnetsecurity.com
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: sc-l-bounces at securecoding.org 
> > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Crispin Cowan
> > Sent: Friday, February 03, 2006 2:12 PM
> > To: Gary McGraw
> > Cc: Kenneth R. van Wyk; Secure Coding Mailing List
> > Subject: Re: [SC-L] Bugs and flaws
> > 
> > 
> > Gary McGraw wrote:
> > > To cycle this all back around to the original posting, lets 
> > talk about
> > > the WMF flaw in particular.  Do we believe that the best way for
> > > Microsoft to find similar design problems is to do code 
> review?  Or
> > > should they use a higher level approach?
> > >
> > > Were they correct in saying (officially) that flaws such as 
> > WMF are hard
> > > to anticipate? 
> > >   
> > I have heard some very insightful security researchers from 
> Microsoft
> > pushing an abstract notion of "attack surface", which is 
> the amount of
> > code/data/API/whatever that is exposed to the attacker. To 
> design for
> > security, among other things, reduce your attack surface.
> > 
> > The WMF design defect seems to be that IE has too large of an attack
> > surface. There are way too many ways for unauthenticated remote web
> > servers to induce the client to run way too much code with 
> parameters
> > provided by the attacker. The implementation flaw is that the 
> > WMF API in
> > particular is vulnerable to malicious content.
> > 
> > None of which strikes me as surprising, but maybe that's just me :)
> > 
> > Crispin
> > -- 
> > Crispin Cowan, Ph.D.                      
> > http://crispincowan.com/~crispin/
> > Director of Software Engineering, Novell  http://novell.com
> > 	Olympic Games: The Bi-Annual Festival of Corruption
> > 
> > 
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org
> > List information, subscriptions, etc - 
> > http://krvw.com/mailman/listinfo/sc-l
> > List charter available at - 
> > http://www.securecoding.org/list/charter.php
> > 
> 
> 
> 
> 
> --------------------------------------------------------------
> --------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein 
> is intended
> solely for the recipient and use by any other party is not 
> authorized.  If
> you are not the intended recipient (or otherwise authorized 
> to receive this
> message by the intended recipient), any disclosure, copying, 
> distribution or
> use of the contents of the information is prohibited.  If you 
> have received
> this electronic message transmission in error, please contact 
> the sender by
> reply email and delete all copies of this message.  Cigital, 
> Inc. accepts no
> responsibility for any loss or damage resulting directly or 
> indirectly from
> the use of this email or its contents.
> Thank You.
> --------------------------------------------------------------
> --------------
> 



From petesh at indigo.ie  Wed Feb  8 21:01:47 2006
From: petesh at indigo.ie (Pete Shanahan)
Date: Thu, 09 Feb 2006 02:01:47 +0000
Subject: [SC-L] boundaries/responsibilities
Message-ID: <43EAA28B.9000001@indigo.ie>

While I'm riveted by the bug versus flaw debate - as it fundamentally
illustrates the importance of discussing things from the same premise(*), I have
what I would consider to be an interesting tangential issue that has been
bothering me for several years.
I've written many programs (in C, C++) and have never made much effort to make
them input safe. I generally made sure that buffers could not be overrun by
using the 'n' versions of the string functions, and I didn't consider the task
too heavily.
The problem is that my code is in far wider and more varied an environment than
I had ever expected, and I am now concerned that I may be exposed to some form
of liability. This is due to the code having not been issued with any specific
exclusion of warranty; such as would be present in the agreement for the Java
language/environment.


(*) It was my logic lecturer who had an anecdote about two men arguing from
different buildings. A man walks along during one of the arguments and shouts to
the both of them that they will never agree as they are arguing from different
premises.

-- 
Pete	+353 (87) 412 9576 [M] | +353 (66) 71 42367 [H]


From ge at linuxbox.org  Thu Feb  9 01:01:52 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Thu, 09 Feb 2006 08:01:52 +0200
Subject: [SC-L] it's not a bug, it's a feature!
Message-ID: <43EADAD0.8080005@linuxbox.org>

Okay, if we are so keen to make distinctions, how about this one?

In the recent WMF 0day, it was indeed a feature. But it was a security 
vulnerability non-the-less. PR-ing it as a feature was indeed, PR.

Cisco released a security advisory, advising that a default root 
password is a "vulnerability" rather than a built-in feature. :)

It seems that people often enjoy making the distinction for putting the 
right spin on things. Myself, I like this quote:
"Any sufficiently advanced bug is indistinguishable from a feature".
A spin on Arthur C. Clarke's 3rd law.

I learned just a few months ago (last year :) ) that it was coined 20 
years ago by someone many of us know: Rich Kulawiec.

What is your take on this, should this be a huge argument as well? :)

	Gadi.


From ge at linuxbox.org  Thu Feb  9 01:08:54 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Thu, 09 Feb 2006 08:08:54 +0200
Subject: [SC-L] static analysis you say?
Message-ID: <43EADC76.9010704@linuxbox.org>

Just last month Greta Yorsh, fresh from work in Microsoft Research over 
in the US lectured to us on something related in TAUSEC 
(http://www.cs.tau.ac.il/tausec - in Hebrew).

-----
Title: Testing, Abstraction, Theorem Proving: Better Together.

We present a method for static program analysis that leverages tests
and concrete program executions.  State abstractions generalizes the
set of program states obtained from concrete executions.  A theorem
prover is then used for checking that the generalized set of concrete
states covers all potential executions, and
satisfies additional safety properties.

Our method finds the same potential errors as the most-precise abstract
interpreter for a given abstraction, and potentially more efficient.
Additionally, it provides a new
way to tune performance by alternating between concrete execution and
theorem proving.
-----

Anyone follow that? I didn't.

VERY basically put, she showed a system that was developed over 5 years 
that abstracts static code such as of device drivers to a simple boolean 
program, and then follows the code to find errors. Later comparing these 
errors to a run on a tad less abstracted program to see if the error is 
really there.

^^^ That is probably the worst description you will ever hear of SLAM.

She claims that with her research (not SLAM) she can prove 
mathematically a program is secure.. erm. She was a very impressive 
lecturer and almost convinced me, I really was impressed.

Here are some links from her lecture (ignore the first line which is in 
Hebrew):
http://www.cs.tau.ac.il/tausec/lectures/Greta_Yorsh_links.html

	Gadi.


From gem at cigital.com  Thu Feb  9 09:56:31 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 9 Feb 2006 09:56:31 -0500
Subject: [SC-L] it's not a bug, it's a feature!
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F1C90@va-mail.cigital.com>

Nope!

gem

 -----Original Message-----
From: 	Gadi Evron [mailto:ge at linuxbox.org]
Sent:	Thu Feb 09 09:50:21 2006
To:	sc-l at securecoding.org
Subject:	[SC-L] it's not a bug, it's a feature!

Okay, if we are so keen to make distinctions, how about this one?

In the recent WMF 0day, it was indeed a feature. But it was a security 
vulnerability non-the-less. PR-ing it as a feature was indeed, PR.

Cisco released a security advisory, advising that a default root 
password is a "vulnerability" rather than a built-in feature. :)

It seems that people often enjoy making the distinction for putting the 
right spin on things. Myself, I like this quote:
"Any sufficiently advanced bug is indistinguishable from a feature".
A spin on Arthur C. Clarke's 3rd law.

I learned just a few months ago (last year :) ) that it was coined 20 
years ago by someone many of us know: Rich Kulawiec.

What is your take on this, should this be a huge argument as well? :)

	Gadi.
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Mon Feb 13 15:06:41 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 13 Feb 2006 15:06:41 -0500
Subject: [SC-L] RSA book signing
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F1E4E@va-mail.cigital.com>

Hi all,

>From the "in case you care" dept...

I'll be at RSA doing the official launch of the book this week.  If you
happen to be there, please stop by the bookstore on Tuesday between 1:30
and 2:00 for the book signing thing. 

Software security lives!

gem

p.s. www.swsec.com


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From Ken at krvw.com  Mon Feb 13 17:00:14 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Mon, 13 Feb 2006 17:00:14 -0500
Subject: [SC-L] Book review: Essential PHP Security
Message-ID: <200602131700.14791@KRvW>

I know that a lot of the folks on this list would consider the words "PHP 
Security" to be an oxymoron.  That said, there's a book out on the subject, 
and it's been reviewed on /.  The review can be found at:

http://books.slashdot.org/books/06/02/13/1426220.shtml

Cheers,

Ken van Wyk

P.S. It was nice to see a few SC-L folks at S3 in San Diego last week.
-- 
KRvW Associates, LLC
http://www.KRvW.com


From ken at krvw.com  Wed Feb 15 10:36:09 2006
From: ken at krvw.com (Kenneth R. van Wyk)
Date: Wed, 15 Feb 2006 10:36:09 -0500 (EST)
Subject: [SC-L] AJAX security paper
Message-ID: <4067.128.237.251.223.1140017769.squirrel@mail.krvw.com>

FYI, here's a pointer to a just-published paper on AJAX security.  Hope you find it useful,
particularly in light of AJAX's quick rise in popularity.

http://www.it-observer.com/articles/1062/ajax_security/

Cheers,

Ken
-- 
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




From gem at cigital.com  Wed Feb 15 12:46:49 2006
From: gem at cigital.com (Gary McGraw)
Date: Wed, 15 Feb 2006 12:46:49 -0500
Subject: [SC-L] Freedom to tinker
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F1F2E@va-mail.cigital.com>


Hi all,

RSA is going well this year.  Of interest is the fact that there are at least six presentations focused directly on software security.  Very cool.

Ed Felten (my Java Security co-author and famous Princeton professor) has a blog called Freedom to Tinker.  He is graciously allowing me to do some posting of book excerpts from Software Security there.  The first can be found here:  http://www.freedom-to-tinker.com/?p=976

gem

www.swsec.com


Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Thu Feb 16 10:49:05 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 16 Feb 2006 10:49:05 -0500
Subject: [SC-L] Podcast
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB5F1F56@va-mail.cigital.com>


Hi all,

Now that there is no more techtv, the biggest media hit you can get seems to be podcasts.  It just ain't the same.

A podcast from RSA about the book by victor garza can be found here
weblog.infoworld.com/zeroday

2 panels today at RSA.  Come see em if you're here.

gem


Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From dave.wichers at aspectsecurity.com  Fri Feb 17 10:16:06 2006
From: dave.wichers at aspectsecurity.com (Dave Wichers)
Date: Fri, 17 Feb 2006 10:16:06 -0500
Subject: [SC-L] Call For Papers: 2006 OWASP AppSec Europe Conference
Message-ID: <003d01c633d5$13449470$6c01a8c0@intranet.aspectsecurity.com>

Call For Papers - Refereed Papers Track at OWASP AppSec 
Europe 2006 Conference 


The Open Web Application Security Project (OWASP, 
http://www.owasp.org) is dedicated to finding and 
fighting the causes of insecure software. OWASP has 
dozens of projects and over 50 chapters worldwide 
focused on application security. Our high quality 
tools and documentation are used everywhere, 
including the freely available book-length "Guide 
to Secure Web Applications and Services", the leading 
web application penetration testing tool called 
"WebScarab", and an advanced web application security 
training application called "WebGoat". 
The OWASP Foundation, a not-for-profit charitable 
organization, ensures the ongoing availability and 
support for this work.

The OWASP AppSec conferences 
(http://www.owasp.org/conferences.html) bring together 
application security experts, researchers and 
practitioners from all over the world. 
Industry and academia can meet to discuss open problems 
and new solutions in application security. 
The conferences offer tutorials, keynotes, and invited 
presentations. 
  
For the first time, the 2006 OWASP AppSec Europe 
conference will feature refereed papers. Original research 
papers pertaining to all aspects of web application 
security are solicited. Papers should describe new ideas, 
new implementations, or experiences related to web 
application security. 

Topics of interest include, but are not limited to: 

 - Web application security 
 - Threat modeling of web applications 
 - Vulnerability analysis of web applications (code review, 
   pentest, static analysis, scanning) 
 - Countermeasures for web application vulnerabilities 
 - Secure coding techniques 
 - Static and dynamic analysis of web application technologies 
 - Platform or language (e.g. Java, .NET) security features 
   that help secure web applications 
 - Open source framework features that help secure web applications
 - How to use databases securely in web applications 
 - Experiences or new ideas on Secure Development Lifecycles (SDLC) 
 - Experiences using web application security scanning or code 
   analysis tools 
 - Access control in web applications 
 - Web services security 

It is the intention of the organizers to publish accepted 
papers in a conference proceedings. 


Important dates: 

Submission deadline (Draft Paper): March 20
Notification of acceptance: April 20 
Final version due: May 20 
Conference: May 29-31, 2006 (May 29 training 
day) (May 30-31 Conference) 

Instructions for authors:

Submitted papers should not substantially overlap with papers 
that have been published. Submissions should be at most 12 pages 
long in the Springer LNCS Style for Proceedings and Other 
Multiauthor Volumes. 
Templates for preparing papers in this style for LaTeX, Word, 
and other word processors can be downloaded from:
http://www.springer.com/sgw/cda/frontpage/0,11855,5-164-2-72376-0,00.html

All submissions should be sent in Adobe Portable Document 
Format (pdf) to Frank Piessens at 
Frank.Piessens_at_cs.kuleuven.ac.be.

Programme Committee: 
Konstantin Beznosov, University of British Columbia, Canada
Sebastien Deleersnyder, Ascure and OWASP Belgian Chapter, Belgium
Andreas Fuchsberger, Royal Holloway, University of London, UK
Andre Marien, Ubizen, Belgium
Mattia Monga, Milan University, Italy
Johan Peeters, secappdev.org, Belgium
Frank Piessens, Katholieke Universiteit Leuven, Belgium (chair)
Erik Poll, Radboud Universiteit Nijmegen, The Netherlands
Maarten Rits, SAP Research, France
Chris Vanden Berghe, IBM Research, Switzerland




From gem at cigital.com  Tue Feb 21 11:02:36 2006
From: gem at cigital.com (Gary McGraw)
Date: Tue, 21 Feb 2006 11:02:36 -0500
Subject: [SC-L] BSI: SOA what?
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4211C7@va-mail.cigital.com>

Hi all,

I'm sure by now everyone has heard at least one marketing person say SOA
in some capacity.  Such it is with buzzwords.  Looks like we're still
climbing the hype curve with this one too.  The one great opportunity
with SOA (or Service Oriented Architecture for those allergic to
acronyms) is that during a rearchitecting exercise, software security
can play a critical role.  Avoid flaws when rearchitecting by applying
the architectural risk analysis touchpoint!

IEEE Security & Privacy magazine published an article that Jeremy, Scott
Matsumoto, and I wrote about SOA security.  You can get it here:
http://www.cigital.com/papers/download/bsi12-soa.doc.pdf

Please consider subscribing to IEEE S&P.  It's a great magazine and a
bargain at only $29 (no IEEE membership required).  See
http://www.computer.org/security/bsisub for more.

gem
www.swsec.com

p.s. I recently updated my home page after, oh, three or four years...
www.cigital.com/~gem 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gunnar at arctecgroup.net  Wed Feb 22 09:08:00 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Wed, 22 Feb 2006 08:08:00 -0600
Subject: [SC-L] BSI: SOA what?
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4211C7@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4211C7@va-mail.cigital.com>
Message-ID: <1140617280.43fc70403f3fb@my.visi.com>

Good stuff, you (and your co-authors) are right: SOA and Web Services are
properly viewed as opportunities for security improvements, not security
nightmares.

Also, I have a paper here (http://www.arctecgroup.net/ISB1009GP.pdf) on Service
Oriented Security (SOS) Architecture

-gp

Quoting Gary McGraw <gem at cigital.com>:

> Hi all,
>
> I'm sure by now everyone has heard at least one marketing person say SOA
> in some capacity.  Such it is with buzzwords.  Looks like we're still
> climbing the hype curve with this one too.  The one great opportunity
> with SOA (or Service Oriented Architecture for those allergic to
> acronyms) is that during a rearchitecting exercise, software security
> can play a critical role.  Avoid flaws when rearchitecting by applying
> the architectural risk analysis touchpoint!
>
> IEEE Security & Privacy magazine published an article that Jeremy, Scott
> Matsumoto, and I wrote about SOA security.  You can get it here:
> http://www.cigital.com/papers/download/bsi12-soa.doc.pdf
>
> Please consider subscribing to IEEE S&P.  It's a great magazine and a
> bargain at only $29 (no IEEE membership required).  See
> http://www.computer.org/security/bsisub for more.
>
> gem
> www.swsec.com
>
> p.s. I recently updated my home page after, oh, three or four years...
> www.cigital.com/~gem
>
>
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>



From gunnar at arctecgroup.net  Tue Feb 28 18:38:49 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue, 28 Feb 2006 17:38:49 -0600
Subject: [SC-L] eWeek: AJAX Poses Security, Performance Risks
In-Reply-To: <43E055CE.3060705@novell.com>
References: <200601301309.30078@KRvW> <p05200f12c0041746babe@[192.168.1.254]>
	<43E055CE.3060705@novell.com>
Message-ID: <EF65B9BC-8E04-460A-9BD5-C91305C9D800@arctecgroup.net>

a lot of this gets back to a "framework versus roll your own debate"

http://1raindrop.typepad.com/1_raindrop/2005/05/wsmex_v_httpget.html
&
http://www.identityblog.com/2005/04/30.html#a210

also, for some good context security in ajax, rest, et. al. as well  
as examples of how amazon and google deals with security check out  
mark o'neill's deck from rsa:
http://radio.weblogs.com/0111797/2006/02/20.html#a44

-gp

On Feb 1, 2006, at 12:31 AM, Crispin Cowan wrote:

> ljknews wrote:
>> I have been involved in a dialog with AJAX fans (which is  
>> different from
>> experts) who say "you security folks just have to bow to the  
>> inevitable
>> and figure out how to secure whatever mechanism we come up with.
>>
> This attitude is not unique to AJAX advocates. I remember holding this
> view myself, while wrestling with the problems of producing a truly
> transparent distributed operating system in the late 1980s and early
> 1990s; security was a bother that made things hard(er).
>
> Of course, this is just lifetime employment for security people :) I
> have certainly made a career out of securing things that are  
> inherently
> insecure.
>
> Crispin
> -- 
> Crispin Cowan, Ph.D.                      http://crispincowan.com/ 
> ~crispin/
> Director of Software Engineering, Novell  http://novell.com
> 	Olympic Games: The Bi-Annual Festival of Corruption
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/ 
> listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/ 
> charter.php



From gem at cigital.com  Thu Mar  2 22:44:43 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 2 Mar 2006 22:44:43 -0500
Subject: [SC-L] Software security hits the big time
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB64B139@va-mail.cigital.com>


Though I must admit that I was most disappointed with my diminuitive SANS review (by a person who admits to never having even seen the new book), my life has been salvaged by my local paper.

Turns out if you read closely, that software security has become a lifestyle.

Does that involve polyesther in any way??

www.timescommunity.com/site/tab3.cfm?newsid=16224110&BRD=2553&PAG=461&dept_id=506078&rfi=6

gem


Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From band at acm.org  Sun Mar  5 12:35:23 2006
From: band at acm.org (William L. Anderson)
Date: Sun, 05 Mar 2006 12:35:23 -0500
Subject: [SC-L] Question about the terms "encypt" and "secure"
Message-ID: <440B215B.5040500@acm.org>

Today's NYTimes has an article about "piggybacking" on open wireless
networks and what some people think about it and what some are doing
about it. The link is:
http://www.nytimes.com/2006/03/05/technology/05wireless.html
(subscription may be req'd)

One question popped up for me when I read the following sentence:

"For the Brodeurs in Los Angeles, a close reading of their network's
manual helped them to finally encrypt their network."

My question is whether it's more accurate to say "secure their network"
rather than "encrypt". I'm not clear myself about the meaning of these
terms; I think of encryption as being one way to make a network secure.

And if there is a substantive difference in these terms, then I'd like
to understand it. I believe that a better understanding of security
would help ordinary users take more secure actions. I'm an optimist.

-Bill Anderson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4546 bytes
Desc: S/MIME Cryptographic Signature
Url : http://krvw.com/pipermail/sc-l/attachments/20060305/4165b1c4/attachment.bin 

From gem at cigital.com  Sun Mar  5 13:19:40 2006
From: gem at cigital.com (Gary McGraw)
Date: Sun, 5 Mar 2006 13:19:40 -0500
Subject: [SC-L] Interview on informIT
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB42127C@va-mail.cigital.com>

Hi all,
 
Here's some more coverage of the book.  I hope you find this interview as interesting to read as I did working on it (last week).  Please pass it on!
 
http://www.informit.com/guides/content.asp?g=security&seqNum=181&rl=1
 
gem


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From ljknews at mac.com  Mon Mar  6 07:59:35 2006
From: ljknews at mac.com (ljknews)
Date: Mon, 6 Mar 2006 07:59:35 -0500
Subject: [SC-L] Question about the terms "encypt" and "secure"
In-Reply-To: <440B215B.5040500@acm.org>
References: <440B215B.5040500@acm.org>
Message-ID: <p05200f0ec031e24d54c8@[192.168.1.254]>

At 12:35 PM -0500 3/5/06, William L. Anderson wrote:

> My question is whether it's more accurate to say "secure their network"
> rather than "encrypt". I'm not clear myself about the meaning of these
> terms; I think of encryption as being one way to make a network secure.

Another way that was described some years ago was Marine Guards every 5
feet down the Thick Ethernet cable to prevent unauthorized taps.  Of
course that was by someone in the cryptographic business :-)
-- 
Larry Kilgallen


From gem at cigital.com  Mon Mar  6 08:42:01 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 6 Mar 2006 08:42:01 -0500
Subject: [SC-L] Question about the terms "encypt" and "secure"
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4212B4@va-mail.cigital.com>

This is a very good question and is worth a careful answer.

For most "off the shelf" users and press people, "securing" and
"encrypting traffic on" do amount to the same thing when it comes to
wireless networks.  In this case, the encryption they turn on is
hopefully WPA and not WEP.  Early versions of 802.11b were not secure
even when WEP was enabled.  (Possibly the most interesting invasion of
privacy around that problem was the X10 camera interception attack:
http://www.g4tv.com/techtvvault/features/36722/Cracking_X10_Cams.html).
The problem was a serious design flaw in WEP itself...that's the kind of
stuff we all talk about here.  Google up Avi Rubin's WEP crack work.

But turning the security feature "on" may not be enough to really secure
a wireless installation.  Some people go to great lengths to re-key
often, hardwire MAC addresses, etc to protect their wireless networks.
It all depends on what you use your wireless net for.

My wireless net is completely open out at my house.  But the nearest
neighbor is 1/2 a mile away.  For someone to steal my signal without
investing in a more powerful antenna, they would be very much visible
from the house.  (BTW, this is not an invitation to come borrow my
wireless net bruce!)

There are a number of good books on wireless security.  The one I
recommend most highly is Bill Arbaugh's book
http://www.amazon.com/gp/product/0321136209/qid=1141652351/sr=1-2/ref=sr
_1_2/102-4633854-8331342?s=books&v=glance&n=283155.  I am also a fan of
Bruce Potter's book
http://www.amazon.com/gp/product/0596100523/ref=pd_bxgy_img_b/102-463385
4-8331342?%5Fencoding=UTF8.

For the purposes of this list, we use the term "securing" to mean
"designing and implementing properly"...sometimes with the additional
implied "oh yeah and installing and operating properly too."

As Mike Howard says pithily, "software security is not security
software."

gem
www.swsec.com 




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From jeremy.epstein at webmethods.com  Mon Mar  6 09:04:12 2006
From: jeremy.epstein at webmethods.com (Jeremy Epstein)
Date: Mon, 6 Mar 2006 06:04:12 -0800 
Subject: [SC-L] Question about the terms "encypt" and "secure"
Message-ID: <5B10E50E14A4594EB1B5566B69AD94070D1AAE89@maileast>

Encryption is one way to secure the *transport* on the network (subject to
various caveats about appropriate use of crypto, trust issues, etc.).  I'd
strongly disagree with anyone who says that encryption "makes a network
secure" - because people interpret that to mean "if I encrypt the network, I
don't need to do anything else".  In fact, there's lots of other things you
need to do, such as authenticating the actions, ensuring you have adequate
audit trails, ensuring that there are no security vulnerabilities, etc.
Some people consider that to be host security as a separate topic, and so
for them, encryption *does* secure the network.  But I get nervous when
someone says encryption secures the network, lest it be considered as an
excuse to ignore all the other problems.

WRT the Marine Guards approach, years ago another approach was to run cables
through pressurized conduits with sensors to detect if anyone tampered with
the conduit before they could tap into the line.  No idea if this is still
done, or if there are new attacks possible (e.g., measuring the power
leakage from the conduits).  At that time, "Orange Book" evaluations weren't
allowed to rely on cryptography as a security measure, so a network
evaluation I worked on suggested using the Marine Guards approach.  Not that
we expected anyone to do it, but it was the only way to get past the
ridiculous requirement...

--Jeremy

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of ljknews
> Sent: Monday, March 06, 2006 8:00 AM
> To: Secure Coding Mailing List
> Subject: Re: [SC-L] Question about the terms "encypt" and "secure"
> 
> At 12:35 PM -0500 3/5/06, William L. Anderson wrote:
> 
> > My question is whether it's more accurate to say "secure 
> their network"
> > rather than "encrypt". I'm not clear myself about the 
> meaning of these 
> > terms; I think of encryption as being one way to make a 
> network secure.
> 
> Another way that was described some years ago was Marine 
> Guards every 5 feet down the Thick Ethernet cable to prevent 
> unauthorized taps.  Of course that was by someone in the 
> cryptographic business :-)
> --
> Larry Kilgallen
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 


From kentaro.arai at avanade.com  Mon Mar  6 08:48:51 2006
From: kentaro.arai at avanade.com (Kentaro Arai)
Date: Mon, 6 Mar 2006 05:48:51 -0800
Subject: [SC-L] Is there any Security problem in Ajax technology?
Message-ID: <425E0A476CF1DA4E967A34A904D1DB1E11D61A5E@MAIL1.corp.avanade.org>



Hi, All

I'm designing a web application with Ajax technology and .NET
Framework1.1.
Do I need to consider any security problem, using the Ajax technology?

Kentaro Arai



From drwachd at sandia.gov  Mon Mar  6 10:04:11 2006
From: drwachd at sandia.gov (Wachdorf, Daniel R)
Date: Mon, 6 Mar 2006 08:04:11 -0700
Subject: [SC-L] Question about the terms "encypt" and "secure"
Message-ID: <80A84CB5E834D4439556D1F64A1FEB8301D6245A@ES20SNLNT.srn.sandia.gov>

I think it's important to understand the difference between encryption
and security (or being secure).  Encryption is a tool, being secure is a
state.  

Think of encryption as a lock on a door.  Putting a lock on a door
doesn't necessarily make your house any more secure.  If you leave your
windows open or leave your key under the doormat your not really any
more secure.  Even if you don't leave you windows open and have a key
lying around, some one can always break the door down or our force
themselves in as you enter or exit.  Encryption functions much the same
way - it's a tool.  If used properly, it can help to secure your system.


Unfortunately, using encryption rarely translates into having a secure
system.  WEP, the first wireless encryption protocol, has been
vulnerable for a long time (it's pretty much worthless).  WPA, the
successor to WEP, is also vulnerable to attack if you have a weak
encryption key.  Even if you were sure that the protocol to encrypt your
networks works, an attacker could try to steal the key or brute force
it.  Then there is the issue of client security - which brings up a
whole different set of security problems.  

Clicking on a few check boxes and setting a key to a wireless network
may encrypt the traffic between the clients and the WAP, but that
doesn't mean your network is any more secure.  

-dan

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of William L. Anderson
Sent: Sunday, March 05, 2006 10:35 AM
To: Secure Coding Mailing List
Subject: [SC-L] Question about the terms "encypt" and "secure"

Today's NYTimes has an article about "piggybacking" on open wireless
networks and what some people think about it and what some are doing
about it. The link is:
http://www.nytimes.com/2006/03/05/technology/05wireless.html
(subscription may be req'd)

One question popped up for me when I read the following sentence:

"For the Brodeurs in Los Angeles, a close reading of their network's
manual helped them to finally encrypt their network."

My question is whether it's more accurate to say "secure their network"
rather than "encrypt". I'm not clear myself about the meaning of these
terms; I think of encryption as being one way to make a network secure.

And if there is a substantive difference in these terms, then I'd like
to understand it. I believe that a better understanding of security
would help ordinary users take more secure actions. I'm an optimist.

-Bill Anderson





From ljknews at mac.com  Mon Mar  6 09:27:01 2006
From: ljknews at mac.com (ljknews)
Date: Mon, 6 Mar 2006 09:27:01 -0500
Subject: [SC-L] Question about the terms "encypt" and "secure"
In-Reply-To: <5B10E50E14A4594EB1B5566B69AD94070D1AAE89@maileast>
References: <5B10E50E14A4594EB1B5566B69AD94070D1AAE89@maileast>
Message-ID: <p05200f10c031f6fd30f1@[192.168.1.254]>

At 6:04 AM -0800 3/6/06, Jeremy Epstein wrote:

> Encryption is one way to secure the *transport* on the network (subject to
> various caveats about appropriate use of crypto, trust issues, etc.).  I'd
> strongly disagree with anyone who says that encryption "makes a network
> secure" - because people interpret that to mean "if I encrypt the network, I
> don't need to do anything else".

I cannot think of any other _network_ security mechanisms that do not
also apply to securing a single multiuser machine.
-- 
Larry Kilgallen


From vanderaj at greebo.net  Mon Mar  6 11:26:56 2006
From: vanderaj at greebo.net (Andrew van der Stock)
Date: Tue, 7 Mar 2006 03:26:56 +1100
Subject: [SC-L] Fwd: Security problems with Ajax
References: <089162A1-3413-406B-A5A8-54E6AB349D59@greebo.net>
Message-ID: <D79D9F5D-8C75-4F63-B1AC-39DE1B5FF1D9@greebo.net>

Hi there,

I replied to Kentaro privately before I was subscribed to this list.  
The OWASP Guide 2.1 Ajax chapter is about 80% done and 80% to go. I  
have some serious vulnerabilities to report to a few vendors,  
research to be included in the paper, such as JSON injection and so  
on, and peer review from an accessibility expert (as I'm not  
qualified in this area).

My slide deck from the OWASP Melbourne chapter meeting in February is  
also useful:
http://www.greebo.net/owasp/ajax_security.pdf (PDF, 1.8 MB)

Here is my message to Kentaro-san:

Begin forwarded message:

> From: Andrew van der Stock <vanderaj at greebo.net>
> Date: 7 March 2006 2:54:36 AM
> To: kentaro.arai at <hidden>
> Subject: Security problems with Ajax
>
> Kentaro,
>
> In short, yes! :)
>
> I am researching and writing a new chapter on Ajax security for the  
> OWASP Guide which will be out as soon as it's been properly  
> reviewed. In my travels, I've found many implementation issues  
> surrounding how Ajax toolkits are used.
>
> In particular:
>
> a) security architecture. Where to start... please read the chapter  
> when it comes out
>
> b) sending to a second, disassociated server prevents secure state,  
> such as authorization from being shared. This usually leads to  
> really poor decisions about state management and application design
>
> c) insecure client-side state storage - including authorization  
> decisions
>
> d) client-side authorization (!!!) or non-existent authorization (!!!)
>
> e) new classes of injection attacks (which I call "Ajax injection"  
> as a meta-class of attack, but are in fact a multitude of injection  
> attacks including existing issues such as Javascript code injection  
> (as per GMail last week) and basic XSS, through to JSON injection,  
> which is a new one) due to a lack of care with encoding, decoding,  
> and in general simply not thinking things through
>
> f) insufficient validation on the server, particularly when Ajax  
> calls web services, and even more so when Ajax calls enterprise  
> service buses (SOA) publishing 40 year old COBOL code which has  
> never been tested for XML node injection before
>
> g) insufficient business rule validation. This is true of normal  
> apps as well, but it is particularly prevalent with Ajax apps as  
> for some strange reason they believe Ajax is secure magic pixie  
> dust. I've got a few demo vulnerabilities to report to various  
> places before I can speak about these in the open.
>
> h) GET request mania. I know that someone here posted something  
> about REST, but honestly, GET methods is a privacy nightmare for  
> many firms who must go out of their way to prevent private  
> information leaking into third party systems like ISP caches or  
> browser history on Internet kiosks. Only a few toolkits had clear  
> documentation on how you can change to using POST data... which  
> surprisingly includes CPaint, one of the first Ajax toolkits to be  
> exposed as insecure. Version 2.0.x of CPaint is soooo much better.
>
> h) not particularly security related, but is compliance related -  
> Ajax frameworks are in general completely inaccessible. They fail  
> WAI validation miserably, do not provide alternate accessible  
> paths, and rarely prompt screen readers to refresh the screen. Many  
> are fixed pixel sizes and work in new ways which makes using  
> assistive technologies impossible as they don't know how to handle  
> this bag o' pixels masquerading as an application. I am getting  
> this section peer reviewed by an accessibility specialist, but as  
> it's illegal to produce inaccessible applications unless it's a  
> justifiable hardship (gee, spending 20%-90% more to create a glitzy  
> interface over an accessible one will go down well with our equal  
> opportunity legal beagles). Ajax CAN be accessible. But with few  
> exceptions, it is not. In some hard core cases, the vendors must  
> really hate and despise disabled users and users with high DPI  
> screens. I have one major commercial Ajax vendor suite that acts  
> like its own desktop UI that *crashes* the browser when you try to  
> increase the font size to something readable. I will name names  
> soon if they don't get their act together. Completely and utterly  
> unacceptable.
>
> In short, Ajax can be made secure, but in general it is not -  
> application writers are at worse than security square one with most  
> toolkits. The architecture alone forces many poor choices upon  
> application authors, and if they are unaware of security issues,  
> they will create insecure and unsecurable web applications.
>
> thanks,
> Andrew



From smb at cs.columbia.edu  Mon Mar  6 14:08:23 2006
From: smb at cs.columbia.edu (Steven M. Bellovin)
Date: Mon, 6 Mar 2006 14:08:23 -0500
Subject: [SC-L] Question about the terms "encypt" and "secure"
In-Reply-To: <440B215B.5040500@acm.org>
References: <440B215B.5040500@acm.org>
Message-ID: <20060306140823.18240a7b.smb@cs.columbia.edu>

On Sun, 05 Mar 2006 12:35:23 -0500
"William L. Anderson" <band at acm.org> wrote:

> Today's NYTimes has an article about "piggybacking" on open wireless
> networks and what some people think about it and what some are doing
> about it. The link is:
> http://www.nytimes.com/2006/03/05/technology/05wireless.html
> (subscription may be req'd)
> 
> One question popped up for me when I read the following sentence:
> 
> "For the Brodeurs in Los Angeles, a close reading of their network's
> manual helped them to finally encrypt their network."
> 
> My question is whether it's more accurate to say "secure their network"
> rather than "encrypt". I'm not clear myself about the meaning of these
> terms; I think of encryption as being one way to make a network secure.
> 
> And if there is a substantive difference in these terms, then I'd like
> to understand it. I believe that a better understanding of security
> would help ordinary users take more secure actions. I'm an optimist.
> 
I suspect that in general you're right, but in this case they really
meant "encrypt" -- turn on WEP to secure the net.


		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb


From dinis at ddplus.net  Mon Mar  6 20:39:05 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Mon, 6 Mar 2006 20:39:05 -0500
Subject: [SC-L] Is there any Security problem in Ajax technology?
Message-ID: <99dd65a800034f4ba039d6bf625689f6@ddplus.net>

I personally think that AJAX has the potential to create very insecure applications because it pushes the data validation and authorization layers back to the client (i.e. the browser)

"AJAX brings 'Back the Rich Client' and all its security problems"

Kentaro, on your AJAX application you must follow the rule-of-thumb of not trusting any data supplied by your own Client-Side-AJAX functions, and authorize every request.

In a nutshell: any data validation and authorization decisions/actions made at the Client-Side-AJAX functions are only there for usability, and have NO security value.

Hope this helps

Dinis Cruz
Owasp .Net Project
www.owasp.net

----------------------------------------
From: "Kentaro Arai" <kentaro.arai at avanade.com>
Sent: Monday, March 06, 2006 9:49 AM
To: "Secure Coding Mailing List" <SC-L at securecoding.org>
Subject: [SC-L] Is there any Security problem in Ajax technology? 

Hi, All

I'm designing a web application with Ajax technology and .NET
Framework1.1.
Do I need to consider any security problem, using the Ajax technology?

Kentaro Arai

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060306/c1ad3282/attachment.html 

From ken at krvw.com  Tue Mar  7 10:56:24 2006
From: ken at krvw.com (Kenneth R. van Wyk)
Date: Tue, 7 Mar 2006 10:56:24 -0500 (EST)
Subject: [SC-L] ZDNET: LAMP lights the way in open-source security 
Message-ID: <3379.72.254.12.137.1141746984.squirrel@mail.krvw.com>

Interesting article out on ZDNet today:

http://www.zdnetasia.com/news/security/0,39044215,39315781,00.htm

The article refers to the US government sponsored study being done by Stanford University,
Symantec, and Coverity.  It says, "The so-called LAMP stack of open-source software has a
lower bug density--the number of bugs per thousand lines of code--than a baseline of 32
open-source projects analyzed, Coverity, a maker of code analysis tools, announced Monday."

This surprised me quite a bit, especially given LAMP's popular reliance on scripting
languages PHP, Perl, and/or Python.  Still, the article doesn't discuss any of the root
causes of the claimed security strengths in LAMP-based code.  Perhaps it's because the
scripting languages tend to make things less complex for the coders (as opposed to more
complex higher level languages like Java and C#/.NET)?  Opinions?

Cheers,

Ken
-- 
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




From mgavin at forrester.com  Tue Mar  7 11:49:16 2006
From: mgavin at forrester.com (Gavin, Michael)
Date: Tue, 7 Mar 2006 11:49:16 -0500
Subject: [SC-L] ZDNET: LAMP lights the way in open-source security 
Message-ID: <79769518040B6B45A46C0AD390FD5A8302251E2B@CAMB-EX.forrester.loc>

The Coverity product (Coverity Prevent) is a static source code analysis
tool for C and C++, see
http://www.coverity.com/library/pdf/coverity_prevent.pdf.

It isn't actually scanning (or if it is, it isn't analyzing) any of the
scripting code, as far I as can tell.

Michael

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth R. van Wyk
Sent: Tuesday, March 07, 2006 10:56 AM
To: Secure Coding Mailing List
Subject: [SC-L] ZDNET: LAMP lights the way in open-source security 

Interesting article out on ZDNet today:

http://www.zdnetasia.com/news/security/0,39044215,39315781,00.htm

The article refers to the US government sponsored study being done by
Stanford University,
Symantec, and Coverity.  It says, "The so-called LAMP stack of
open-source software has a
lower bug density--the number of bugs per thousand lines of code--than a
baseline of 32
open-source projects analyzed, Coverity, a maker of code analysis tools,
announced Monday."

This surprised me quite a bit, especially given LAMP's popular reliance
on scripting
languages PHP, Perl, and/or Python.  Still, the article doesn't discuss
any of the root
causes of the claimed security strengths in LAMP-based code.  Perhaps
it's because the
scripting languages tend to make things less complex for the coders (as
opposed to more
complex higher level languages like Java and C#/.NET)?  Opinions?

Cheers,

Ken
-- 
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php



From jeremy.epstein at webmethods.com  Tue Mar  7 12:17:29 2006
From: jeremy.epstein at webmethods.com (Jeremy Epstein)
Date: Tue, 7 Mar 2006 12:17:29 -0500 
Subject: [SC-L] ZDNET: LAMP lights the way in open-source security 
Message-ID: <5B10E50E14A4594EB1B5566B69AD94070D1EFDD5@maileast>

All of which proves that there are lies, damn lies, and statistics (the
statistic being the lower bug density, which ignores the most potentially
vulnerable parts of the system). 

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gavin, Michael
> Sent: Tuesday, March 07, 2006 11:49 AM
> To: Kenneth R. van Wyk; Secure Coding Mailing List
> Subject: RE: [SC-L] ZDNET: LAMP lights the way in open-source 
> security 
> 
> The Coverity product (Coverity Prevent) is a static source 
> code analysis tool for C and C++, see 
> http://www.coverity.com/library/pdf/coverity_prevent.pdf.
> 
> It isn't actually scanning (or if it is, it isn't analyzing) 
> any of the scripting code, as far I as can tell.
> 
> Michael
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth R. van Wyk
> Sent: Tuesday, March 07, 2006 10:56 AM
> To: Secure Coding Mailing List
> Subject: [SC-L] ZDNET: LAMP lights the way in open-source security 
> 
> Interesting article out on ZDNet today:
> 
> http://www.zdnetasia.com/news/security/0,39044215,39315781,00.htm
> 
> The article refers to the US government sponsored study being 
> done by Stanford University, Symantec, and Coverity.  It 
> says, "The so-called LAMP stack of open-source software has a 
> lower bug density--the number of bugs per thousand lines of 
> code--than a baseline of 32 open-source projects analyzed, 
> Coverity, a maker of code analysis tools, announced Monday."
> 
> This surprised me quite a bit, especially given LAMP's 
> popular reliance on scripting languages PHP, Perl, and/or 
> Python.  Still, the article doesn't discuss any of the root 
> causes of the claimed security strengths in LAMP-based code.  
> Perhaps it's because the scripting languages tend to make 
> things less complex for the coders (as opposed to more 
> complex higher level languages like Java and C#/.NET)?  Opinions?
> 
> Cheers,
> 
> Ken
> --
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 


From mgavin at forrester.com  Tue Mar  7 12:45:45 2006
From: mgavin at forrester.com (Gavin, Michael)
Date: Tue, 7 Mar 2006 12:45:45 -0500
Subject: [SC-L] ZDNET: LAMP lights the way in open-source security 
Message-ID: <79769518040B6B45A46C0AD390FD5A8302251EBD@CAMB-EX.forrester.loc>

Yeah, statistics can allow you to say and "prove" just about anything.

OK, showing my ignorance here, since I haven't checked out any of the
LAMP source trees and reviewed the code: how much of the code making up
those modules is written in scripting languages vs. how much of it is
written in C, C++ (and how much, if any, is written in any other
compiled languages)?

If the LAMP source code itself is primarily C/C++, then arguably, the
results are somewhat interesting, though I think they would be much more
interesting if this DISA project was set up to test the open source code
with a number of commercial scanners instead of just the Coverity
scanner, then we could at least compare the merits of various scanning
techniques and implementations. In this case, the distinction to me is
that they have tested the LAMP platform code, not the code that people
write on top of it for their applications, and are making some
statements about the software security of the LAMP platform compared to
the rest of the open source code they scanned.

If on the other hand, a significant portion of the LAMP code base itself
is made up of scripting language code, then I agree with you, the
results aren't terribly useful to anyone other than possibly Coverity
and Stanford. Note: significant is open to interpretation, but doesn't
have to be large; 10 or 15 per cent would seem significant enough to me.

-----Original Message-----
From: Jeremy Epstein [mailto:jeremy.epstein at webmethods.com] 
Sent: Tuesday, March 07, 2006 12:17 PM
To: Gavin, Michael; Kenneth R. van Wyk; Secure Coding Mailing List
Subject: RE: [SC-L] ZDNET: LAMP lights the way in open-source security 

All of which proves that there are lies, damn lies, and statistics (the
statistic being the lower bug density, which ignores the most
potentially
vulnerable parts of the system). 

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gavin, Michael
> Sent: Tuesday, March 07, 2006 11:49 AM
> To: Kenneth R. van Wyk; Secure Coding Mailing List
> Subject: RE: [SC-L] ZDNET: LAMP lights the way in open-source 
> security 
> 
> The Coverity product (Coverity Prevent) is a static source 
> code analysis tool for C and C++, see 
> http://www.coverity.com/library/pdf/coverity_prevent.pdf.
> 
> It isn't actually scanning (or if it is, it isn't analyzing) 
> any of the scripting code, as far I as can tell.
> 
> Michael
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth R. van Wyk
> Sent: Tuesday, March 07, 2006 10:56 AM
> To: Secure Coding Mailing List
> Subject: [SC-L] ZDNET: LAMP lights the way in open-source security 
> 
> Interesting article out on ZDNet today:
> 
> http://www.zdnetasia.com/news/security/0,39044215,39315781,00.htm
> 
> The article refers to the US government sponsored study being 
> done by Stanford University, Symantec, and Coverity.  It 
> says, "The so-called LAMP stack of open-source software has a 
> lower bug density--the number of bugs per thousand lines of 
> code--than a baseline of 32 open-source projects analyzed, 
> Coverity, a maker of code analysis tools, announced Monday."
> 
> This surprised me quite a bit, especially given LAMP's 
> popular reliance on scripting languages PHP, Perl, and/or 
> Python.  Still, the article doesn't discuss any of the root 
> causes of the claimed security strengths in LAMP-based code.  
> Perhaps it's because the scripting languages tend to make 
> things less complex for the coders (as opposed to more 
> complex higher level languages like Java and C#/.NET)?  Opinions?
> 
> Cheers,
> 
> Ken
> --
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 



From jeff.williams at aspectsecurity.com  Tue Mar  7 14:34:27 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Tue, 7 Mar 2006 14:34:27 -0500
Subject: [SC-L] ZDNET: LAMP lights the way in open-source security 
In-Reply-To: <79769518040B6B45A46C0AD390FD5A8302251EBD@CAMB-EX.forrester.loc>
Message-ID: <00b801c6421e$25ccaae0$8204a8c0@intranet.aspectsecurity.com>

I'm a strong advocate of static analysis, but drawing conclusions about
overall security based only on these tools is just silly.  Even ignoring the
scripting language problem, these tools simply aren't even looking for many
of the types of problems that cause the most serious risks.  They're great
for assisting a code review or indicating potential design flaws, but not a
great ruler.  At least not yet.

--Jeff

> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On
> Behalf Of Gavin, Michael
> Sent: Tuesday, March 07, 2006 12:46 PM
> To: Jeremy Epstein; Kenneth R. van Wyk; Secure Coding Mailing List
> Subject: RE: [SC-L] ZDNET: LAMP lights the way in open-source security
> 
> Yeah, statistics can allow you to say and "prove" just about anything.
> 
> OK, showing my ignorance here, since I haven't checked out any of the
> LAMP source trees and reviewed the code: how much of the code making up
> those modules is written in scripting languages vs. how much of it is
> written in C, C++ (and how much, if any, is written in any other
> compiled languages)?
> 
> If the LAMP source code itself is primarily C/C++, then arguably, the
> results are somewhat interesting, though I think they would be much more
> interesting if this DISA project was set up to test the open source code
> with a number of commercial scanners instead of just the Coverity
> scanner, then we could at least compare the merits of various scanning
> techniques and implementations. In this case, the distinction to me is
> that they have tested the LAMP platform code, not the code that people
> write on top of it for their applications, and are making some
> statements about the software security of the LAMP platform compared to
> the rest of the open source code they scanned.
> 
> If on the other hand, a significant portion of the LAMP code base itself
> is made up of scripting language code, then I agree with you, the
> results aren't terribly useful to anyone other than possibly Coverity
> and Stanford. Note: significant is open to interpretation, but doesn't
> have to be large; 10 or 15 per cent would seem significant enough to me.
> 
> -----Original Message-----
> From: Jeremy Epstein [mailto:jeremy.epstein at webmethods.com]
> Sent: Tuesday, March 07, 2006 12:17 PM
> To: Gavin, Michael; Kenneth R. van Wyk; Secure Coding Mailing List
> Subject: RE: [SC-L] ZDNET: LAMP lights the way in open-source security
> 
> All of which proves that there are lies, damn lies, and statistics (the
> statistic being the lower bug density, which ignores the most
> potentially
> vulnerable parts of the system).
> 
> > -----Original Message-----
> > From: sc-l-bounces at securecoding.org
> > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gavin, Michael
> > Sent: Tuesday, March 07, 2006 11:49 AM
> > To: Kenneth R. van Wyk; Secure Coding Mailing List
> > Subject: RE: [SC-L] ZDNET: LAMP lights the way in open-source
> > security
> >
> > The Coverity product (Coverity Prevent) is a static source
> > code analysis tool for C and C++, see
> > http://www.coverity.com/library/pdf/coverity_prevent.pdf.
> >
> > It isn't actually scanning (or if it is, it isn't analyzing)
> > any of the scripting code, as far I as can tell.
> >
> > Michael
> >
> > -----Original Message-----
> > From: sc-l-bounces at securecoding.org
> > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth R. van Wyk
> > Sent: Tuesday, March 07, 2006 10:56 AM
> > To: Secure Coding Mailing List
> > Subject: [SC-L] ZDNET: LAMP lights the way in open-source security
> >
> > Interesting article out on ZDNet today:
> >
> > http://www.zdnetasia.com/news/security/0,39044215,39315781,00.htm
> >
> > The article refers to the US government sponsored study being
> > done by Stanford University, Symantec, and Coverity.  It
> > says, "The so-called LAMP stack of open-source software has a
> > lower bug density--the number of bugs per thousand lines of
> > code--than a baseline of 32 open-source projects analyzed,
> > Coverity, a maker of code analysis tools, announced Monday."
> >
> > This surprised me quite a bit, especially given LAMP's
> > popular reliance on scripting languages PHP, Perl, and/or
> > Python.  Still, the article doesn't discuss any of the root
> > causes of the claimed security strengths in LAMP-based code.
> > Perhaps it's because the scripting languages tend to make
> > things less complex for the coders (as opposed to more
> > complex higher level languages like Java and C#/.NET)?  Opinions?
> >
> > Cheers,
> >
> > Ken
> > --
> > Kenneth R. van Wyk
> > KRvW Associates, LLC
> > http://www.KRvW.com
> >
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org
> > List information, subscriptions, etc -
> > http://krvw.com/mailman/listinfo/sc-l
> > List charter available at -
> > http://www.securecoding.org/list/charter.php
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org
> > List information, subscriptions, etc -
> > http://krvw.com/mailman/listinfo/sc-l
> > List charter available at -
> > http://www.securecoding.org/list/charter.php
> >
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php



From gem at cigital.com  Tue Mar  7 15:40:19 2006
From: gem at cigital.com (Gary McGraw)
Date: Tue, 7 Mar 2006 15:40:19 -0500
Subject: [SC-L] ZDNET: LAMP lights the way in open-source security 
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB64B265@va-mail.cigital.com>

Absolutely right.  Spot on.

gem

 -----Original Message-----
From: 	Jeff Williams [mailto:jeff.williams at aspectsecurity.com]
Sent:	Tue Mar 07 14:46:54 2006
To:	'Gavin, Michael'; 'Jeremy Epstein'; 'Kenneth R. van Wyk'; 'Secure Coding Mailing List'
Subject:	RE: [SC-L] ZDNET: LAMP lights the way in open-source security 

I'm a strong advocate of static analysis, but drawing conclusions about
overall security based only on these tools is just silly.  Even ignoring the
scripting language problem, these tools simply aren't even looking for many
of the types of problems that cause the most serious risks.  They're great
for assisting a code review or indicating potential design flaws, but not a
great ruler.  At least not yet.

--Jeff

> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On
> Behalf Of Gavin, Michael
> Sent: Tuesday, March 07, 2006 12:46 PM
> To: Jeremy Epstein; Kenneth R. van Wyk; Secure Coding Mailing List
> Subject: RE: [SC-L] ZDNET: LAMP lights the way in open-source security
> 
> Yeah, statistics can allow you to say and "prove" just about anything.
> 
> OK, showing my ignorance here, since I haven't checked out any of the
> LAMP source trees and reviewed the code: how much of the code making up
> those modules is written in scripting languages vs. how much of it is
> written in C, C++ (and how much, if any, is written in any other
> compiled languages)?
> 
> If the LAMP source code itself is primarily C/C++, then arguably, the
> results are somewhat interesting, though I think they would be much more
> interesting if this DISA project was set up to test the open source code
> with a number of commercial scanners instead of just the Coverity
> scanner, then we could at least compare the merits of various scanning
> techniques and implementations. In this case, the distinction to me is
> that they have tested the LAMP platform code, not the code that people
> write on top of it for their applications, and are making some
> statements about the software security of the LAMP platform compared to
> the rest of the open source code they scanned.
> 
> If on the other hand, a significant portion of the LAMP code base itself
> is made up of scripting language code, then I agree with you, the
> results aren't terribly useful to anyone other than possibly Coverity
> and Stanford. Note: significant is open to interpretation, but doesn't
> have to be large; 10 or 15 per cent would seem significant enough to me.
> 
> -----Original Message-----
> From: Jeremy Epstein [mailto:jeremy.epstein at webmethods.com]
> Sent: Tuesday, March 07, 2006 12:17 PM
> To: Gavin, Michael; Kenneth R. van Wyk; Secure Coding Mailing List
> Subject: RE: [SC-L] ZDNET: LAMP lights the way in open-source security
> 
> All of which proves that there are lies, damn lies, and statistics (the
> statistic being the lower bug density, which ignores the most
> potentially
> vulnerable parts of the system).
> 
> > -----Original Message-----
> > From: sc-l-bounces at securecoding.org
> > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gavin, Michael
> > Sent: Tuesday, March 07, 2006 11:49 AM
> > To: Kenneth R. van Wyk; Secure Coding Mailing List
> > Subject: RE: [SC-L] ZDNET: LAMP lights the way in open-source
> > security
> >
> > The Coverity product (Coverity Prevent) is a static source
> > code analysis tool for C and C++, see
> > http://www.coverity.com/library/pdf/coverity_prevent.pdf.
> >
> > It isn't actually scanning (or if it is, it isn't analyzing)
> > any of the scripting code, as far I as can tell.
> >
> > Michael
> >
> > -----Original Message-----
> > From: sc-l-bounces at securecoding.org
> > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth R. van Wyk
> > Sent: Tuesday, March 07, 2006 10:56 AM
> > To: Secure Coding Mailing List
> > Subject: [SC-L] ZDNET: LAMP lights the way in open-source security
> >
> > Interesting article out on ZDNet today:
> >
> > http://www.zdnetasia.com/news/security/0,39044215,39315781,00.htm
> >
> > The article refers to the US government sponsored study being
> > done by Stanford University, Symantec, and Coverity.  It
> > says, "The so-called LAMP stack of open-source software has a
> > lower bug density--the number of bugs per thousand lines of
> > code--than a baseline of 32 open-source projects analyzed,
> > Coverity, a maker of code analysis tools, announced Monday."
> >
> > This surprised me quite a bit, especially given LAMP's
> > popular reliance on scripting languages PHP, Perl, and/or
> > Python.  Still, the article doesn't discuss any of the root
> > causes of the claimed security strengths in LAMP-based code.
> > Perhaps it's because the scripting languages tend to make
> > things less complex for the coders (as opposed to more
> > complex higher level languages like Java and C#/.NET)?  Opinions?
> >
> > Cheers,
> >
> > Ken
> > --
> > Kenneth R. van Wyk
> > KRvW Associates, LLC
> > http://www.KRvW.com
> >
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org
> > List information, subscriptions, etc -
> > http://krvw.com/mailman/listinfo/sc-l
> > List charter available at -
> > http://www.securecoding.org/list/charter.php
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org
> > List information, subscriptions, etc -
> > http://krvw.com/mailman/listinfo/sc-l
> > List charter available at -
> > http://www.securecoding.org/list/charter.php
> >
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From crispin at novell.com  Tue Mar  7 15:59:50 2006
From: crispin at novell.com (Crispin Cowan)
Date: Tue, 07 Mar 2006 12:59:50 -0800
Subject: [SC-L] ZDNET: LAMP lights the way in open-source security
In-Reply-To: <79769518040B6B45A46C0AD390FD5A8302251EBD@CAMB-EX.forrester.loc>
References: <79769518040B6B45A46C0AD390FD5A8302251EBD@CAMB-EX.forrester.loc>
Message-ID: <440DF446.3030209@novell.com>

Gavin, Michael wrote:
> Yeah, statistics can allow you to say and "prove" just about anything.
>
> OK, showing my ignorance here, since I haven't checked out any of the
> LAMP source trees and reviewed the code: how much of the code making up
> those modules is written in scripting languages vs. how much of it is
> written in C, C++ (and how much, if any, is written in any other
> compiled languages)?
>   
That doesn't matter; what matters is what fraction of disclosed
vulnerabilities is in each segment of the code? If 90% of the
vulnerabilities come from the PHP part, then the fact that 90% of the
lines of code are in C doesn't help.

> If the LAMP source code itself is primarily C/C++, then arguably, the
> results are somewhat interesting, though I think they would be much more
> interesting if this DISA project was set up to test the open source code
> with a number of commercial scanners instead of just the Coverity
> scanner, then we could at least compare the merits of various scanning
> techniques and implementations.
The proprietary status of the Coverity scanner is a continuous pain.
That's why I tend to ignore it where possible :)

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption



From mgavin at forrester.com  Tue Mar  7 16:35:30 2006
From: mgavin at forrester.com (Gavin, Michael)
Date: Tue, 7 Mar 2006 16:35:30 -0500
Subject: [SC-L] ZDNET: LAMP lights the way in open-source security
Message-ID: <79769518040B6B45A46C0AD390FD5A83022521F4@CAMB-EX.forrester.loc>


-----Original Message-----
>From: Crispin Cowan [mailto:crispin at novell.com]
>
>Gavin, Michael wrote:
>> Yeah, statistics can allow you to say and "prove" just about
anything.
>>
>> OK, showing my ignorance here, since I haven't checked out any of the
>> LAMP source trees and reviewed the code: how much of the code making
up
>> those modules is written in scripting languages vs. how much of it is
>> written in C, C++ (and how much, if any, is written in any other
>> compiled languages)?
>>   
> That doesn't matter; what matters is what fraction of disclosed
> vulnerabilities is in each segment of the code? If 90% of the
> vulnerabilities come from the PHP part, then the fact that 90% of the
> lines of code are in C doesn't help.

[Gavin, Michael] Absolutely true! But from the perspective of improving
static source code analysis tools, if 90% of the code is in C, which is
one of the 2 languages supported by the Coverity product, then we now
have one reasonable data point regarding how well that (moderate amount
of) C code was written with respect to one vendor's
notion/implementation of secure coding in C.

Certainly not a huge win for anyone, but a potential starting point for
comparing techniques and products. For example, I haven't been following
the status of David Wheeler's flawfinder, but even if that hasn't been
updated lately, it might be interesting to see which flaws it finds that
Coverity found, which Coverity found that flawfinder doesn't, and which
flawfinder finds that Coverity didn't. Unfortunately your comment below
regarding the proprietary nature of Coverity makes such a comparison
less useful for everyone but Coverity...

>> If the LAMP source code itself is primarily C/C++, then arguably, the
>> results are somewhat interesting, though I think they would be much
more
>> interesting if this DISA project was set up to test the open source
code
>> with a number of commercial scanners instead of just the Coverity
>> scanner, then we could at least compare the merits of various
scanning
>> techniques and implementations.
> The proprietary status of the Coverity scanner is a continuous pain.
> That's why I tend to ignore it where possible :)
>
> Crispin
> -- 
> Crispin Cowan, Ph.D.
http://crispincowan.com/~crispin/
> Director of Software Engineering, Novell http://novell.com
> 	Olympic Games: The Bi-Annual Festival of Corruption




From gem at cigital.com  Tue Mar  7 17:32:23 2006
From: gem at cigital.com (Gary McGraw)
Date: Tue, 7 Mar 2006 17:32:23 -0500
Subject: [SC-L] ZDNET: LAMP lights the way in open-source security
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB64B268@va-mail.cigital.com>

Hmm.

Time to no longer use flawfinder, RATS, and ITS4.  Throw them out and get a real tool.

I cover this in gory detail in chapter 5 of Software Security.  There's a pretty nice treatment of the history of these tools and the evolution of technology there.

gem
www.swsec.com
www.cigital.com/~gem

 -----Original Message-----
From: 	Gavin, Michael [mailto:mgavin at forrester.com]
Sent:	Tue Mar 07 16:40:00 2006
To:	Crispin Cowan
Cc:	Jeremy Epstein; Secure Coding Mailing List
Subject:	RE: [SC-L] ZDNET: LAMP lights the way in open-source security


-----Original Message-----
>From: Crispin Cowan [mailto:crispin at novell.com]
>
>Gavin, Michael wrote:
>> Yeah, statistics can allow you to say and "prove" just about
anything.
>>
>> OK, showing my ignorance here, since I haven't checked out any of the
>> LAMP source trees and reviewed the code: how much of the code making
up
>> those modules is written in scripting languages vs. how much of it is
>> written in C, C++ (and how much, if any, is written in any other
>> compiled languages)?
>>   
> That doesn't matter; what matters is what fraction of disclosed
> vulnerabilities is in each segment of the code? If 90% of the
> vulnerabilities come from the PHP part, then the fact that 90% of the
> lines of code are in C doesn't help.

[Gavin, Michael] Absolutely true! But from the perspective of improving
static source code analysis tools, if 90% of the code is in C, which is
one of the 2 languages supported by the Coverity product, then we now
have one reasonable data point regarding how well that (moderate amount
of) C code was written with respect to one vendor's
notion/implementation of secure coding in C.

Certainly not a huge win for anyone, but a potential starting point for
comparing techniques and products. For example, I haven't been following
the status of David Wheeler's flawfinder, but even if that hasn't been
updated lately, it might be interesting to see which flaws it finds that
Coverity found, which Coverity found that flawfinder doesn't, and which
flawfinder finds that Coverity didn't. Unfortunately your comment below
regarding the proprietary nature of Coverity makes such a comparison
less useful for everyone but Coverity...

>> If the LAMP source code itself is primarily C/C++, then arguably, the
>> results are somewhat interesting, though I think they would be much
more
>> interesting if this DISA project was set up to test the open source
code
>> with a number of commercial scanners instead of just the Coverity
>> scanner, then we could at least compare the merits of various
scanning
>> techniques and implementations.
> The proprietary status of the Coverity scanner is a continuous pain.
> That's why I tend to ignore it where possible :)
>
> Crispin
> -- 
> Crispin Cowan, Ph.D.
http://crispincowan.com/~crispin/
> Director of Software Engineering, Novell http://novell.com
> 	Olympic Games: The Bi-Annual Festival of Corruption


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Tue Mar  7 21:38:21 2006
From: gem at cigital.com (Gary McGraw)
Date: Tue, 7 Mar 2006 21:38:21 -0500
Subject: [SC-L] Software security for the enterprise
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB64B277@va-mail.cigital.com>


According to this article is is possible to have large scale successful software security programs!  Rock on.

http://www.eweek.com/article2/0,1895,1935074,00.asp

gem
www.swsec.com


Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gwc at acm.org  Mon Mar 13 15:30:04 2006
From: gwc at acm.org (George Capehart)
Date: Mon, 13 Mar 2006 15:30:04 -0500
Subject: [SC-L] Is there any Security problem in Ajax technology?
In-Reply-To: <99dd65a800034f4ba039d6bf625689f6@ddplus.net>
References: <99dd65a800034f4ba039d6bf625689f6@ddplus.net>
Message-ID: <4415D64C.8020200@acm.org>

Dinis Cruz wrote:
> I personally think that AJAX has the potential to create very insecure applications because it pushes the data validation and authorization layers back to the client (i.e. the browser)
> 
> "AJAX brings 'Back the Rich Client' and all its security problems"
> 
> Kentaro, on your AJAX application you must follow the rule-of-thumb of not trusting any data supplied by your own Client-Side-AJAX functions, and authorize every request.
> 
> In a nutshell: any data validation and authorization decisions/actions made at the Client-Side-AJAX functions are only there for usability, and have NO security value.

I enthusiastically agree with the above.  I'll take it further and suggest
that, even then, the input from the Web should/must be examined and sanitized
before use . . .  /*still*/ need to check for SQL injection attacks, etc.
IMNSHO, identification, authorization and validation should always be done by
the part of the system that is at risk if the input is bad (in any of the
connotations of bad) . . .

Cheers,

/g


From ge at linuxbox.org  Tue Mar 14 06:08:47 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Tue, 14 Mar 2006 13:08:47 +0200
Subject: [SC-L] Is there any Security problem in Ajax technology?
In-Reply-To: <4415D64C.8020200@acm.org>
References: <99dd65a800034f4ba039d6bf625689f6@ddplus.net>
	<4415D64C.8020200@acm.org>
Message-ID: <4416A43F.8050805@linuxbox.org>

George Capehart wrote:
> Dinis Cruz wrote:
> 
>>I personally think that AJAX has the potential to create very insecure applications because it pushes the data validation and authorization layers back to the client (i.e. the browser)
>>
>>"AJAX brings 'Back the Rich Client' and all its security problems"
>>
>>Kentaro, on your AJAX application you must follow the rule-of-thumb of not trusting any data supplied by your own Client-Side-AJAX functions, and authorize every request.
>>
>>In a nutshell: any data validation and authorization decisions/actions made at the Client-Side-AJAX functions are only there for usability, and have NO security value.
> 
> 
> I enthusiastically agree with the above.  I'll take it further and suggest
> that, even then, the input from the Web should/must be examined and sanitized
> before use . . .  /*still*/ need to check for SQL injection attacks, etc.
> IMNSHO, identification, authorization and validation should always be done by
> the part of the system that is at risk if the input is bad (in any of the
> connotations of bad) . . .

Indeed, but I believe the main point he was trying to make was:
 >>In a nutshell: any data validation and authorization 
decisions/actions made at the Client-Side-AJAX functions are only there 
for usability, and have NO security value.

Much like with regular Java. Nothing changed.

The issue is to think like an attacker. Any client-side defense can be 
thrown aside, discarded.
Client-side defenses however are often very useful for "usability", 
i.e., so that the user is not allowed to send in bad Characters, or 
he/she wouldn't know their request was stopped server-side.

	Gadi.

-- 
http://blogs.securiteam.com/

"Out of the box is where I live".
	-- Cara "Starbuck" Thrace, Battlestar Galactica.


From vanderaj at greebo.net  Tue Mar 14 20:48:07 2006
From: vanderaj at greebo.net (Andrew van der Stock)
Date: Wed, 15 Mar 2006 12:48:07 +1100
Subject: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in Ajax
	technology?
In-Reply-To: <000801c647d0$82b92820$6601a8c0@agi.alexandergroupinc.com>
References: <000801c647d0$82b92820$6601a8c0@agi.alexandergroupinc.com>
Message-ID: <70FC217E-8921-4D63-82CC-893C8910A672@greebo.net>

Yes! :)

I am speaking at the OWASP EU conference in Belgium (I hope people  
speak English 'cos my French is now quite appalling) at the end of  
May, and I have a paper submission for O'Reilly's OSCON in early  
July. I am still mulling over whether to submit a proposal to  
BlackHat as although I love junkets, I can't do too many - I have to  
work as well :)

Next, once the chapter is released, it will be a major new addition  
to the OWASP Guide 2.1, and I'm sure we'll be doing something about  
promoting it at that point.

There's not really any technology required to secure Ajax; it's all  
about the architecturally correct location of authorization,  
validation and preventing injection attacks. There's no magic  
technical bullet, WAF, or similar which can help fix these things.

The issues with Ajax aren't really new, it's just that devs are  
introducing new classes of vulnerability because they have forgotten  
the hard lessons learnt in the past.

thanks,
Andrew

On 15/03/2006, at 12:33 PM, Eric Swanson wrote:

> My question: How does OWASP plan to educate the public regarding  
> security
> concerns raised by AJAX and, indeed, any new methodology or  
> technology and
> what is its plan to develop tools that translate this education into
> practice?  *AJAX and related methodologies should be addressed by  
> all groups
> within OWASP, so I'm guessing that the .NET group isn't the only group
> actively discussing it.  (AFLAX - a Flash version also raises the same
> concerns.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2234 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060315/9effd791/attachment.bin 

From ken at krvw.com  Wed Mar 15 17:32:41 2006
From: ken at krvw.com (Kenneth R. van Wyk)
Date: Wed, 15 Mar 2006 17:32:41 -0500 (EST)
Subject: [SC-L] CFP -- HICSS 2007
Message-ID: <3226.208.54.94.17.1142461961.squirrel@mail.krvw.com>

Greetings SC-L subscribers:

FYI, a Call for Participation for the Hawaii International Conference on System Sciences
(HICSS) Secure Software Architecture, Design, Implementation and Assurance (SSADIA)
Minitrack is out.  The conference takes place 3-6 January 2007 in Waikoloa on the Big Island
of Hawaii.

The CFP can be found below.

Cheers,

Ken van Wyk
-- 
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

==================================================
HICSS-40: Call for Papers

Secure Software Architecture, Design, Implementation and Assurance (SSADIA) Minitrack
Hawaii International Conference on System Sciences
Waikoloa, Big Island, Hawaii, January 3-6, 2007

Call For Participation
The Secure Software Architecture, Design, Implementation and Assurance minitrack focuses on
the research and automation required to develop secure software systems that do not
compromise other system properties such as performance or reliability. Current security
engineering methods are demonstrably inadequate, as software vulnerabilities are currently
being discovered at the rate of over 4,000 per year. These vulnerabilities are caused by
software designs and implementations that do not adequately protect systems and by
development practices that do not focus sufficiently on eliminating implementation defects
that result in security flaws. An opportunity exists for systematic improvement that can
lead to secure software architectures, designs, and implementations.

The following topics are appropriate topics for research papers:
- Static analysis tools and techniques for detecting security flaws and software
vulnerabilities in source or binary code
- Dynamic analysis tools for detecting security flaws and software vulnerabilities in source
or binary code
- Model checking tools for detecting security flaws and software vulnerabilities in software
systems
- Software architectures and designs for securing against denial-of-service attacks and
other software exploits
- Coding practices for improved security and secure library implementations
- Computational security engineering
- Other tools and techniques for reducing or eliminating vulnerabilities during development
and maintenance

Co-Chairs
Sven Dietrich, CERT
Daniel Plakosh, CERT/CC
Robert C. Seacord, CERT/CC

Address email to the minitrack chairs to ssadia at cert.org.

Program Committee
Julia Allen, SEI/CMU
Hal Burch, CERT/CC
Brian Chess, Fortify Software
Bob Fleck, Secure Software
Michael Howard, Microsoft
Derek M. Jones, Knowledge Software Ltd
Alan Krassowski, Symantec
Fred Long, University of Wales, Aberystwyth
Tom Longstaff, 	CERT
Robert Martin, MITRE
Leon Moonen, Delft University of Technology
James W. Moore, MITRE
Samuel Redwine, James Madison University
David Riley, University of Wisconsin - La Crosse
John Steven, Cigital
Carol Woody, CERT
Kenneth R. van Wyk, KRvW Associates, LLC

Paper Review And Proceedings Publication
HICSS conferences are devoted to the most relevant advances in the information, computer,
and system sciences, and encompass developments in both theory and practice. Accepted papers
may be theoretical, conceptual, tutorial, or descriptive in nature. Submissions must not
have been previously published. Submissions undergo a double-blind peer referee process.
Those selected for presentation at the conference will be published in the HICSS-40
conference proceedings.

Instructions For Paper Submission
HICSS papers must contain original material not previously published nor currently submitted
elsewhere.
It is recommended that authors contact the Minitrack Chair(s) by email for guidance
regarding appropriate content.
HICSS will conduct double-blind reviews of each submitted paper.
Submit full paper according to detailed author instructions to be found on the HICSS web
site (http://www.hicss.hawaii.edu/hicss_40/apahome40.htm ) by May 1.
The preferred format for papers submission is PDF.

Important 2006 Dates
June 15, 2006 - Authors may contact Minitrack Chairs for guidance and indication of
appropriate content at any time before June 15.
August 15, 2006 - Deadlines to submit full papers. All papers will be submitted in double
column publication format and limited to 10 pages including diagrams and references. Papers
undergo a double-blind review.
September 15, 2006 - Authors receive notification regarding paper acceptances through the
review system, not from the Minitrack Chairs. Acceptance may be conditional; revisions may
be requested before final acceptance of paper. Attendance by at least one author and
presentation of the paper at the conference is a requirement of acceptance.
September 16, 2006 - Authors submit final version of papers following author instructions
posted on this site. At least one author of each paper must register by this date with
specific plans to attend the conference to present the paper. Early registration fee applies
until this date.
September 17, 2006 - General registration fee applies from this date through December 15.
December 1, 2006 - Cancellation penalties apply after this date. Please see cancellation
policy for details. If conference registration is cancelled, paper will not be included in
the proceedings.
December 15, 2006 - Hotel rates are not guaranteed after this date. On-site registration fee
applies after this date. No refunds after this date.




From gwc at acm.org  Wed Mar 15 19:28:37 2006
From: gwc at acm.org (George Capehart)
Date: Wed, 15 Mar 2006 19:28:37 -0500
Subject: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in Ajax
	technology?
In-Reply-To: <1f1991610603140835y30af893v487e2530de220459@mail.gmail.com>
References: <99dd65a800034f4ba039d6bf625689f6@ddplus.net>
	<4415D64C.8020200@acm.org>
	<1f1991610603140835y30af893v487e2530de220459@mail.gmail.com>
Message-ID: <4418B135.20904@acm.org>

Yvan Boily wrote:
> Hi George,
> 
> I think a much more eloquent form of what you are saying is that
> validation must be performed each time data crosses a security
> boundary.

Hello Yvan,

I absolutely agree.  Wish I'd said it myself . . .  :)
> 
> The challenge is in helping people to understand what a security boundary is.

Errrmmmmmm.  Into understatement these days, eh?  :)

Thanks for your comments.

Best regards,

/g


From ge at linuxbox.org  Thu Mar 16 04:10:02 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Thu, 16 Mar 2006 11:10:02 +0200
Subject: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in Ajax
	technology?
In-Reply-To: <4418B135.20904@acm.org>
References: <99dd65a800034f4ba039d6bf625689f6@ddplus.net>	<4415D64C.8020200@acm.org>	<1f1991610603140835y30af893v487e2530de220459@mail.gmail.com>
	<4418B135.20904@acm.org>
Message-ID: <44192B6A.9050508@linuxbox.org>

George Capehart wrote:
> Yvan Boily wrote:
> 
>>Hi George,
>>
>>I think a much more eloquent form of what you are saying is that
>>validation must be performed each time data crosses a security
>>boundary.
> 
> 
> Hello Yvan,
> 
> I absolutely agree.  Wish I'd said it myself . . .  :)

In other words, it's just Javascript. Do your coding securely. I don't 
like the big buzz. This is nothing new.


>>The challenge is in helping people to understand what a security boundary is.
> 
> 
> Errrmmmmmm.  Into understatement these days, eh?  :)

I wish I had a good Yoda quote right now, but all I can come up with is 
Terry Goodkind, which I feel very ashamed of.

	Gadi.

-- 
http://blogs.securiteam.com/

"Out of the box is where I live".
	-- Cara "Starbuck" Thrace, Battlestar Galactica.


From gwc at acm.org  Thu Mar 16 19:17:36 2006
From: gwc at acm.org (George Capehart)
Date: Thu, 16 Mar 2006 19:17:36 -0500
Subject: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in Ajax
	technology?
In-Reply-To: <44192B6A.9050508@linuxbox.org>
References: <99dd65a800034f4ba039d6bf625689f6@ddplus.net>
	<4415D64C.8020200@acm.org>
	<1f1991610603140835y30af893v487e2530de220459@mail.gmail.com>
	<4418B135.20904@acm.org> <44192B6A.9050508@linuxbox.org>
Message-ID: <441A0020.5080609@acm.org>

Gadi Evron wrote:
> 
> In other words, it's just Javascript. Do your coding securely. I don't
> like the big buzz. This is nothing new.

Hola Gadi!

*grin*  I absolutely agree.  It is absolutely not new . . .

>>> The challenge is in helping people to understand what a security
>>> boundary is.

<rant>
The problem is:  We /*still*/ have _this_ problem . . .  :}  It's been my
experience over the years that very, very, very few system architects
understand the concept and design systems appropriately.  Having said that,
I'm not shaking my finger at them.  If it were important to $MANAGEMENT that
the system design be aware of it and respect it, it would be so.  After all,
in the end, this is all about risk management.  /*That*/ is management's job.
</rant>

Apologies, but I have to get it off my chest every now and then . . .  ;>

> I wish I had a good Yoda quote right now, but all I can come up with is
> Terry Goodkind, which I feel very ashamed of.

NP.  Thanks for turning me onto a new author!  :)

Cheers,

/g


From dinis at ddplus.net  Sat Mar 25 06:39:19 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Sat, 25 Mar 2006 11:39:19 +0000
Subject: [SC-L] 
 4 Questions: Latest IE vulnerability, Firefox vs IE security, User
 vs Admin risk profile, and browsers coded in 100% Managed Verifiable code
Message-ID: <44252BE7.9040603@ddplus.net>

Another day, and another unmanaged-code remote command execution in IE.

What is relevant in the ISS alert (see end of this post) is that IE 7
beta 2 is also vulnerable, which leads me to this post's questions:

1) Will IE 7.0 be more secure than IE 6.0 (i.e. will after 2 years it
being released the number of exploits and attacks be smaller than today?
and will it be a trustworthy browser?)

2) Given that Firefox is also build on unmanaged code, isn't Firefox as
insecure as IE and as dangerous

3) Since my assets as a user exist in user land, isn't the risk profile
of malicious unmanaged code (deployed via IE/Firefox) roughly the same
if I am running as a 'low privileged' user or as administrator? (at the
end of the day, in both cases the malicious code will still be able to:
access my files, access all websites that I have stored credentials in
my browser (cookies or username / passwords pairs), access my VPNs,
attack other computers on the local network, install key loggers,
establish two way communication with a Internet based boot net, etc ...
(basically everything except rooting the boot, disabling AVs and
installing persistent hooks (unless of course this malicious code
executes a successful escalation of privilege attack)))

4) Finally, isn't the solution for the creation of secure and
trustworthy Internet Browsing environments the development of browsers
written in 100% managed and verifiable code, which execute on a secure
and very restricted Partially Trusted Environments? (under .Net, Mono or
Java). This way, the risk of buffer overflows will be very limited, and
when logic or authorization vulnerabilities are discovered in this
'Partially Trusted IE' the 'Secure Partially Trusted environment' will
limit what the malicious code (i.e. the exploit) can do.
   
This last question/idea is based on something that I have been defending
for quite a while now (couple years) which is: "Since it is impossible
to create bug/vulnerability free code, our best solution to create
securer and safer computing environments (compared to the ones we have
today), is to execute those applications in sandboxed environments".

Basically we need to be able to safely handle malicious code, executed
in our user's session, in a web server, in a database engine, etc... Our
current security model is based on the concept of preventing malicious
code from being executed (something which is becoming more and more
impossible to do) versus the model of 'malicious payload containment' 
(i.e. Sandboxing).

And in my view, creating sandboxes for unmanaged code is very hard or
even impossible (at least in the current Windows Architecture), so the
only solution that I am seeing at the moment is to create sandboxes for
managed and verifiable code.

Fortunately, both .Net and Java have architectures that allow the
creation of these 'secure' environments (CAS and Security Manager).

Unfortunately, today there is NO BUSINESS case to do this. The paying
customers are not demanding products that don't have the ability to
'own' their data center, software companies don't want to invest in the
development of such applications, nobody is liable for anything,
malicious attackers have not exploited this insecure software
development and deployment environment (they have still too much to
money to harvest via Spyware/Spam) and the Framework developers
(Microsoft, Sun, Novell, IBM, etc...) don't want to rock the boat and
explain their to their clients that they should be demanding (and only
paying for) applications that can be safely executed in their corporate
environment (i.e. ones where malicious activities are easily detectable,
preventable and contained (something which I believe we only have a
chance of doing with managed and verifiable code)).

I find ironic the fact that Microsoft now looks at Oracle and says 'We
are so much better than them on Security', when the reason why Oracle
has not cared (so far) about security is the same why Microsoft doesn't
make any serious efforts to promote and develop Partially Trusted .Net
applications: There is no business case for both. Btw, if Microsoft
publicly admitted that the current application development practices of
ONLY creating Full Trust code IS A MASSIVE PROBLEM, and if Microsoft
spent considerable resources and focus in turning that boat around, the
resulting 'partially trusted application' environment (which could then
be enforced by default to all locally executed code) would have more
impact in creating a secure and trustworthy computing environment that
all LUAs and UACs put together :)

Finally, you might have noticed that whenever I talked about 'managed
code', I mentioned 'managed and verifiable code', the reason for this
distinction, is that I discovered recently that .Net code executed under
Full Trust  can not be (or should not be) called 'managed code', since
the .Net Framework will not verify that code (because it is executed
under Full Trust). This means that I can write MSIL code which breaks
type safety and execute it without errors in a Full Trust .Net environment.

...in the hope that somebody is listening ....

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net
 
-------- Original Message --------
Subject:     ISS ProIStection Brief: Microsoft IE createTextRange()
Remote Command Execution
Date:     Fri, 24 Mar 2006 14:55:42 -0500 (EST)
From:     X-Force <xforce at iss.net>
To:     alert at iss.net



Internet Security Systems Protection Alert
March 24, 2006

Microsoft IE createTextRange() Remote Command Execution

Version: 1.0


Summary:
A vulnerability was reported in the way Microsoft Internet Explorer
handles unexpected method calls.  Exploitation of this vulnerability
could lead to remote code execution under the security context of the user
viewing a malicious web page.

Description:
Internet Explorer does not properly handle the createTextRange()
method when invoked on a checkbox object.  Because of this, a call is
made to a predictable location in memory.  An attacker can easily
fill this predictable location in memory with malicious code to
be executed.

Business Impact:
Compromise of the operating system can lead to exposure of
confidential information, loss of productivity, and further network
compromise. Successful exploitation of this vulnerability could
be used to gain unauthorized access to one.s networks and machines.

Affected Products:
.    Microsoft Corporation: Microsoft Internet Explorer 6.0
.    Microsoft Corporation: Microsoft Internet Explorer 6.0 SP1
.    Microsoft Corporation: Microsoft Internet Explorer 7 Beta 2
.    Microsoft Corporation: Windows 95
.    Microsoft Corporation: Windows 98
.    Microsoft Corporation: Windows 98 Second Edition
.    Microsoft Corporation: Windows Me
.    Microsoft Corporation: Windows XP
.    Microsoft Corporation: Windows 2000 Any version
.    Microsoft Corporation: Windows 2003 Any version
.    Microsoft Corporation: Windows NT 4.0
______________________________________________________________________

About Internet Security Systems, Inc.
Internet Security Systems, Inc. (ISS) is the trusted security advisor to
thousands of the world.s leading businesses and governments, providing
preemptive protection for networks, desktops and servers. An established
leader in security since 1994, ISS. integrated security platform
automatically protects against both known and unknown threats, keeping
networks up and running and shielding customers from online attacks before
they impact business assets. ISS products and services are based
on the proactive security intelligence of its X-Force? research and
development team . the unequivocal world authority in vulnerability and
threat research. ISS. product line is also complemented by
comprehensive Managed Security Services. For more information, visit
the Internet Security Systems Web site at www.iss.net or call 800-776-2362.

Copyright (c) 2006 Internet Security Systems, Inc. All rights reserved
worldwide.

This document is not to be edited or altered in any way without the
express written consent of Internet Security Systems, Inc. If you wish
to reprint the whole or any part of this document, please email

xforce at iss.net for permission. You may provide links to this document
from your web site, and you may make copies of this document in
accordance with the fair use doctrine of the U.S. copyright laws.

Disclaimer: The information within this paper may change without notice.
Use of this information constitutes acceptance for use in an AS IS
condition. There are NO warranties, implied or otherwise, with regard to
this information or its use. Any use of this information is at the
user's risk. In no event shall the author/distributor (Internet Security
Systems X-Force) be held liable for any damages whatsoever arising out
of or in connection with the use or spread of this information.

X-Force PGP Key available on MIT's PGP key server and PGP.com's key
server, as well as at http://www.iss.net/security_center/sensitive.php
Please send suggestions, updates, and comments to: X-Force

xforce at iss.net of Internet Security Systems, Inc.


xforce at iss.net of Internet Security Systems, Inc.




From Kevin.Wall at qwest.com  Sat Mar 25 09:42:09 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Sat, 25 Mar 2006 08:42:09 -0600
Subject: [SC-L] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, Uservs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
Message-ID: <CF8B26B8B49184429CB084616B0019300102D989@itomae2km05.AD.QINTRA.COM>

Dinis,

Dinis Cruz wrote...

	Finally, you might have noticed that whenever I talked
	about 'managed code', I mentioned 'managed and verifiable code',
	the reason for this distinction, is that I discovered recently
	that .Net code executed under Full Trust can not be (or should
	not be) called 'managed code', since the .Net Framework will
	not verify that code (because it is executed under Full Trust).
	This means that I can write MSIL code which breaks type safety
	and execute it without errors in a Full Trust .Net environment.

Indeed this is somewhat surprising that there is no byte-code
verification
in place, especially for strong typing, since when you think about it,
this is not too different than the "unmanaged" code case.

Apparently the whole "managed" versus "unmanaged" code only has to do
with whether or not garbage collection is attempted. Given the fact
that Microsoft has added almost 50 new keywords just for their new
"managed C++", one certainly could hope they could do better than
this--IF this applies to ALL "managed" code in general.

However, the real question is "is this true for ALL managed code or
only managed code in the .NET Framework"? If it is the latter, I don't
see it as being much different where Java java.* packages may use
"native"
code (via JNI) in (say) rt.jar to interface with OS-level constructs.
I believe that such code is fully-trusted in the JVM as well. Of course,
it is reasonable to ask of Sun Microsystems and Microsoft to restrict
such trust
for "native" and "managed" code (respectively) by requiring it be
limited
to digitally signed jars / assemblies signed by trusted sources that are
verified at runtime when these jars / assemblies are first loaded. This
could
be extended so that the "trusted sources" ultimately could be defined
by the end users (or their administrators), but by default, it would
include
the vendors (Sun and Microsoft) themselves. I recall early versions of
Sun's
domestic JCE jars that were distributed as separate jars. The
verification
of the signatures for these signed jars significantly slowed down the
initial
loading of those jars, but after verification, it had little, if any
performance impact. Of course if software quality improvement does not
take
place in these companies, their signing would be somewhat vacuous. But
it
would be better than nothing, since at least all such code would not be
fully trusted by default.

Of course (not to open another can of worms) if we could actually
enforce
liability for software just as we commonly do with other manufactured
products, we problably wouldn't need some elaborate constructs to ensure
secure coding. Because once some of the major vendors had had their feet
held to the fire and been burned by millions or billions in lawsuits,
I suspect all of a sudden they would SEE a valid business reason where
none existed before. (Usual company disclaimers apply.)

Comments?
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit



From ljknews at mac.com  Sat Mar 25 08:55:32 2006
From: ljknews at mac.com (ljknews)
Date: Sat, 25 Mar 2006 08:55:32 -0500
Subject: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE
	security, User vs Admin risk profile, and browsers coded in 100% Managed
	Verifiable code
In-Reply-To: <44252BE7.9040603@ddplus.net>
References: <44252BE7.9040603@ddplus.net>
Message-ID: <p05200f3bc04afb382293@[192.168.1.254]>

At 11:39 AM +0000 3/25/06, Dinis Cruz wrote:

> 3) Since my assets as a user exist in user land, isn't the risk profile
> of malicious unmanaged code (deployed via IE/Firefox) roughly the same
> if I am running as a 'low privileged' user or as administrator? (at the

If the administrator's assets are compromised, all users of the system
will have their assets compromised.

> end of the day, in both cases the malicious code will still be able to:
> access my files, access all websites that I have stored credentials in
> my browser (cookies or username / passwords pairs), access my VPNs,

Certainly users should not store credentials in software on a computer.

> attack other computers on the local network, install key loggers,

If one is not the administrator, there should be no way to install
software.  If there is, the operating system is underprotected.

> establish two way communication with a Internet based boot net, etc ...

At least one aspect of that is a design defect in TCP/IP, allowing
unprivileged users to create a port to receive inbound connections.
Other networking protocols avoid that flaw.
-- 
Larry Kilgallen


From dinis at ddplus.net  Sun Mar 26 20:34:57 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Mon, 27 Mar 2006 02:34:57 +0100
Subject: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, Uservs Admin risk profile, and browsers coded in
	100% Managed Verifiable code
In-Reply-To: <CF8B26B8B49184429CB084616B0019300102D989@itomae2km05.AD.QINTRA.COM>
References: <CF8B26B8B49184429CB084616B0019300102D989@itomae2km05.AD.QINTRA.COM>
Message-ID: <44274141.3040306@ddplus.net>

Hi Kevin
> Indeed this is somewhat surprising that there is no byte-code
> verification
> in place, especially for strong typing, since when you think about it,
> this is not too different than the "unmanaged" code case.
>
>   
Well there is some byte coding verification. For example if you
manipulate MSIL so that you create calls to private members (something
that you can't compile with VS.NET) you will get a runtime error saying
that you tried to access a private member. So in this case there is some
verification.

What I found surprising was how little verification was done by the CLR
when verification is disabled, see for example these issues:

    * Possible Type Confusion issue in .Net 1.1 (only works in Full
      Trust) <http://owasp.net/blogs/dinis_cruz/archive/2005/11/08/36.aspx>
    * Another Full Trust CLR Verification issue: Exploiting Passing
      Reference Types by Reference
      <http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/393.aspx>
    * Another Full Trust CLR Verification issue: Changing Private Field
      using Proxy Struct
      <http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/394.aspx>
    * Another Full Trust CLR Verification issue: changing the Method
      Parameters order
      <http://owasp.net/blogs/dinis_cruz/archive/2005/12/26/390.aspx>
    * C# readonly modifier is not inforced by the CLR (when in Full
      Trust <http://owasp.net/blogs/dinis_cruz/archive/2005/12/26/390.aspx>
    * Also related: JIT prevents short overflow (and PeVerify doesn't
      catch it)
      <http://owasp.net/blogs/dinis_cruz/archive/2006/01/10/422.aspx>
      and ANSI/UNICODE bug in System.Net.HttpListenerRequest
      <http://www.owasp.net//blogs/dinis_cruz/archive/2005/12/17/349.aspx>

Basically, Microsoft decided against performing verification on Full
Trust code (which is 99% of the .Net code out there remember). Their
argument (I think) is: "if it is Full Trust then it can jump to
unmanaged code anyway, so all bets are off" (I am sure I have seen this
documented somewhere in a Microsoft book, KB article or blog, but can't
seem to find it (for the Microsofties that are reading this (if any),
can  you post some links please? thanks))

Apart from a basic problem which is "You cannot trust Full Trust code
EVEN if it doesn't make ANY direct unmanaged call or reflection" there
is a much bigger one.

When (not if) Applications start to be developed so that they run in
secure Partially Trusted environments,I think that the developers will
find that they code will suffer from an immediate performance hit due to
the fact that Verification is now being done on their code (again for
the Microsofties that are reading this (if any), can you post some data
related to the performance impact of the current CLR Verification
process? thanks)
> Apparently the whole "managed" versus "unmanaged" code only has to do
> with whether or not garbage collection is attempted. 
yes, although I still think that we should fight for the words "Managed
Code" to include verification

> However, the real question is "is this true for ALL managed code or
> only managed code in the .NET Framework"? 
I am not a Java expert, but I think that the Java Verifier is NOT used
on Apps that are executed with the Security Manager disabled (which I
believe is the default setting) or are loaded from a local disk (see
"... applets loaded via the file system are not passed through the byte
code verifier" in http://java.sun.com/sfaq/)
> Of course if software quality improvement does not take
> place in these companies, their signing would be somewhat vacuous. Butit
> would be better than nothing, since at least all such code would not be
> fully trusted by default.
>   
Yes, and note that I strongly defend that: "All local code must NOT be
given Full Trust by default" (at the moment it is)

Dinis

PS: For the Microsofties that are reading this (if any) ....  sorry for
the irony and I hope I am not offending anyone, but.... WHEN are you
going to join this conversion? (i.e. reply to this posts)

I can only see 4 reasons for your silence: a) you are not reading these
emails, b) you don't care about these issues, c) you don't want to talk
about them or  d) you don't know what to say.

Can you please engage and publicly participate in this conversation ...

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060327/dc79b065/attachment.html 

From dinis at ddplus.net  Sun Mar 26 21:22:20 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Mon, 27 Mar 2006 03:22:20 +0100
Subject: [SC-L] Re: [Owasp-dotnet] RE: 4 Questions: Latest IE vulnerability,
 Firefox vs IE security, User vs Admin risk profile,
 and browsers coded in 100% Managed Verifiable code
In-Reply-To: <020101c65054$73ffd9a0$1204a8c0@intranet.aspectsecurity.com>
References: <020101c65054$73ffd9a0$1204a8c0@intranet.aspectsecurity.com>
Message-ID: <44274C5C.4080108@ddplus.net>

Hi Jeff, comments inline

Jeff Williams wrote:
> Great topics.
>
> I'm a huge fan of sandboxes, but Dinis is right, the market hasn't really
> gotten there yet. No question that it would help if it was possible to run
> complex software like a browser inside a sandbox that restricted its ability
> to do bad things, even if there are vulnerabilities (or worse -- malicious
> code) in them.  
Absolutely, and do you see any other alternative? (or we should just
continue to TRUST every bit of code that is executed in our computers?
and TRUST every single developer/entity that had access to that code
during its development and deployment?)
>  I'm terrified about the epidemic use of libraries that are
> just downloaded from wherever (in both client and server applications). All
> that code can do *whatever* it wants in your environments folks!
>
>   
Yes they can, and one of my original questions was 'When considering the
assets, is there REALLY any major differences between running code as
normal user versus as an administrator?"
> Sandboxes are finally making some headway. Most of the Java application
> servers (Tomcat included) now run with their sandbox enabled (albeit with a
> weak policy). And I think the Java Web Start system also has the sandbox
> enabled.  So maybe we're making progress.
>   
True, but are these really secure sandboxes?

I am not a Java expert so I can't give you specific examples, but on the
.Net Framework a Partially Trusted 'Sandbox' which contains an
UnamanagedCode, MemberAccess Reflection or SkipVerification Permission,
should not be called a 'Sandbox' since it can be easily compromised.
> But, if you've ever tried to configure the Java security policy file, use
> JAAS, or implement the SecurityManager interface, you know that it's *way*
> too hard to implement a tight policy this way.
And .Net has exactly the same problem. It is super complex to create a
.Net application that can be executed in a secure Partially Trusted Sandbox.
>   You end up granting all
> kinds of privileges because it's too difficult to do it right.  
And the new VS2005 makes this allocation of privileges very easy: "Mr.
developer, your application crashed because it didn't have the required
permissions, Do you want to add these permissions, Yes No? ....
(developer clicks yes) ... "You are adding the permission
UnamanagedCodePermission, do you sure, Yes No? ... (developer clicks yes
(with support from application architect and confident that all
competitor Applications require similar permissions))"
> And only the
> developer of the software could reasonably attempt it, which is backwards,
> because it's the *user* who really needs it right. 
Yes, it is the user's responsibility (i.e. its IT Security and Server
Admin staff) to define the secure environment (i.e the Sandbox) that 3rd
party or internal-developed applications are allocated inside their data
center,

> It's possible that sandboxes are going the way of multilevel security (MLS).
> A sort of ivory tower idea that's too complex to implement or use. 
I don't agree that the problem is too complex. What we have today is
very complex architectures / systems with too many interconnections.

Simplify the lot, get enough resources with the correct focus involved,
are you will see that it is doable.
> But it
> seems like a really good idea that we should try to make practical. But even
> if they do start getting used, we can't just give up on getting software
> developers to produce secure code.  There will always be security problems
> that sandboxes designed for the platform cannot help with.
>   
Of course, I am not saying that developers should produce insecure code,
I am the first to defend that developers must have a firm and solid
understanding of the tools and technologies  that they use, and also as
important, the security implications of their code.
> I'm with Dinis that the only way to get people to care is to fix the
> externalities in the software market and put the burden on those who can
> most easily avoid the costs -- the people who build the software. Maybe then
> the business case will be more clear.
>   
Yes, but the key here is not with money (since that would also kill
large chunks of the Open Source world).

One of the solutions that I like, is the situation where all software
companies have (by law) to disclose information about the
vulnerabilities that they are aware of (look at the Eeye model of
disclosing information about 'reported but unpatched vulnerabilities').

Basically, give the user data (as in information) that he can digest and
understand, and you will see the user(s) making the correct decision(s).
> (Your last point about non-verified MSIL is terrifying. I can't think of any
> reason why you would want to turn off verification -- except perhaps startup
> speed. But that's a terrible tradeoff.)
>   
See my previous post (on this same thread) about this issue, but I think
that .Net is not alone in skipping verification for locally executed code :)

Dinis Cruz
Owasp .Net Project
www.owasp.net




From mouse at Rodents.Montreal.QC.CA  Mon Mar 27 03:19:01 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Mon, 27 Mar 2006 03:19:01 -0500 (EST)
Subject: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE
	security, User vs Admin risk profile, and browsers coded in 100% Managed
	Verifiable code
In-Reply-To: <p05200f3bc04afb382293@[192.168.1.254]>
References: <44252BE7.9040603@ddplus.net>
	<p05200f3bc04afb382293@[192.168.1.254]>
Message-ID: <200603270824.DAA09788@Sparkle.Rodents.Montreal.QC.CA>

> At least one aspect of that is a design defect in TCP/IP, allowing
> unprivileged users to create a port to receive inbound connections.

I don't think it's fair to call that any kind of defect in TCP/IP.
There is nothing at all in TCP or IP that says anything whatsoever
about what privilege may or may not be necessary to establish a listen
for incoming connections.  If you must call this a flaw, at least place
the "flaw" where it actually is - in the implementation(s).

I'm also not convinced it's a flaw at all; calling it one sounds to me
like viewing a TCP stack designed for one environment from the point of
view of a drastically different environment.  In the environment most
current TCP stacks were designed for, listening for connections on a
"high" port should not be a restricted operation.  In calling that a
defect, you appear to be looking on it from a point of view which
disagrees with that, which actually means just that you've picked the
wrong TCP stack for your environment, not that there's anything wrong
with the stack for its design environment.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From pilonmntry at yahoo.com  Mon Mar 27 00:58:10 2006
From: pilonmntry at yahoo.com (Pilon Mntry)
Date: Sun, 26 Mar 2006 21:58:10 -0800 (PST)
Subject: [SC-L] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <242a0a8f0603251814q650e0424sb9db6252bb168880@mail.gmail.com>
Message-ID: <20060327055810.3335.qmail@web61312.mail.yahoo.com>


> of creating a
> full-featured
> browser, from scratch, with usability as good as IE
> and Firefox
> strikes me as a fairly tricky project. 

I agree.

> What about
> using the
> facilities already provided by the OS to enforce the
> sandbox? 

But then will it be possible to prevent buffer
overflows, still running on unmanaged code?

Very nice points by Dinis, esp. the one about the
"advantages" of using our boxes with less privileges
(for internet browsing).

-pilon

--- Brian Eaton <eaton.lists at gmail.com> wrote:

> On 3/25/06, Dinis Cruz <dinis at ddplus.net> wrote:
> > 4) Finally, isn't the solution for the creation of
> secure and
> > trustworthy Internet Browsing environments the
> development of browsers
> > written in 100% managed and verifiable code, which
> execute on a secure
> > and very restricted Partially Trusted
> Environments? (under .Net, Mono or
> > Java). This way, the risk of buffer overflows will
> be very limited, and
> > when logic or authorization vulnerabilities are
> discovered in this
> > 'Partially Trusted IE' the 'Secure Partially
> Trusted environment' will
> > limit what the malicious code (i.e. the exploit)
> can do.
> 
> I am less than enthusiastic about most of the
> desktop java
> applications I use.  They are, for the most part,
> sluggish, memory
> gobbling beasts, prone to disintegration if I look
> at them cross-eyed
> or click the mouse too frequently.
> 
> Usability problems with java applications are not
> necessarily due to
> managed code, of course, but the idea of creating a
> full-featured
> browser, from scratch, with usability as good as IE
> and Firefox
> strikes me as a fairly tricky project.  What about
> using the
> facilities already provided by the OS to enforce the
> sandbox?  Rather
> than scrapping the existing codebases, start running
> them with
> restricted rights.  Use mandatory access control
> systems to make sure
> the browser doesn't overstep its bounds.
> 
> Regards,
> Brian
> 
>
-------------------------------------------------------------------------
> This List Sponsored by: SpiDynamics
> 
> ALERT: "How A Hacker Launches A Web Application
> Attack!"
> Step-by-Step - SPI Dynamics White Paper
> Learn how to defend against Web Application Attacks
> with real-world
> examples of recent hacking methods such as: SQL
> Injection, Cross Site
> Scripting and Parameter Manipulation
> 
>
https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl
>
--------------------------------------------------------------------------
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From ljknews at mac.com  Mon Mar 27 07:40:42 2006
From: ljknews at mac.com (ljknews)
Date: Mon, 27 Mar 2006 07:40:42 -0500
Subject: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE
	vulnerability, Firefox vs IE security, Uservs Admin risk profile, and
	browsers coded in	100% Managed Verifiable code
In-Reply-To: <44274141.3040306@ddplus.net>
References: <CF8B26B8B49184429CB084616B0019300102D989@itomae2km05.AD.QINTRA.COM>
	<44274141.3040306@ddplus.net>
Message-ID: <p05200f04c04d8d8bb381@[192.168.1.254]>

At 2:34 AM +0100 3/27/06, Dinis Cruz wrote:

> PS: For the Microsofties that are reading this (if any) ....  sorry for
>the irony and I hope I am not offending anyone, but.... WHEN are you going
>to join this conversion? (i.e. reply to this posts)
>
> I can only see 4 reasons for your silence: a) you are not reading these
>emails, b) you don't care about these issues, c) you don't want to talk
>about them or  d) you don't know what to say.

e) Your employer has a company policy against such participation.
-- 
Larry Kilgallen


From stephen at corsaire.com  Mon Mar 27 05:43:33 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Mon, 27 Mar 2006 17:43:33 +0700
Subject: [SC-L] A Modular Approach to Data Validation in Web Applications
In-Reply-To: <20060321065259.91360.qmail@web61313.mail.yahoo.com>
References: <20060321065259.91360.qmail@web61313.mail.yahoo.com>
Message-ID: <3B1B3C48-B30E-41A9-8EDB-1AB757788CB8@corsaire.com>


A Corsaire White Paper:

A Modular Approach to Data Validation in Web Applications

Outline:

Data that is not validated or poorly validated is the root cause of a  
number of serious security vulnerabilities affecting applications.  
This paper presents a modular approach to performing thorough data  
validation in modern web applications so that the benefits of modular  
component based design; extensibility, portability and re-use, can be  
realised. It starts with an explanation of the vulnerabilities  
introduced through poor validation and then goes on to discuss the  
merits and drawbacks of a number of common data validation strategies  
such as:
- Validation in an external Web Application Firewall;
- Validation performed in the web tier (e.g. Struts); and
- Validation performed in the domain model.
Finally, a modular approach is introduced together with practical  
examples of how to implement such a scheme in a web application.

Download:

http://www.corsaire.com/white-papers/060116-a-modular-approach-to- 
data-validation.pdf








From mshines at purdue.edu  Mon Mar 27 08:22:10 2006
From: mshines at purdue.edu (Michael S Hines)
Date: Mon, 27 Mar 2006 08:22:10 -0500
Subject: FW: [SC-L]  4 Questions: Latest IE vulnerability,
	Firefox vs IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
Message-ID: <001e01c651a1$749600d0$4fa7d280@OS00009>

Isn't it possible to break out of the sandbox even with managed code? (That is, can't
managed code call out to unmanaged code, i.e. Java call to C++)?  I was thinking this was
documented for Java - perhaps for various flavors of .Net too?  

-----------------------------------
Michael S Hines
mshines at purdue.edu 

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of
Dinis Cruz
Sent: Saturday, March 25, 2006 6:39 AM
To: 'owasp-dotnet at lists.sourceforge.net'; webappsec at securityfocus.com;
SC-L at securecoding.org; full-disclosure at lists.grok.org.uk
Cc: xforce at iss.net
Subject: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs
Admin risk profile, and browsers coded in 100% Managed Verifiable code

Another day, and another unmanaged-code remote command execution in IE.

What is relevant in the ISS alert (see end of this post) is that IE 7
beta 2 is also vulnerable, which leads me to this post's questions:

1) Will IE 7.0 be more secure than IE 6.0 (i.e. will after 2 years it
being released the number of exploits and attacks be smaller than today?
and will it be a trustworthy browser?)

2) Given that Firefox is also build on unmanaged code, isn't Firefox as
insecure as IE and as dangerous

3) Since my assets as a user exist in user land, isn't the risk profile
of malicious unmanaged code (deployed via IE/Firefox) roughly the same
if I am running as a 'low privileged' user or as administrator? (at the
end of the day, in both cases the malicious code will still be able to:
access my files, access all websites that I have stored credentials in
my browser (cookies or username / passwords pairs), access my VPNs,
attack other computers on the local network, install key loggers,
establish two way communication with a Internet based boot net, etc ...
(basically everything except rooting the boot, disabling AVs and
installing persistent hooks (unless of course this malicious code
executes a successful escalation of privilege attack)))

4) Finally, isn't the solution for the creation of secure and
trustworthy Internet Browsing environments the development of browsers
written in 100% managed and verifiable code, which execute on a secure
and very restricted Partially Trusted Environments? (under .Net, Mono or
Java). This way, the risk of buffer overflows will be very limited, and
when logic or authorization vulnerabilities are discovered in this
'Partially Trusted IE' the 'Secure Partially Trusted environment' will
limit what the malicious code (i.e. the exploit) can do.
   
This last question/idea is based on something that I have been defending
for quite a while now (couple years) which is: "Since it is impossible
to create bug/vulnerability free code, our best solution to create
securer and safer computing environments (compared to the ones we have
today), is to execute those applications in sandboxed environments".

Basically we need to be able to safely handle malicious code, executed
in our user's session, in a web server, in a database engine, etc... Our
current security model is based on the concept of preventing malicious
code from being executed (something which is becoming more and more
impossible to do) versus the model of 'malicious payload containment' 
(i.e. Sandboxing).

And in my view, creating sandboxes for unmanaged code is very hard or
even impossible (at least in the current Windows Architecture), so the
only solution that I am seeing at the moment is to create sandboxes for
managed and verifiable code.

Fortunately, both .Net and Java have architectures that allow the
creation of these 'secure' environments (CAS and Security Manager).

Unfortunately, today there is NO BUSINESS case to do this. The paying
customers are not demanding products that don't have the ability to
'own' their data center, software companies don't want to invest in the
development of such applications, nobody is liable for anything,
malicious attackers have not exploited this insecure software
development and deployment environment (they have still too much to
money to harvest via Spyware/Spam) and the Framework developers
(Microsoft, Sun, Novell, IBM, etc...) don't want to rock the boat and
explain their to their clients that they should be demanding (and only
paying for) applications that can be safely executed in their corporate
environment (i.e. ones where malicious activities are easily detectable,
preventable and contained (something which I believe we only have a
chance of doing with managed and verifiable code)).

I find ironic the fact that Microsoft now looks at Oracle and says 'We
are so much better than them on Security', when the reason why Oracle
has not cared (so far) about security is the same why Microsoft doesn't
make any serious efforts to promote and develop Partially Trusted .Net
applications: There is no business case for both. Btw, if Microsoft
publicly admitted that the current application development practices of
ONLY creating Full Trust code IS A MASSIVE PROBLEM, and if Microsoft
spent considerable resources and focus in turning that boat around, the
resulting 'partially trusted application' environment (which could then
be enforced by default to all locally executed code) would have more
impact in creating a secure and trustworthy computing environment that
all LUAs and UACs put together :)

Finally, you might have noticed that whenever I talked about 'managed
code', I mentioned 'managed and verifiable code', the reason for this
distinction, is that I discovered recently that .Net code executed under
Full Trust  can not be (or should not be) called 'managed code', since
the .Net Framework will not verify that code (because it is executed
under Full Trust). This means that I can write MSIL code which breaks
type safety and execute it without errors in a Full Trust .Net environment.

...in the hope that somebody is listening ....

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net
 
-------- Original Message --------
Subject:     ISS ProIStection Brief: Microsoft IE createTextRange()
Remote Command Execution
Date:     Fri, 24 Mar 2006 14:55:42 -0500 (EST)
From:     X-Force <xforce at iss.net>
To:     alert at iss.net



Internet Security Systems Protection Alert
March 24, 2006

Microsoft IE createTextRange() Remote Command Execution

Version: 1.0


Summary:
A vulnerability was reported in the way Microsoft Internet Explorer
handles unexpected method calls.  Exploitation of this vulnerability
could lead to remote code execution under the security context of the user
viewing a malicious web page.

Description:
Internet Explorer does not properly handle the createTextRange()
method when invoked on a checkbox object.  Because of this, a call is
made to a predictable location in memory.  An attacker can easily
fill this predictable location in memory with malicious code to
be executed.

Business Impact:
Compromise of the operating system can lead to exposure of
confidential information, loss of productivity, and further network
compromise. Successful exploitation of this vulnerability could
be used to gain unauthorized access to one.s networks and machines.

Affected Products:
.    Microsoft Corporation: Microsoft Internet Explorer 6.0
.    Microsoft Corporation: Microsoft Internet Explorer 6.0 SP1
.    Microsoft Corporation: Microsoft Internet Explorer 7 Beta 2
.    Microsoft Corporation: Windows 95
.    Microsoft Corporation: Windows 98
.    Microsoft Corporation: Windows 98 Second Edition
.    Microsoft Corporation: Windows Me
.    Microsoft Corporation: Windows XP
.    Microsoft Corporation: Windows 2000 Any version
.    Microsoft Corporation: Windows 2003 Any version
.    Microsoft Corporation: Windows NT 4.0
______________________________________________________________________

About Internet Security Systems, Inc.
Internet Security Systems, Inc. (ISS) is the trusted security advisor to
thousands of the world.s leading businesses and governments, providing
preemptive protection for networks, desktops and servers. An established
leader in security since 1994, ISS. integrated security platform
automatically protects against both known and unknown threats, keeping
networks up and running and shielding customers from online attacks before
they impact business assets. ISS products and services are based
on the proactive security intelligence of its X-ForceR research and
development team . the unequivocal world authority in vulnerability and
threat research. ISS. product line is also complemented by
comprehensive Managed Security Services. For more information, visit
the Internet Security Systems Web site at www.iss.net or call 800-776-2362.

Copyright (c) 2006 Internet Security Systems, Inc. All rights reserved
worldwide.

This document is not to be edited or altered in any way without the
express written consent of Internet Security Systems, Inc. If you wish
to reprint the whole or any part of this document, please email

xforce at iss.net for permission. You may provide links to this document
from your web site, and you may make copies of this document in
accordance with the fair use doctrine of the U.S. copyright laws.

Disclaimer: The information within this paper may change without notice.
Use of this information constitutes acceptance for use in an AS IS
condition. There are NO warranties, implied or otherwise, with regard to
this information or its use. Any use of this information is at the
user's risk. In no event shall the author/distributor (Internet Security
Systems X-Force) be held liable for any damages whatsoever arising out
of or in connection with the use or spread of this information.

X-Force PGP Key available on MIT's PGP key server and PGP.com's key
server, as well as at http://www.iss.net/security_center/sensitive.php
Please send suggestions, updates, and comments to: X-Force

xforce at iss.net of Internet Security Systems, Inc.


xforce at iss.net of Internet Security Systems, Inc.


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php



From stephen at corsaire.com  Mon Mar 27 08:50:10 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Mon, 27 Mar 2006 20:50:10 +0700
Subject: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest
	IE vulnerability, Firefox vs IE security, Uservs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <033601c65153$421e1140$1204a8c0@intranet.aspectsecurity.com>
References: <033601c65153$421e1140$1204a8c0@intranet.aspectsecurity.com>
Message-ID: <A7F74BDC-4FBE-4971-AEAE-3E23F16A4507@corsaire.com>


On 27 Mar 2006, at 11:02, Jeff Williams wrote:

>
>> I am not a Java expert, but I think that the Java Verifier is NOT  
>> used on
> Apps that >are executed with the Security Manager disabled (which I  
> believe
> is the default >setting) or are loaded from a local disk (see "...  
> applets
> loaded via the file system >are not passed through the byte code  
> verifier"
> in http://java.sun.com/sfaq/)
>
> I believe that as of Java 1.2, all Java code except the core  
> libraries must
> go through the verifier, unless it is specifically disabled (java
> -noverify).

I had the same intuition about the verifier, but have just tested  
this and it is not the case.  It seems that the -noverify is the  
default setting! If you want to verify classes loaded from the local  
filesystem, then you need to explicitly add -verify to the cmd line.   
I tested this by compiling 2 classes where one accesses a public  
member of the other.  Then recompiled the other and changed the  
method access to private.  Tested on:
Jdk 1.4.2 Mac OS X
Jdk 1.5.0 Mac OS X
Jdk 1.5.0 Win XP

all behave the same.

[~/data/dev/applettest/src]java -cp . FullApp
Noone can access me!!
[~/data/dev/applettest/src]java -cp . -verify FullApp
Exception in thread "main" java.lang.IllegalAccessError: tried to  
access field MyData.secret from class FullApp at FullApp.main 
(FullApp.java:23)

Using the same code with an Applet loaded from the filesystem throws  
an IllegalAccessError exception as it should.


-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com







From dwheeler at ida.org  Mon Mar 27 12:59:55 2006
From: dwheeler at ida.org (David A. Wheeler)
Date: Mon, 27 Mar 2006 12:59:55 -0500
Subject: [SC-L] 
 4 Questions: Latest IE vulnerability, Firefox vs IE security, User
 vs Admin risk profile, and browsers coded in 100% Managed Verifiable code
References: <200603251700.k2PH02PL027665@ratsass.krvw.com>
Message-ID: <4428281B.8090501@ida.org>

Dinis Cruz said:

> Another day, and another unmanaged-code remote command execution in IE.
> 
> What is relevant in the ISS alert (see end of this post) is that IE 7
> beta 2 is also vulnerable, which leads me to this post's questions:
> 
> 1) Will IE 7.0 be more secure than IE 6.0 (i.e. will after 2 years it
> being released the number of exploits and attacks be smaller than today?
> and will it be a trustworthy browser?)

It will be "more secure", in the sense that when you start with
something that's hideously insecure, any effort is likely to make some
sort of improvement.  It might actually be noticeably more secure --
I certainly hope so -- but only time will answer that question.
MS still seems to consider IE as "baked into" the OS, something
that was noted as one of its fundamental design flaws years ago,
so there's reason to be skeptical.


> 2) Given that Firefox is also build on unmanaged code, isn't Firefox as
> insecure as IE and as dangerous

Actually, your presumption is not true.  A significant amount
of Firefox is written using XUL/Javascript, which is managed
(it has auto garbage collection, etc.).  You cannot break the
typesafety in Javascript; any attempt is stopped as a runtime error.
(Checking is all dynamic, rather than partly static, but it's ALWAYS done;
in constrast many of .NET's checks are skipped.)
Many Firefox runtime libraries are written in C/C++, but I believe that
is true for many of the low-level .NET libraries too (many of
the .NET libraries eventually call out to unmanaged libraries).
Comparing their implementations is actually not easy to do.


> 3) Since my assets as a user exist in user land, isn't the risk profile
> of malicious unmanaged code (deployed via IE/Firefox) roughly the same
> if I am running as a 'low privileged' user or as administrator?

No, I don't think so.  Damage and system recovery are vastly different.
If an "ordinary" user runs malicious unmanaged code, without
"admin" privileges, then files owned by others shouldn't be tamperable
(and may not be openable).  More importantly, cleanup is easy; you don't
need to reload the OS, because the OS should be undamaged.

That's assuming you CAN reload the OS; many Windows laptops
don't have a safe way to reload the OS, and the only reload possible
is from a hard drive that may be corrupted.  If you can't reload
from CDs/DVDs, then you should essentially NEVER run as admin.

Of course, this is unlikely.  Last stats I saw said that 70% of all
Windows apps REQUIRE admin, so Windows users typically run with
excess privileges.  Which is a key practical reason why Windows systems
tend to be so much less secure in practice than they
should be; users (for understandable reasons)
often run with so many unnecessary privileges that they easily get
into trouble.  Having "managed code" with excess privileges is
not a real help. I have hope that this overuse of admin
will diminish over time.


> 4) Finally, isn't the solution for the creation of secure and
> trustworthy Internet Browsing environments the development of browsers
> written in 100% managed and verifiable code, which execute on a secure
> and very restricted Partially Trusted Environments? (under .Net, Mono or
> Java). This way, the risk of buffer overflows will be very limited,

I think that would help, though less than you might think.
Many Linux systems are now highly resistant to buffer overflows
(Fedora Core has a number of countermeasures, and they're adding more).
There's a C/C++ compiler option under Windows that adds StackGuard-type
protection against buffer overflows; if programmers use that, the program
has some protection on Windows against buffer overflows.


> This last question/idea is based on something that I have been defending
> for quite a while now (couple years) which is: "Since it is impossible
> to create bug/vulnerability free code, our best solution to create
> securer and safer computing environments (compared to the ones we have
> today), is to execute those applications in sandboxed environments".

I think that's a good idea, and I have said so myself.
But the real payoff is writing code specifically designed to defend
itself against malicious attack.  If you choose safer environments
AS PART OF that thrust, you'll do well.  But you really need to
write software with a paranoid mindset, working hard to counter
security attacks. It's the mindset, not the language, that is key.


> Unfortunately, today there is NO BUSINESS case to do this. The paying
> customers are not demanding products that don't have the ability to
> 'own' their data center,

There is one and only one requirement for change: customers must
decide to use, and switch to, products with better security. That's all.
I don't think that liability suits will be helpful for general-purpose
software, for a variety of reasons (new thread, out of scope here).

Let me repeat:
All that needs to happen is that customers CHOOSE THEIR SUPPLIER
based on which one is more secure.  When customers
do that, the market will immediately supply customers with more
secure products.  Suppliers will immediately improve security, or
find themselves out of the market.  The market is actually quite
efficient this way.  If customers don't do that, then customers are
getting what they want... and what they deserve.

Yes, it's true that it's sometimes difficult to get good, independent
security advice.  But that has nothing to do with IE.
Really, did anyone SERIOUSLY think that IE
had good security in 2004? In 2005?  Just read a newspaper, folks.
A novice could ask anyone clueful about security and get an answer;
you didn't need a million-dollar evaluation to answer that one.
The people who used IE anyway got exactly what they should have
expected to receive for their behavior.  Attackers should be
punished, but users are responsible for their choices, too.

I think people ARE starting to change their behavior, by the way.
There's a host of evidence that Firefox is much more secure than IE
(e.g., http://bcheck.scanit.be/bcheck/page.php?name=STATS2004), and
Firefox's market share has been increasing. One of the main
reasons stated by Firefox users "it's more secure".  So much so that
Microsoft blew off the mothballs off IE, and actually came up
with IE 7.  MS's new security development process is an improvement,
I think, and the pieces of IE that were redeveloped through
it will probably be better for it.

Competition is a wonderful thing, and it CAN work
for security too.  Suppliers can create much more secure products.
I think there are a lot of smart people in MS who
really DO want more secure products, and are working hard to make
improvements.  (Good for them! Rah, rah!!)

But customers need to be willing to SWITCH
products based on the products' security.  If customers buy products
from MS, or anyone else, regardless of how poor their security is,
then MS or anyone else would be foolish to spend a dime on security.
Customers who are unwilling to change suppliers are not
just part of the problem... they ARE the problem.
If most customers used only the products with the best
security track records, there would be few security problems.

Which is why it is CRITICAL TO SECURITY that people use open
standards.  Make sure your website complies with W3C standards, test
with multiple browsers, etc.  Having open competition makes it possible
for people to choose the most secure products, and switch when
a supplier fails them, rather than whichever
product has the best lock-in today (both MS and Netscape have historically
played the hideous and security-subverting lock-in game).

Making sure that interface standards are used, enabling customers
to pick the most secure implementation, is far more important than
the browser implementation language for a particular browser.
If a browser is bad, then people can drop it like a dead skunk, and
thus the language the bad browser is written is quickly irrelevant.

> Finally, you might have noticed that whenever I talked about 'managed
> code', I mentioned 'managed and verifiable code', the reason for this
> distinction, is that I discovered recently that .Net code executed under
> Full Trust  can not be (or should not be) called 'managed code', since
> the .Net Framework will not verify that code (because it is executed
> under Full Trust). This means that I can write MSIL code which breaks
> type safety and execute it without errors in a Full Trust .Net environment.

In this sense, the .NET framework may be slightly worse off than some other
environments, which ALWAYS do runtime checks that CANNOT be disabled.
But I don't think that's the key point. The best defense is
rampant paranoia among the developers.  And the best way to encourage
such thinking is for customers to stop whining about security, and
switch to products that actually supply it.  When customers routinely say,
"No, I'll switch to another supplier with better security," we will have
better security.

--- David A. Wheeler




From dinis at ddplus.net  Tue Mar 28 16:58:56 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Tue, 28 Mar 2006 22:58:56 +0100
Subject: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, Uservs Admin risk profile, and browsers coded in
	100% Managed Verifiable code
In-Reply-To: <033601c65153$421e1140$1204a8c0@intranet.aspectsecurity.com>
References: <033601c65153$421e1140$1204a8c0@intranet.aspectsecurity.com>
Message-ID: <4429B1A0.5040800@ddplus.net>

Jeff, as you can see by Stephen de Vries's response on this thread, you
are wrong in your assumption that most Java code (since 1.2) must go
through the Verifier (this is what I was sure it was happening since I
remembered reading that most Java code executed in real-world
applications is not verified)

I think your answer shows clearly that the Java camp should also be
participating in these discussions.

In fact I also would like to ask "Where are the Java Guys/Girls?"

I have been talking for two years now on the dangers of .Net Full Trust
code, and have not seem much discussion on the dangers of 'Security
Manager disabled Java code' (since the problems are exactly the same).
Malicious Java code, executed with the Security Manager Disabled  in a
user's desktop or in a server, is as dangerous as Full Trust .Net code.

This comes back to that great concept called 'Faith-based' Security (see
Gunnar Peterson's post
http://1raindrop.typepad.com/1_raindrop/2005/11/net_and_java_fa.html ),
which is when people are told so many times that something is secure,
that that they believe that it MUST be secure. Some examples:

    - "Java is more secure than .Net" (meaningless discussion unless we
also talk about the Sandboxes the code is running under)

    - "IIS 6.0 is more secure that IIS 5.0" (today, is a fully patched
IIS 5 (with urlscan ISAPI filter) more 'secure' than a IIS 6.0? Most
people will automatically say yes, but if you do a Risk analysis to
both,  you will see that the risk is just about the same: both ARE able
to sustain malicious 'Internet based' anonymous attacks (since there are
no reported unpatched vulnerabilities and zero-days exploits), and both
are NOT ABLE to sustain malicious Full Trust Asp.Net code executed from
within one of its worker processes

    - "Open Source apps are more secure than Closed Source apps" (again,
not an automatic truism)

    - "Linux and Mac are more secure than Windows" (that depends on how
it is configured, deployed, maintained, and more importantly, how it is
used).

    - "If only we could get the developers to write 'secure code' there
would be no more vulnerabilities" (this is the best one, a good example
of 'Faith Based Security' with 'Blame the guy in the trenches that
doesn't complain (i.e. the developers)' (note that I don't think that
developers have SOLE (or even MAIN) responsibility in the process that
leads to the creation of insecure applications))
 
    -"I.E. is more insecure than Firefox" (apart from the unmanaged code
discussion we had earlier, I just say this: Firefox plug-ins. The best
way to Own millions of computers is to write a popular Firefox plug-in
(which to my understanding runs directly on Firefox's process space and
not contained in any type of Sandbox))

I hope the Java camp will also join this discussion on how to create
'real world' applications which can be executed in safe Sandboxes.

Ultimately my main frustration is that both .Net and Java have built
into their framework technological solutions which COULD deliver such
environments (CAS and Security Manager). The problem is that they were
designed to handle a very specific type of code (the so called 'Mobile
code') for a specific set of applications (browser based components and
mobile devices), not the complicated,massively interconnected, 
feature-rich apps that we have today.

What we need now is focus, energy and commitment to create a business
environment where it is possible (and profitable) the creation,
deployment and maintenance of applications executed in secure sandboxes.

Dinis Cruz
Owasp .Net Project
www.owasp.net

Jeff Williams wrote:
>> I am not a Java expert, but I think that the Java Verifier is NOT used on
>>     
> Apps that >are executed with the Security Manager disabled (which I believe
> is the default >setting) or are loaded from a local disk (see "... applets
> loaded via the file system >are not passed through the byte code verifier"
> in http://java.sun.com/sfaq/) 
>
> I believe that as of Java 1.2, all Java code except the core libraries must
> go through the verifier, unless it is specifically disabled (java
> -noverify).  Note that Mustang will have a new, faster, better? verifier and
> that Sun has made the new design and implementation available to the
> community with a challenge to find security flaws in this important piece of
> their security architecture. https://jdk.dev.java.net/CTV/challenge.html.
> Kudos to Sun for engaging with the community this way.
>
> --Jeff
>
>
>
> -------------------------------------------------------------------------
> This List Sponsored by: SpiDynamics
>
> ALERT: "How A Hacker Launches A Web Application Attack!" 
> Step-by-Step - SPI Dynamics White Paper
> Learn how to defend against Web Application Attacks with real-world 
> examples of recent hacking methods such as: SQL Injection, Cross Site 
> Scripting and Parameter Manipulation
>
> https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl
> --------------------------------------------------------------------------
>
>
> -----------------------------------------
> The information contained in this e-mail message is intended only
> for the personal and confidential use of the recipient(s) named
> above. This message may be an attorney-client communication and/or
> work product and as such is privileged and confidential. If the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
> hereby notified that you have received this document in error and
> that any review, dissemination, distribution, or copying of this
> message is strictly prohibited. If you have received this
> communication in error, please notify us immediately by e-mail, and
> delete the original message.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Owasp-dotnet mailing list
> Owasp-dotnet at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060328/96f3dff4/attachment.html 

From dinis at ddplus.net  Tue Mar 28 17:09:20 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Tue, 28 Mar 2006 23:09:20 +0100
Subject: [SC-L] Re: [Owasp-dotnet] Re: Is there any Security problem in Ajax
	technology?
In-Reply-To: <00ce01c647de$767cccc0$d204a8c0@intranet.aspectsecurity.com>
References: <00ce01c647de$767cccc0$d204a8c0@intranet.aspectsecurity.com>
Message-ID: <4429B410.4030507@ddplus.net>

As been said before in this thread, AJAX is just another 'architecture'
for creating systems that allow end users to use online services
(although due to the increased attack surface one more potentially
dangerous than an website interface).

But will AJAX dramatically increase or decrease the security
vulnerabilities that exist in applications? I am not sure.

More and more I am convinced that it is the 'development model' /
'development mindset' that has the greater impact in the security of the
newly created applications.

In an environment where:

    a) end clients (the ones paying for the development) don't care
about (or don't know how to demand) secure applications,
    b) solution architects have limited time/budget to design a solution
to 'ever-moving project objectives/deliverables'
    c) projects are so complex that nobody has a full technical
understanding of the entire system
    d) there is no (or there is a weak) formal security process (from
threat modeling, to secure by design/default/deployment designs, to code
audits)
    e) developers don't have a strong understanding of the security
implications of the programing techniques that they use
    f) developers  are given  unrealistic deadlines for the number of
features requested
    g) the financial benefit in writing secure code, is much smaller
than the financial benefits of writing feature rich applications which
have good performance
    h) security incidents will be 'covered up', not publicly disclosed
unless they really have to, and the responsible parties (which in my
view, in most of the cases are not the developers) are not made accountable
    g) the ever changing of technologies used (where nobody really
masters it, and even very experienced programmers are most of the time
'professional amateurs')
    i) the increased complexity and interconnectivity of our systems

...how do you expect secure applications to be developed?

Ultimately we must look at the assets and answer the question "are they
still being compromised?"  regardless if the attack vector are buffer
overflows, SQL injection, Authorization  failures, etc...

We also must note the 'depth' of the compromise. Are we a talking about
a compromise of an Web Application, the server or the data center?

With the current speed of the industry, unless the 'model' behind the
Software Development Lifecycle promotes security, then there will always
be multiple ways to create security vulnerabilities.

Unfortunately it does not end with a good Secure Software Development
Lifecycle (SSDL). For example Microsoft currently has a better SSDL than
Oracle, but is still creating insecure applications, frameworks and
operating systems that (for example) are not able to handle malicious
code executed from within (namely Full Trust .Net code and Vista's
UAC/LUA). Microsoft understands yesterday's security problems (buffer
overflows, Sql injections, xss, crypto attacks,etc...) but doesn't
understand (or wants to understand) tomorrow's security  problems
(securely execution of malicious code, authorization vulnerabilities,
race-conditions, malicious developers, CLR attacks, etc...).

So here we end up with the good-old Business case. When there is no
short-term business case and strong client/government demand for a
secure solution/product/operating system, the companies delivering
applications will not do it voluntarily  (even when they have a good
understanding of security and have developers who understand secure
coding practices)

So coming back to AJAX.... I would say: Show me your development model,
mindset, motivation and past exploitation record; add in the
technologies used, and I will show you where security vulnerabilities
are very likely to exist.

Dinis Cruz
Owasp .Net Project
www.owasp.net




Jeff Williams wrote:
> Hi Eric,
>
> I think you've nailed what's really going on here.  There's this huge
> timelag between when new technologies are introduced and when we (as a
> software development community) are really using them securely.
>
> As several folks have pointed out, there's nothing fundamentally new about
> the security issues created by AJAX. As a *security* community, our
> challenge is to translate the principles and practices that we understand to
> the new technologies that come along.  Our track record isn't particularly
> good here by the way. We never translated the extensive access control work
> from the 80's to the web environment. We're starting to translate what we've
> learned about web apps to web services.  But, realistically, it's going to
> be a while before we are effectively securing AJAX apps.
>
> OWASP, as an all volunteer open-source project, has a role to play here.
> When new technologies arise, we approach them from a bunch of different
> angles.  Generally, the presentations at local chapters and email threads
> like this happen first.  The Guide captures the issues more completely and
> fully. WebScarab adds support for the technology, and WebGoat lessons get
> built to help developers really learn. And maybe we even build some
> technology to help developers protect their applications.
>
> Look at the support we have for web services developers for an example.
> We've got several great presentations (and video podcasts), fantastic
> content in the Guide, excellent testing tools in WebScarab, and cool lessons
> in WebGoat.  We've started doing similar stuff for AJAX as some others have
> mentioned.
>
> It's a huge challenge -- and we need all the help we can get.  Please let me
> know if you have ideas about how we can be more effective.
>
> --Jeff
>  
> Jeff Williams, Chair
> The OWASP Foundation
> http://www.owasp.org
> email: jeff.williams at owasp.org
>
>
>   
>> -----Original Message-----
>> From: owasp-dotnet-admin at lists.sourceforge.net [mailto:owasp-dotnet-
>> admin at lists.sourceforge.net] On Behalf Of Eric Swanson
>> Sent: Tuesday, March 14, 2006 8:34 PM
>> To: owasp-dotnet at lists.sourceforge.net; SC-L at securecoding.org
>> Subject: RE: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in
>>     
> Ajax
>   
>> technology?
>>
>> My question: How does OWASP plan to educate the public regarding security
>> concerns raised by AJAX and, indeed, any new methodology or technology and
>> what is its plan to develop tools that translate this education into
>> practice?  *AJAX and related methodologies should be addressed by all
>>     
> groups
>   
>> within OWASP, so I'm guessing that the .NET group isn't the only group
>> actively discussing it.  (AFLAX - a Flash version also raises the same
>> concerns.)
>>
>> The security concerns with the AJAX method are the same as they have
>>     
> always
>   
>> been and the standard checklists still apply.  I think the real concern is
>> that the popularity of AJAX will continue to enable ignorant programmers
>>     
> to
>   
>> develop insecure solutions and possibly more importantly solutions that
>> violate personal privacy (i.e. the AJAX concept allows a website to
>>     
> collect
>   
>> information as you type it, regardless of whether you explicitly submit
>>     
> the
>   
>> information -- this was possible using hidden frames in the past, but it
>> will become a more evident problem as popularity increases; I raised this
>> issue last year regarding auto-form completion programs).
>>
>> AJAX is just another method of making a request to the server and (yet
>> another redundant point) all requests need to be authorized and validated.
>> The same applies to EVERY request to the server.
>>
>> *The barrier for rapid, rich-client development is getting lower as
>> high-level programming progresses and implementation choices are
>> ever-growing.  It's up to groups like this to make security concerns
>>     
> evident
>   
>> to all parties, standardize security practices, provide the resources and
>> tools to educate and verify conformity to standards, etc.
>>
>> --Eric Swanson
>>
>> -----Original Message-----
>> From: owasp-dotnet-admin at lists.sourceforge.net
>> [mailto:owasp-dotnet-admin at lists.sourceforge.net] On Behalf Of Yvan Boily
>> Sent: Tuesday, March 14, 2006 9:35 AM
>> To: George Capehart
>> Cc: Dinis Cruz; SC-L at securecoding.org; owasp-dotnet at lists.sourceforge.net
>> Subject: Re: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in
>>     
> Ajax
>   
>> technology?
>>
>> Hi George,
>>
>> I think a much more eloquent form of what you are saying is that
>> validation must be performed each time data crosses a security
>> boundary.
>>
>> The challenge is in helping people to understand what a security boundary
>> is.
>>
>> Regards,
>> Yvan Boily
>>
>> On 3/13/06, George Capehart <gwc at acm.org> wrote:
>>     
>>> Dinis Cruz wrote:
>>>       
>>>> I personally think that AJAX has the potential to create very insecure
>>>>         
>> applications because it pushes the data validation and authorization
>>     
> layers
>   
>> back to the client (i.e. the browser)
>>     
>>>> "AJAX brings 'Back the Rich Client' and all its security problems"
>>>>
>>>> Kentaro, on your AJAX application you must follow the rule-of-thumb of
>>>>         
>> not trusting any data supplied by your own Client-Side-AJAX functions, and
>> authorize every request.
>>     
>>>> In a nutshell: any data validation and authorization decisions/actions
>>>>         
>> made at the Client-Side-AJAX functions are only there for usability, and
>> have NO security value.
>>     
>>> I enthusiastically agree with the above.  I'll take it further and
>>>       
> suggest
>   
>>> that, even then, the input from the Web should/must be examined and
>>>       
>> sanitized
>>     
>>> before use . . .  /*still*/ need to check for SQL injection attacks,
>>>       
> etc.
>   
>>> IMNSHO, identification, authorization and validation should always be
>>>       
> done
>   
>> by
>>     
>>> the part of the system that is at risk if the input is bad (in any of
>>>       
> the
>   
>>> connotations of bad) . . .
>>>
>>> Cheers,
>>>
>>> /g
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>>       
>> language
>>     
>>> that extends applications into web and mobile media. Attend the live
>>>       
>> webcast
>>     
>>> and join the prime developer group breaking into this new coding
>>>       
>> territory!
>>     
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
>>> _______________________________________________
>>> Owasp-dotnet mailing list
>>> Owasp-dotnet at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
>>>
>>>       
>> --
>> ____
>> ygjb
>> Computer Science is no more about computers than astronomy is about
>> telescopes. E. W. Dijkstra
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>     
> language
>   
>> that extends applications into web and mobile media. Attend the live
>>     
> webcast
>   
>> and join the prime developer group breaking into this new coding
>>     
> territory!
>   
>> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
>> _______________________________________________
>> Owasp-dotnet mailing list
>> Owasp-dotnet at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>     
> language
>   
>> that extends applications into web and mobile media. Attend the live
>>     
> webcast
>   
>> and join the prime developer group breaking into this new coding
>>     
> territory!
>   
>> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
>> _______________________________________________
>> Owasp-dotnet mailing list
>> Owasp-dotnet at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
>>     
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> Owasp-dotnet mailing list
> Owasp-dotnet at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060328/5a500233/attachment.html 

From dinis at ddplus.net  Tue Mar 28 17:52:11 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Tue, 28 Mar 2006 23:52:11 +0100
Subject: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest
	IE vulnerability, Firefox vs IE security, Uservs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <A7F74BDC-4FBE-4971-AEAE-3E23F16A4507@corsaire.com>
References: <033601c65153$421e1140$1204a8c0@intranet.aspectsecurity.com>
	<A7F74BDC-4FBE-4971-AEAE-3E23F16A4507@corsaire.com>
Message-ID: <4429BE1B.6030406@ddplus.net>

Hello Stephen ,


Stephen de Vries wrote:
> I had the same intuition about the verifier, but have just tested this
> and it is not the case.  It seems that the -noverify is the default
> setting! 

Thanks for confirming this (I wonder how many other other Java
developers are aware of this (especially the ones not focused on
security)).

Stephen, do you have any idea of what is the current percentage of 'real
world' Java applications are executed:

    a) with verification

    b) on a secure sandbox

Note that for example I have seen several Java Based Financial
Applications which are executed on the client which either require local
installation (via setup.exe / App.msi) or require that the user grants
that Java application more permissions that the ones allocated to a
normal Sandboxed browser based Java App.

> If you want to verify classes loaded from the local filesystem, then
> you need to explicitly add -verify to the cmd line.  I tested this by
> compiling 2 classes where one accesses a public member of the other. 
> Then recompiled the other and changed the method access to private. 
> Tested on:
> Jdk 1.4.2 Mac OS X
> Jdk 1.5.0 Mac OS X
> Jdk 1.5.0 Win XP
>
> all behave the same.
>
> [~/data/dev/applettest/src]java -cp . FullApp
> Noone can access me!!
> [~/data/dev/applettest/src]java -cp . -verify FullApp
> Exception in thread "main" java.lang.IllegalAccessError: tried to
> access field MyData.secret from class FullApp at
> FullApp.main(FullApp.java:23)
>
Humm, this is indeed interesting. Ironically, the 1.1 and 2.0 versions
of the CLR will thrown an exception in this case (even in Full Trust).
Since verification is not performed on that .Net Assembly, the CLR might
pick up this information when it is resolving the method's relative
address into the real physical addresses (i.e. during JIT).
> Using the same code with an Applet loaded from the filesystem throws
> an IllegalAccessError exception as it should.
>
What do you mean by 'Applet loaded from the filesystem'?

Where? In a Browser?

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net




From dinis at ddplus.net  Tue Mar 28 18:43:09 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Wed, 29 Mar 2006 00:43:09 +0100
Subject: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest
	IE vulnerability, Firefox vs IE security, Uservs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <000901c651e3$ae8b2b20$6401a8c0@agi.alexandergroupinc.com>
References: <000901c651e3$ae8b2b20$6401a8c0@agi.alexandergroupinc.com>
Message-ID: <4429CA0D.40908@ddplus.net>

Hello Eric (comments inline)

Eric Swanson wrote:
> Because I believe that Microsoft will never be as cooperative with .NET and
> the developer community as Sun is with Java, is there an opportunity for
> another company to step up to the plate on Microsoft's behalf? 
There is definitely an opportunity here. At the moment I see two big
players that could move into that space: Novell and IBM.

Both have the resources to do it, and the motivation. The main questions
are:

    - Do they want to buy that 'war' with Microsoft?
    - Do they 'believe' that this a worthwhile project and one that will
help their bottom line?
    - Can they do it in an open and transparent way that attracts a
strong community to it? (note that this community will be critical to
the project, since I believe that no company in the world has the
resources to it by itself)

This could also be done by a very dynamic and well funded Open Source
project (maybe by several governments or by companies/corporations which
decide that they need to be more proactive in the protection of their
critical resources and assets)
>  The .NET
> Framework is completely public, and, although Mono continues to have its
> workload increased by each Framework release, I think there may be an
> opportunity for a company or organization to step-in and take the reigns
> where Microsoft left off.  How possible is it to "plug-in" to the CLR and
> make extensions to the core?
>   
It is very doable. Note that there are already 4 different flavors of
the CLR (Microsoft's .Net Framework, Rotor, Mono and DotGnu)

See also the Postbuild commercial application
(http://www.xenocode.com/Products/Postbuild/) which claims (I have not
used it) to create Native x86 executables which  allows .NET
applications to run anywhere, with or without the Framework.

This is something that I always wanted to do since it should (depending
how it is done) allow the dramatic reduction of code (and dlls) that
needs to be loaded in memory (the ultimate objective would be to create
mini-VMs that were completely isolated from the host OS (or only having
very specific interfaces / contact points)).

Also while I was doing my 'Rooting the CLR' research, since Microsoft
does provide the Symbols for core .Net Assemblies, there is a lot that
can be done at that level. That said, this work would be greatly
simplified if Microsoft released the source code of the entire .Net
Framework :)

> Perhaps a better project for OWASP.NET than security vulnerability detection
> utilities is a security plug-in to the CLR engine for byte code signature
> registration and verification?  
Agree, the problem we have is resources (and lack of funding)

Btw, at Owasp .Net we have now much more than just 'Security
Vulnerability Detection Utilities' :)

Apart from those utilities (namely ANSA and ANBS) we now also have:

    * Owasp Site Generator : Dynamic website creator to test Web
Application Scanners and Web Application Firewalls (and a great tool for
developers to learn about security vulnerabilities)
    * Owasp PenTest Reporter : Tool that aids in the process of
documenting,  reporting and tracking security vulnerabilities discovered
during Penetration Testing engagements
    * DefApp (Proof of Concept): Web Application Firewall
 
Another project that I would love to do is to work on a plug-in manager
for Firefox which would execute all Firefox plug-ins in a managed and
verifiable .Net sandbox (maybe built around mono (which was were this
idea was suggested to me))
> Would this task even be feasible?  (Managed
> code only?)  Is it even worth the effort, considering the possibility of
> further development from Microsoft?
>   
I think that it would be worth the effort, the problem is 'who will fund
this'.

I don't think that this is a project that can be done on the backs of
the odd spare times that its main developers would be able to allocate
to it.
> *Personally, I have never attempted to work below the top layers of .NET.
>   
It's not that hard :)
> But, it seems to me that plugging into the core would be a better option
> than some kind of wrapper sandbox, especially with regard to change control
> (top layers are likely to change more often and more drastically than lower
> layers).
>   
Absolutely, and remember that ideally this tool would also remove 95% of
that 'top layer' since it is not required.

I am also not convinced of the robustness of the current implementation
of CAS in .Net 1.1 and 2.0. There are too many security demands in too
many places.
> Should it be a task of the OWASP.Java team to work with Sun "Mustang"?
>   
Maybe, but first you need to create that Owasp.Java team :)

There are a lot of Java guys at Owasp, but they all are working on
separate projects
> Could there ever be a silver bullet sandbox for all executables, regardless
> of language? 
No I don't think so.

You will need to look at each different type of executables (mobile
code, web apps, desktop apps, windows services, 'real-time apps', etc..)
and create solutions for each one (there might be tons of code reuse,
but the focus will be different).

This means that you will need different versions of the Garbage
Collector, different versions of the security manager, and probably even
different versions of the Verifier.

And the best justification for having these different versions of core
components of the CLR is given by Microsoft's failed attempt with Vista
to implement large parts of the OS on top of the .Net Framework. I don't
know the details of this failure (since I was not there) but my belief
is that the fundamental problem was that they were using the .Net CLR in
ways it was never designed to (for example in time-sensitive apps or
heavy graphics / memory manipulation).

The problem was not that Microsoft tried to build Vista on top of
managed code, the problem was that they did it on top of the .Net Framework.
>  Wouldn't this turn into just another evolution of anti-virus
> programs?
>   
Well, anti-virus will probably, eventually, create such sandboxed
environments, but at the moment I don't see a lot of movement from that
side.
> "Even if you just barely scratch the surface, you've made a visible change
> that everyone can see and, who knows, may even cause them to want to make a
> scratch of their own."
>   
Perfect quote, and I have to say that all that I am trying to do here is
to raise the awareness of these issues in the hope that somebody,
somewhere will take them seriously and start the process of creating
secure and trustworthy computing environments.
> Thinking out loud,
>   
So am I :)
> --Eric Swanson
>   
>   
Dinis Cruz
Owasp .Net Project
www.owasp.net





From dinis at ddplus.net  Tue Mar 28 19:17:04 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Wed, 29 Mar 2006 01:17:04 +0100
Subject: FW: [SC-L]  4 Questions: Latest IE vulnerability,	Firefox vs
	IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <001e01c651a1$749600d0$4fa7d280@OS00009>
References: <001e01c651a1$749600d0$4fa7d280@OS00009>
Message-ID: <4429D200.6070908@ddplus.net>

If you are able to make direct calls to unmanaged code, then yes you can
jump out of the sandbox (assuming that you are in one in the first place)

The environment that I am talking about is one where you have managed
and verifiable code which is not allowed to perform dangerous actions
(such as making direct calls to unmanaged code)

Of course that you would still be affected if there was a hole in
Microsoft's .Net Sandboxes or in the used Microsoft COM components (for
example the .Net Framework was vulnerable to the WMF exploit).

Coming back to your question, Verifiable .Net code is not allowed to
perform (amongst other things) direct pointer or stack manipulation, all
type conversions much be valid, and you cannot control the execution
flow the way you can in C++. So basically, Verifiable .Net code is not
able to jump out of the sandbox.

Dinis Cruz
Owasp .Net Project
www.owasp.net

Michael S Hines wrote:
> Isn't it possible to break out of the sandbox even with managed code? (That is, can't
> managed code call out to unmanaged code, i.e. Java call to C++)?  I was thinking this was
> documented for Java - perhaps for various flavors of .Net too?  
>
> -----------------------------------
> Michael S Hines
> mshines at purdue.edu 
>   




From dinis at ddplus.net  Tue Mar 28 20:29:06 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Wed, 29 Mar 2006 02:29:06 +0100
Subject: [SC-L] Owasp SiteGenerator v0.70 (public beta release)
Message-ID: <4429E2E2.7090407@ddplus.net>

After much development and hard work here is the first stable (beta)
release of the new Owasp SiteGenerator tool (whose Open Source
development has been sponsored by Foundstone)

Owasp SiteGenerator allows the creating of dynamic websites based on XML
files and predefined vulnerabilities (some simple to detect/exploit,
some harder) covering multiple .Net languages and web development
architectures (for example, navigation: Html, Javascript, Flash, Java,
etc...).

SiteGenerator can be used on the following projects:

    - Evaluation of Web Application Security Scanners
    - Evaluation of Web Application Firewalls
    - Developer Training
    - Web Honeypots
    - Web Application hacking contests (or evaluations)

You can read an introduction to this tool here
(http://sourceforge.net/mailarchive/message.php?msg_id=14547158), and
download the latest version from here:

    * Website installer:
      http://www.ddplus.net/projects/FoundStone/21-March-2006/SiteGenerator_IIS_Website_Setup
      v0.70.msi
    * Gui Installer:
      http://www.ddplus.net/projects/FoundStone/21-March-2006/Owasp
      SiteGenerator v0.70.msi

Some installation and configuration notes (which you only need to do once):

    * Before you install the website do this (assuming a windows 2003 image)
          o Create a new Application pool, call it
            SiteGeneratorSystemAppPool), and configure it to run under
            System
          o Create a new website and point it to a local directory (the
            website installation files will be copied here)
          o Configure the new website to run Asp.Net 2.0
          o Create a new Application in that website and set the
            application pool to SiteGeneratorSystemAppPool
          o Add a IIS wildcard Application Mapping (accessible via Home
            Directory -> Configuration) to 
            C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
            and untick the 'Verify that file exists'
          o Make sure Default.htm is one of the files included in the
            default document list (in the 'Documents' tab)
          o Configure the Website's IP Address to be 127.0.0.1, and
            click on the Advanced button to add a new host header mapping
                + IPAddress: 127.0.0.1
                + TCP Port: 80
                + Host Header Value: SiteGenerator
    * Install the WebSite (selecting as the target the website created
      in the previous step)
    * Install the GUI
    * Add this line to your hosts file (located in
      C:\window\system32\drivers\etc\hosts)
          o SiteGenerator        127.0.0.1
    * Click on the SiteGenerator link that was placed on your desktop

If all goes well you now can browse to http://SiteGenerator or
http://127.0.0.1 (depending if you did the mappings or not) and see the
default SiteGenerator's website. If you see a blank page, try
http://127.0.0.1/Default.htm (you might be getting a cached version of
http://127.0.0.1)

Note that the SQL Injection vulnerabilities expect that you have the
latest version of HacmeBank (v2.0) installed in your box.

I am in the process of creating several videos (covering the
installation and GUI) which I am sure will be very useful and practical.
Also if you are interested in helping in the development of
SiteGenerator or in its vulnerabilities database, then contact me directly.

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net
   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060329/52884829/attachment.html 

From michaelslists at gmail.com  Tue Mar 28 20:32:16 2006
From: michaelslists at gmail.com (michaelslists at gmail.com)
Date: Wed, 29 Mar 2006 12:32:16 +1100
Subject: FW: [SC-L] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <001e01c651a1$749600d0$4fa7d280@OS00009>
References: <001e01c651a1$749600d0$4fa7d280@OS00009>
Message-ID: <5e01c29a0603281732n51b5d839i615104f989b99f50@mail.gmail.com>

On 3/28/06, Michael S Hines <mshines at purdue.edu> wrote:
> Isn't it possible to break out of the sandbox even with managed code? (That is, can't
> managed code call out to unmanaged code, i.e. Java call to C++)?  I was thinking this was
> documented for Java - perhaps for various flavors of .Net too?

Java _can_ call c++ but the the way to do it can be restricted by the
security manager. i.e. you can't call "System.loadLibrary" without
permission.

you "may" be able to call native functions of already loaded dll's
though by registering their headers like:

public native foo( ... );

not sure how far you'll get with that though.

-- Michael



From michaelslists at gmail.com  Tue Mar 28 20:49:27 2006
From: michaelslists at gmail.com (michaelslists at gmail.com)
Date: Wed, 29 Mar 2006 12:49:27 +1100
Subject: [SC-L] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <20060328235413.23659.qmail@paddy.troja.mff.cuni.cz>
References: <242a0a8f0603271418k84a9661uc964be661cd7360@mail.gmail.com>
	<20060328235413.23659.qmail@paddy.troja.mff.cuni.cz>
Message-ID: <5e01c29a0603281749y47b5396w382cd718a1a832ab@mail.gmail.com>

no, a browser written in java would not have buffer overflow/stack
issues. the jvm is specifically designed to prevent it ...

-- Michael

On 3/29/06, Pavel Kankovsky <peak at argo.troja.mff.cuni.cz> wrote:
> On Mon, 27 Mar 2006, Brian Eaton wrote:
>
> > If I run a pure-java browser, for example, no web site's HTML code is
> > going to cause a buffer overflow in the parser.
>
> Even a "pure-java browser" would rest on the top of a huge pile of native
> code (OS, JRE, native libraries). A seemingly innocent piece of data
> passed to that native code might trigger a bug (perhaps even a buffer
> overflow) in it...
>
> Unlikely (read: less likely than a direct attack vector) but still
> possible.
>
> --Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
> "Resistance is futile. Open your source code and prepare for assimilation."
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



From michaelslists at gmail.com  Tue Mar 28 21:15:32 2006
From: michaelslists at gmail.com (michaelslists at gmail.com)
Date: Tue, 28 Mar 2006 21:15:32 -0500
Subject: [SC-L] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <20060328235413.23659.qmail@paddy.troja.mff.cuni.cz>
References: <242a0a8f0603271418k84a9661uc964be661cd7360@mail.gmail.com><20060328235413.23659.qmail@paddy.troja.mff.cuni.cz>
Message-ID: <000001c652d6$a85af4d0$0201a8c0@Jaluno.local>

no, a browser written in java would not have buffer overflow/stack
issues. the jvm is specifically designed to prevent it ...

-- Michael

On 3/29/06, Pavel Kankovsky <peak at argo.troja.mff.cuni.cz> wrote:
> On Mon, 27 Mar 2006, Brian Eaton wrote:
>
> > If I run a pure-java browser, for example, no web site's HTML code is
> > going to cause a buffer overflow in the parser.
>
> Even a "pure-java browser" would rest on the top of a huge pile of native
> code (OS, JRE, native libraries). A seemingly innocent piece of data
> passed to that native code might trigger a bug (perhaps even a buffer
> overflow) in it...
>
> Unlikely (read: less likely than a direct attack vector) but still
> possible.
>
> --Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
> "Resistance is futile. Open your source code and prepare for assimilation."
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/




From vanderaj at greebo.net  Tue Mar 28 21:17:12 2006
From: vanderaj at greebo.net (Andrew van der Stock)
Date: Wed, 29 Mar 2006 13:17:12 +1100
Subject: [SC-L] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <5e01c29a0603281749y47b5396w382cd718a1a832ab@mail.gmail.com>
References: <242a0a8f0603271418k84a9661uc964be661cd7360@mail.gmail.com>
	<20060328235413.23659.qmail@paddy.troja.mff.cuni.cz>
	<5e01c29a0603281749y47b5396w382cd718a1a832ab@mail.gmail.com>
Message-ID: <E65BA254-3C66-4C27-BE78-6573EE4E889B@greebo.net>

This is not quite true.

Java does not prevent integer overflows (it will not throw an  
exception). So you still have to be careful about array indexes.

Andrew

On 29/03/2006, at 12:49 PM, michaelslists at gmail.com wrote:

> no, a browser written in java would not have buffer overflow/stack
> issues. the jvm is specifically designed to prevent it ...
>
> -- Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2234 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060329/ea07464c/attachment.bin 

From jeff.williams at aspectsecurity.com  Tue Mar 28 22:52:36 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Tue, 28 Mar 2006 22:52:36 -0500
Subject: [SC-L] Re: 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, Uservs Admin risk profile,
	and browsers coded in100% Managed Verifiable code
In-Reply-To: <000201c652bf$9edb9660$0201a8c0@Jaluno.local>
Message-ID: <071e01c652e4$382b22d0$8a04a8c0@intranet.aspectsecurity.com>

> Jeff, as you can see by Stephen de Vries's response on this thread,
> you are wrong in your assumption that most Java code (since 1.2)
> must go through the Verifier (this is what I was sure it was
> happening since I remembered reading that most Java code executed
> in real-world applications is not verified)

Wow.  I ran some tests too, and Stephen is absolutely right.  It appears
that Sun quietly turned off verification by default for bytecode loaded from
the local disk (not applets).  They've apparently
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4030988), acknowledged
that it is a bug, and said that it will not be fixed.  The change had
something to do with compatibility with old bytecode.  More details
(http://www.cafeaulait.org/reports/accessviolations.html) 

This is a clear violation of the JVM Spec. And (regardless of protestation
to the contrary) it IS a big security problem.  Just because bytecode is
loaded from the local disk does not mean it's trustworthy.  Every
application uses lots of libraries that developers download from the
Internet (as compiled jar files) and loaded from the local disk.  Unless you
run with "java -verify" that code won't get verified.

I'm sure that the percentage of applications that are running with both
verification and sandbox is terrifyingly small.  Probably only applets and
maybe Java Web Start applications.  As I mentioned before some of the J2EE
servers are now enabling a sandbox, but their security policies are
generally wide open.

I think there are two relatively easy things we can do here. First, let's
find out what plans Sun has for the new verifier -- we should strongly
encourage them to turn it on by default.  Second, we can work on ways to
encourage people to use sandboxes -- tools, articles, and awareness.

--Jeff





From michaelslists at gmail.com  Tue Mar 28 22:30:43 2006
From: michaelslists at gmail.com (michaelslists at gmail.com)
Date: Wed, 29 Mar 2006 14:30:43 +1100
Subject: [SC-L] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <E65BA254-3C66-4C27-BE78-6573EE4E889B@greebo.net>
References: <242a0a8f0603271418k84a9661uc964be661cd7360@mail.gmail.com>
	<20060328235413.23659.qmail@paddy.troja.mff.cuni.cz>
	<5e01c29a0603281749y47b5396w382cd718a1a832ab@mail.gmail.com>
	<E65BA254-3C66-4C27-BE78-6573EE4E889B@greebo.net>
Message-ID: <5e01c29a0603281930g427b3bb2vada6afd70f8c1eb@mail.gmail.com>

No you dont.

Arrays are all bounds checked; ..., that is, the following code will
throw an exception:

================================
class Foo {
  static {
    int[] m = new int[2];
    System.out.println(m[34]);
  }
}
================================


What do you mean by "overflow"? Do you mean this?

================================
class Foo {
  static {
    int m = Integer.MAX_VALUE;
    int k = Integer.MAX_VALUE + Integer.MAX_VALUE;
    System.out.println(m);
    System.out.println(k);
    System.exit(0);
  }
}
================================

if so, I don't see how that is an issue.

-- Michael



On 3/29/06, Andrew van der Stock <vanderaj at greebo.net> wrote:
> This is not quite true.
>
> Java does not prevent integer overflows (it will not throw an
> exception). So you still have to be careful about array indexes.
>
> Andrew
>
> On 29/03/2006, at 12:49 PM, michaelslists at gmail.com wrote:
>
> > no, a browser written in java would not have buffer overflow/stack
> > issues. the jvm is specifically designed to prevent it ...
> >
> > -- Michael
>
>
>



From michaelslists at gmail.com  Tue Mar 28 22:50:10 2006
From: michaelslists at gmail.com (michaelslists at gmail.com)
Date: Wed, 29 Mar 2006 14:50:10 +1100
Subject: [SC-L] Re: Java integer overflows (was: a really long topic)
In-Reply-To: <EE0D6313-A1AF-4C85-9BE8-2B97DDBB76B8@greebo.net>
References: <242a0a8f0603271418k84a9661uc964be661cd7360@mail.gmail.com>
	<20060328235413.23659.qmail@paddy.troja.mff.cuni.cz>
	<5e01c29a0603281749y47b5396w382cd718a1a832ab@mail.gmail.com>
	<E65BA254-3C66-4C27-BE78-6573EE4E889B@greebo.net>
	<5e01c29a0603281930g427b3bb2vada6afd70f8c1eb@mail.gmail.com>
	<EE0D6313-A1AF-4C85-9BE8-2B97DDBB76B8@greebo.net>
Message-ID: <5e01c29a0603281950m3b6f1617uc788c454af48b0af@mail.gmail.com>

right,

but we're talking about unmanaged vs managed, and the earlier poster
(i think it might've been "pavel" [sorry if it wasn't]), said that
100% java is still vulnerable to buffer overflows. the fact is that it
isn't.

-- Michael

On 3/29/06, Andrew van der Stock <vanderaj at greebo.net> wrote:
> I'm not talking arbitrary code execution, I'm talking about odd code
> paths, bizarre outcomes, and DoS.
>
> For example (found via 19 Sins, Viega, Howard and LeBlanc):
> http://seclists.org/lists/bugtraq/2004/Nov/0097.html
>
> I know Michael reads webappsec, he may have more examples.
>
> In my own code testing, I look for silly behaviors if a user can
> insert a large or negative number. You'd be surprised how often it
> occurs. There is no excuse not to include basic range checks when
> performing data validation.
>
> thanks,
> Andrew
>
> On 29/03/2006, at 2:30 PM, michaelslists at gmail.com wrote:
>
> > No you dont.
> >
> > Arrays are all bounds checked; ..., that is, the following code will
> > throw an exception:
> >
> > ================================
> > class Foo {
> >   static {
> >     int[] m = new int[2];
> >     System.out.println(m[34]);
> >   }
> > }
> > ================================
> >
> >
> > What do you mean by "overflow"? Do you mean this?
> >
> > ================================
> > class Foo {
> >   static {
> >     int m = Integer.MAX_VALUE;
> >     int k = Integer.MAX_VALUE + Integer.MAX_VALUE;
> >     System.out.println(m);
> >     System.out.println(k);
> >     System.exit(0);
> >   }
> > }
> > ================================
> >
> > if so, I don't see how that is an issue.
> >
> > -- Michael
> >
> >
> >
> > On 3/29/06, Andrew van der Stock <vanderaj at greebo.net> wrote:
> >> This is not quite true.
> >>
> >> Java does not prevent integer overflows (it will not throw an
> >> exception). So you still have to be careful about array indexes.
> >>
> >> Andrew



From michaelslists at gmail.com  Tue Mar 28 22:57:00 2006
From: michaelslists at gmail.com (michaelslists at gmail.com)
Date: Wed, 29 Mar 2006 14:57:00 +1100
Subject: [SC-L] Re: [Full-disclosure] Re: Java integer overflows (was: a
	really long topic)
In-Reply-To: <3da3d8310603281953q12efdf4cs52b2e5af019af1bd@mail.gmail.com>
References: <242a0a8f0603271418k84a9661uc964be661cd7360@mail.gmail.com>
	<20060328235413.23659.qmail@paddy.troja.mff.cuni.cz>
	<5e01c29a0603281749y47b5396w382cd718a1a832ab@mail.gmail.com>
	<E65BA254-3C66-4C27-BE78-6573EE4E889B@greebo.net>
	<5e01c29a0603281930g427b3bb2vada6afd70f8c1eb@mail.gmail.com>
	<EE0D6313-A1AF-4C85-9BE8-2B97DDBB76B8@greebo.net>
	<5e01c29a0603281950m3b6f1617uc788c454af48b0af@mail.gmail.com>
	<3da3d8310603281953q12efdf4cs52b2e5af019af1bd@mail.gmail.com>
Message-ID: <5e01c29a0603281957i4428e0a7t4a0d8c1fc34c38a1@mail.gmail.com>

Obviously there is other issues around not sanitising the data
yourself, but in the context of the reply - i.e. buffer overflows for
arbitrary code exec - java is fully protected.

any access to an array is checked by the vm.

-- Michael


On 3/29/06, Eliah Kagan <degeneracypressure at gmail.com> wrote:
> > On 3/29/06, Andrew van der Stock wrote:
> > > This is not quite true.
> > >
> > > Java does not prevent integer overflows (it will not throw an
> > > exception). So you still have to be careful about array indexes.
>
> On 3/28/06, michaelslists at gmail.com replied:
> > No you dont.
> >
> > Arrays are all bounds checked; ..., that is, the following code will
> > throw an exception:
> >
> > ================================
> > class Foo {
> >   static {
> >     int[] m = new int[2];
> >     System.out.println(m[34]);
> >   }
> > }
> > ================================
> >
> >
> > What do you mean by "overflow"? Do you mean this?
> >
> > ================================
> > class Foo {
> >   static {
> >     int m = Integer.MAX_VALUE;
> >     int k = Integer.MAX_VALUE + Integer.MAX_VALUE;
> >     System.out.println(m);
> >     System.out.println(k);
> >     System.exit(0);
> >   }
> > }
> > ================================
> >
> > if so, I don't see how that is an issue.
> >
> > -- Michael
>
> That is an issue in a limited way--if you are trying to access a
> record with a high enough number (say by adding a number to a previous
> array index), you might end up accessing a record with a low number,
> which could potentially compromise the security of an application if
> certain assumptions are made. But this would only be within the same
> array that is already being accessed. The risk is minimal compared to
> the risks of accessing past the end of an array in, say, C.
>
> Even with bounds checking, there is no general way for a programming
> language to stop the programmer from writing a program that accesses
> the wrong piece of data in within a data structure, causing a security
> problem. Java was never designed to solve this sort of problem. Java
> does abstract data access so that many common bugs like buffer
> overflows are prevented, which is very useful.
>
> -Eliah
>



From michaelslists at gmail.com  Tue Mar 28 23:04:28 2006
From: michaelslists at gmail.com (michaelslists at gmail.com)
Date: Wed, 29 Mar 2006 15:04:28 +1100
Subject: [SC-L] Re: [Owasp-dotnet] Re: 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, Uservs Admin risk profile,
	and browsers coded in100% Managed Verifiable code
In-Reply-To: <071e01c652e4$382b22d0$8a04a8c0@intranet.aspectsecurity.com>
References: <000201c652bf$9edb9660$0201a8c0@Jaluno.local>
	<071e01c652e4$382b22d0$8a04a8c0@intranet.aspectsecurity.com>
Message-ID: <5e01c29a0603282004t6d174e86s54736c63a666518b@mail.gmail.com>

I wonder if you could disable the default security manager with unverified code.

Probably.

Hmm.

-- Michael


On 3/29/06, Jeff Williams <jeff.williams at aspectsecurity.com> wrote:
> > Jeff, as you can see by Stephen de Vries's response on this thread,
> > you are wrong in your assumption that most Java code (since 1.2)
> > must go through the Verifier (this is what I was sure it was
> > happening since I remembered reading that most Java code executed
> > in real-world applications is not verified)
>
> Wow.  I ran some tests too, and Stephen is absolutely right.  It appears
> that Sun quietly turned off verification by default for bytecode loaded from
> the local disk (not applets).  They've apparently
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4030988), acknowledged
> that it is a bug, and said that it will not be fixed.  The change had
> something to do with compatibility with old bytecode.  More details
> (http://www.cafeaulait.org/reports/accessviolations.html)
>
> This is a clear violation of the JVM Spec. And (regardless of protestation
> to the contrary) it IS a big security problem.  Just because bytecode is
> loaded from the local disk does not mean it's trustworthy.  Every
> application uses lots of libraries that developers download from the
> Internet (as compiled jar files) and loaded from the local disk.  Unless you
> run with "java -verify" that code won't get verified.
>
> I'm sure that the percentage of applications that are running with both
> verification and sandbox is terrifyingly small.  Probably only applets and
> maybe Java Web Start applications.  As I mentioned before some of the J2EE
> servers are now enabling a sandbox, but their security policies are
> generally wide open.
>
> I think there are two relatively easy things we can do here. First, let's
> find out what plans Sun has for the new verifier -- we should strongly
> encourage them to turn it on by default.  Second, we can work on ways to
> encourage people to use sandboxes -- tools, articles, and awareness.
>
> --Jeff
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Owasp-dotnet mailing list
> Owasp-dotnet at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
>



From michaelslists at gmail.com  Tue Mar 28 23:23:36 2006
From: michaelslists at gmail.com (michaelslists at gmail.com)
Date: Wed, 29 Mar 2006 15:23:36 +1100
Subject: [SC-L] Re: [Full-disclosure] Re: [Owasp-dotnet] Re: 4 Questions:
	Latest IEvulnerability, Firefox vs IE security,
	Uservs Admin risk profile,
	and browsers coded in100% Managed Verifiable code
In-Reply-To: <000101c652e9$98110e30$0201a8c0@Jaluno.local>
References: <000201c652bf$9edb9660$0201a8c0@Jaluno.local>
	<071e01c652e4$382b22d0$8a04a8c0@intranet.aspectsecurity.com>
	<000101c652e9$98110e30$0201a8c0@Jaluno.local>
Message-ID: <5e01c29a0603282023g6288fb0g84570405fae405f6@mail.gmail.com>

I just tried a few ways and couldn't figure anything out;

It doesn't seem like you can modify a java.lang Class from outside the
package (even unverified) and I also couldn't get my class _inside_
java.lang.

Maybe BCEL can get further ... or maybe I missed something.

-- Michael


On 3/29/06, michaelslists at gmail.com <michaelslists at gmail.com> wrote:
> I wonder if you could disable the default security manager with unverified code.
>
> Probably.
>
> Hmm.
>
> -- Michael
>
>
> On 3/29/06, Jeff Williams <jeff.williams at aspectsecurity.com> wrote:
> > > Jeff, as you can see by Stephen de Vries's response on this thread,
> > > you are wrong in your assumption that most Java code (since 1.2)
> > > must go through the Verifier (this is what I was sure it was
> > > happening since I remembered reading that most Java code executed
> > > in real-world applications is not verified)
> >
> > Wow.  I ran some tests too, and Stephen is absolutely right.  It appears
> > that Sun quietly turned off verification by default for bytecode loaded from
> > the local disk (not applets).  They've apparently
> > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4030988), acknowledged
> > that it is a bug, and said that it will not be fixed.  The change had
> > something to do with compatibility with old bytecode.  More details
> > (http://www.cafeaulait.org/reports/accessviolations.html)
> >
> > This is a clear violation of the JVM Spec. And (regardless of protestation
> > to the contrary) it IS a big security problem.  Just because bytecode is
> > loaded from the local disk does not mean it's trustworthy.  Every
> > application uses lots of libraries that developers download from the
> > Internet (as compiled jar files) and loaded from the local disk.  Unless you
> > run with "java -verify" that code won't get verified.
> >
> > I'm sure that the percentage of applications that are running with both
> > verification and sandbox is terrifyingly small.  Probably only applets and
> > maybe Java Web Start applications.  As I mentioned before some of the J2EE
> > servers are now enabling a sandbox, but their security policies are
> > generally wide open.
> >
> > I think there are two relatively easy things we can do here. First, let's
> > find out what plans Sun has for the new verifier -- we should strongly
> > encourage them to turn it on by default.  Second, we can work on ways to
> > encourage people to use sandboxes -- tools, articles, and awareness.
> >
> > --Jeff



From mouse at Rodents.Montreal.QC.CA  Wed Mar 29 03:31:07 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Wed, 29 Mar 2006 03:31:07 -0500 (EST)
Subject: [SC-L] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <000001c652d6$a85af4d0$0201a8c0@Jaluno.local>
References: <242a0a8f0603271418k84a9661uc964be661cd7360@mail.gmail.com><20060328235413.23659.qmail@paddy.troja.mff.cuni.cz>
	<000001c652d6$a85af4d0$0201a8c0@Jaluno.local>
Message-ID: <200603290832.DAA02108@Sparkle.Rodents.Montreal.QC.CA>

> no, a browser written in java would not have buffer overflow/stack
> issues.  the jvm is specifically designed to prevent it ...

And of course, we all know all JVM implementations are perfect.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From stephen at corsaire.com  Wed Mar 29 03:51:07 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Wed, 29 Mar 2006 15:51:07 +0700
Subject: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest
	IE vulnerability, Firefox vs IE security, Uservs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
Message-ID: <ABAEAB4F-6BCC-4162-8C4A-34B21355EEB8@corsaire.com>


Hi Dinis,

On 29 Mar 2006, at 05:52, Dinis Cruz wrote:

>
> Thanks for confirming this (I wonder how many other other Java
> developers are aware of this (especially the ones not focused on
> security)).
>

Most I've worked with aren't really aware of the security manager,  
never mind bytecode verification.
It is an issue, but the security risk in the real world may be a bit  
overstated.  If I were a maliciously minded attacker that wanted  
users to execute my evil Java program, I wouldn't need to mess about  
with the lack of verification, I could just write evil code in  
perfectly verifiable format and rely on users to execute it.
Can anyone come up with attack vectors that exploit lack of  
verification on downloaded code that couldn't be exploited by other  
(easier) means?

>
> Stephen, do you have any idea of what is the current percentage of  
> 'real
> world' Java applications are executed:
>
>     a) with verification
>
>     b) on a secure sandbox
>

Very few.  As Jeff mentioned some Java Application servers ship with  
a security policy enabled, but the policy doesn't restrict anything  
(e.g. JBoss), other's show you how to run with a sec policy, but  
don't apply it by default (e.g. Tomcat).  In some cases, with the  
more complex app servers a sec policy would be of little security  
benefit because the server needs so much access in order to function  
properly that the policy could be considered completely open.

In some ways I think we're applying double standards here.  Just  
because a virtual machine offers the facility for defining a security  
policy and verification doesn't mean that it _has_ to use it.  There  
are  native executable programs that I trust, so why should a program  
that runs in a VM be subject to more stringent security controls just  
because they're available?  IMO whether code needs to be sandboxed  
and controlled by a policy should be decided on a case by case basis  
rather than a blanket rule.
>
> Note that for example I have seen several Java Based Financial
> Applications which are executed on the client which either require  
> local
> installation (via setup.exe / App.msi) or require that the user grants
> that Java application more permissions that the ones allocated to a
> normal Sandboxed browser based Java App.

This is quite common for an app, and granting more permissions is  
fine as long as those are tightly controlled by the java security  
policy.

>>
>>
> Humm, this is indeed interesting. Ironically, the 1.1 and 2.0 versions
> of the CLR will thrown an exception in this case (even in Full Trust).
> Since verification is not performed on that .Net Assembly, the CLR  
> might
> pick up this information when it is resolving the method's relative
> address into the real physical addresses (i.e. during JIT).
>
>> Using the same code with an Applet loaded from the filesystem throws
>> an IllegalAccessError exception as it should.
>>
>>
> What do you mean by 'Applet loaded from the filesystem'?
>
> Where? In a Browser?
>

If you load an applet in a browser using a url such as: file:///data/ 
stuff/launch.html then no verification is performed.
But if you access the applet using http/s then it will be verified.

cheers,

-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com







From vanderaj at greebo.net  Tue Mar 28 22:41:17 2006
From: vanderaj at greebo.net (Andrew van der Stock)
Date: Wed, 29 Mar 2006 14:41:17 +1100
Subject: [SC-L] Java integer overflows (was: a really long topic)
In-Reply-To: <5e01c29a0603281930g427b3bb2vada6afd70f8c1eb@mail.gmail.com>
References: <242a0a8f0603271418k84a9661uc964be661cd7360@mail.gmail.com>
	<20060328235413.23659.qmail@paddy.troja.mff.cuni.cz>
	<5e01c29a0603281749y47b5396w382cd718a1a832ab@mail.gmail.com>
	<E65BA254-3C66-4C27-BE78-6573EE4E889B@greebo.net>
	<5e01c29a0603281930g427b3bb2vada6afd70f8c1eb@mail.gmail.com>
Message-ID: <EE0D6313-A1AF-4C85-9BE8-2B97DDBB76B8@greebo.net>

I'm not talking arbitrary code execution, I'm talking about odd code  
paths, bizarre outcomes, and DoS.

For example (found via 19 Sins, Viega, Howard and LeBlanc):
http://seclists.org/lists/bugtraq/2004/Nov/0097.html

I know Michael reads webappsec, he may have more examples.

In my own code testing, I look for silly behaviors if a user can  
insert a large or negative number. You'd be surprised how often it  
occurs. There is no excuse not to include basic range checks when  
performing data validation.

thanks,
Andrew

On 29/03/2006, at 2:30 PM, michaelslists at gmail.com wrote:

> No you dont.
>
> Arrays are all bounds checked; ..., that is, the following code will
> throw an exception:
>
> ================================
> class Foo {
>   static {
>     int[] m = new int[2];
>     System.out.println(m[34]);
>   }
> }
> ================================
>
>
> What do you mean by "overflow"? Do you mean this?
>
> ================================
> class Foo {
>   static {
>     int m = Integer.MAX_VALUE;
>     int k = Integer.MAX_VALUE + Integer.MAX_VALUE;
>     System.out.println(m);
>     System.out.println(k);
>     System.exit(0);
>   }
> }
> ================================
>
> if so, I don't see how that is an issue.
>
> -- Michael
>
>
>
> On 3/29/06, Andrew van der Stock <vanderaj at greebo.net> wrote:
>> This is not quite true.
>>
>> Java does not prevent integer overflows (it will not throw an
>> exception). So you still have to be careful about array indexes.
>>
>> Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2234 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060329/344704c4/attachment.bin 

From gunnar at arctecgroup.net  Wed Mar 29 07:52:10 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Wed, 29 Mar 2006 06:52:10 -0600
Subject: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, Uservs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <4429B1A0.5040800@ddplus.net>
References: <033601c65153$421e1140$1204a8c0@intranet.aspectsecurity.com>
	<4429B1A0.5040800@ddplus.net>
Message-ID: <D9A25556-7A84-4855-9BD2-A427DA3C3C3B@arctecgroup.net>

> This comes back to that great concept called 'Faith-based' Security  
> (see Gunnar Peterson's post http://1raindrop.typepad.com/1_raindrop/ 
> 2005/11/net_and_java_fa.html ), which is when people are told so  
> many times that something is secure, that that they believe that it  
> MUST be secure. Some examples:

This is also neatly summarized by Brian Snow thusly:

We will be in a truly dangerous stance: we will think we are secure  
(and act accordingly) when in fact we are not secure.

-gp

1. Notes and links on "We Need Assurance!" paper
http://1raindrop.typepad.com/1_raindrop/2005/12/the_road_to_ass.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060329/8298eb4b/attachment.html 

From mshines at purdue.edu  Wed Mar 29 08:25:21 2006
From: mshines at purdue.edu (Michael S Hines)
Date: Wed, 29 Mar 2006 08:25:21 -0500
Subject: [SC-L] Managed Code and Runtime Environments - Another layer of
	added security?
In-Reply-To: <4429B1A0.5040800@ddplus.net>
Message-ID: <003901c65334$3b195ac0$4fa7d280@OS00009>

Which brings us to the point of asking why we must have this run time environment to
protect the computing resources.  Why isn't this a function of and included in the
Operating System code?     
Is this like a firewall and IDS - just another layer we have to add due to ineffective and
insecure OS's? 
Are we dealing with symptoms or the real solution?   
 
Just wondering?
-----------------------------------
Michael S Hines
mshines at purdue.edu 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060329/0e9d9ccb/attachment.html 

From ken at krvw.com  Wed Mar 29 09:08:26 2006
From: ken at krvw.com (Kenneth R. van Wyk)
Date: Wed, 29 Mar 2006 09:08:26 -0500 (EST)
Subject: [SC-L] Software security efforts at DTCC
Message-ID: <4256.72.254.50.96.1143641306.squirrel@mail.krvw.com>

FYI, some more mainstream coverage of software security issues.  This article --
http://www.securitypipeline.com/183702555;jsessionid=SF0AM1XSETTOEQSNDBECKICCJUMEKJVN
-- describes some software security process improvements under way at the Depository Trust
and Clearing Company (DTCC).

What I find encouraging is hearing about companies that are bringing their security and
software development efforts together.  YMMV...

Cheers,

Ken
-- 
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




From mouse at Rodents.Montreal.QC.CA  Wed Mar 29 12:19:19 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Wed, 29 Mar 2006 12:19:19 -0500 (EST)
Subject: [SC-L] Managed Code and Runtime Environments - Another layer of
	added security?
In-Reply-To: <003901c65334$3b195ac0$4fa7d280@OS00009>
References: <003901c65334$3b195ac0$4fa7d280@OS00009>
Message-ID: <200603291728.MAA05657@Sparkle.Rodents.Montreal.QC.CA>

> Which brings us to the point of asking why we must have this run time
> environment to protect the computing resources.  Why isn't this a
> function of and included in the Operating System code?

Because "we" chose an OS that doesn't do that.

> Is this like a firewall and IDS - just another layer we have to add
> due to ineffective and insecure OS's?

In a sense.  But I'd put it in a way that slants it rather differently;
I'd say that they are layers "we" have to add because "we" chose an OS
that didn't include that stuff.

It's not the OS's fault that it doesn't do something it's not designed
to do.  The real problem from this perspective is all the people who
are picking Windows or Linux or something to run on their machines and
then expecting it to have security properties it was never intended to
have.

Of course, if you try a "real" (from this security standpoint) OS, you
will find that, as it must to achieve that level of assurance, it makes
a lot of the things you've used to doing a lot harder.  I suspect that
between the additional up-front cost of such an OS and the
inconvenience it imposes, most people prefer "add-on" security - less
thorough but sufficiently less costly to tip the balance.  (Actually, I
suspect most people don't actually think about it and just grumble that
the OS doesn't Just Do The Right Thing, even though that would require
the mythical mind-reading peripheral.)

> Are we dealing with symptoms or the real solution?

Symptoms.  The real problem is...well, depending on how you want to
spin it, it could be "choosing the wrong OS for the job" or "the high
cost of inconvenience" or various other things.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From neumann at csl.sri.com  Wed Mar 29 13:17:12 2006
From: neumann at csl.sri.com (Peter G. Neumann)
Date: Wed, 29 Mar 2006 10:17:12 PST
Subject: [SC-L] Managed Code and Runtime Environments - Another layer of
	added security?
In-Reply-To: Your message of Wed, 29 Mar 2006 12:19:19 -0500 (EST)
Message-ID: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>

Der Mouse is barking up the right rathole.

*** BEGIN SOAPBOX ***

Having cut my security eye-teeth in Multics from 1965 to 1969, I am
continually drawn back into discussions of what Multics did right that
has been systematically (!) ignored by almost all subsequent operating
systems.  For the younger folks among the SC-L audience, let me mention
a few of the architectural strengths.  There were no buffer overflows in
the stack, because anything out of the stack frame was not executable.
The ring-structured domain architecture and file system access controls
permitted straightforward sandboxing.  Dynamic linking and revocation
were fundamental.  Segmentation and paging enabled layers of virtual
machines and protected virtual memory.  The I/O system had virtual
stream names, virtual I/O, and common device-driver software where
appropriate, coupled with separate hardware for the input-output
controller (GIOC).  The programming language was the stark EPL subset of
PL/I and the corresponding McIlroy-Morris EPL compiler, which seems to
have avoided some of the characteristic programming errors that are
still common today.  No software was written until there was an approved
specification, with well defined interfaces and exception conditions
that were explicitly characterized in EPL.  And so on into a visionary
sense of a future that has been largely lost for may perceived reasons,
some of which are bogus, some of which are just seriously short-sighted.

*** END SOAPBOX ***

I'm sure this message may generate all sorts of Ifs and Ands and Buts.
But the Butt we are kicking is our own.

Cheers!  PGN


From mouse at Rodents.Montreal.QC.CA  Wed Mar 29 13:41:35 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Wed, 29 Mar 2006 13:41:35 -0500 (EST)
Subject: [SC-L] Managed Code and Runtime Environments - Another layer of
	added security?
In-Reply-To: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
References: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
Message-ID: <200603291901.OAA06533@Sparkle.Rodents.Montreal.QC.CA>

> Der Mouse is barking up the right rathole.

:-)  That's a lovely mangled metaphor.  And, thanks for the kind words;
I'm glad to see I'm not totally out to lunch.  (I haven't been at this
for as long as you have - you write "from 1965 to 1969", during which
time I was at most five years old - and it's good to get confirmation
of some of what I think I've learnt.)

> No software was written until there was an approved specification,
> with well defined interfaces and exception conditions

And here you come close, I believe, to one of the reasons this kind of
security architecture is not more done.

This kind of coding - heck, even just writing good specifications - is
hard work, work that comparatively few people are competent to do.  In
all my years at this, I can count the number of times I've seen a
really well-defined specification on the fingers of one hand.  (The
case I usually cite is the VAX Architecture Reference Manual, which is
carful to call out all the cases where the behaviour is UNDEFINED or
UNPREDICTABLE, those being technical terms defined early in the
document, and to cover every possibility with defined behaviour or one
of those.)  Almost everything has holes, cases where the spec is
silent; this is not the way to produce solid designs.  In many cases a
shaky design is no big problem (so your solitaire game crashes now and
then, so what?).  But in other cases it can be quite disastrous, with
the kind of consequences everyone here surely knows far too much about.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From u3902 at siliconkeep.com  Wed Mar 29 14:50:39 2006
From: u3902 at siliconkeep.com (Olin Sibert)
Date: Wed, 29 Mar 2006 14:50:39 -0500
Subject: [SC-L] Managed Code and Runtime Environments - Another
	layer of added security?
In-Reply-To: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
References: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
Message-ID: <7.0.1.0.2.20060329143405.03ce00d0@siliconkeep.com>

While we're on Multics lessons, let's not forget upward-growing
stacks (which were a natural consequence of the segmented
addressing architecture).

Multics code was not immune to buffer overflows, but in most cases
the effect was blunted because the out-of-range index values could
only affect data beyond the current activation record--in contrast
with most linear addressing systems where an overflow is almost
always able to reach important values like the return address.

It is sobering to reflect how much of the current state of our art
was laid out clearly in 1969 by Peter's own "The Role of Motherhood
in the Pop Art of System Programing" paper and by the 1973
Saltzer/Schroeder paper "The Protection of Information in Computer
Systems".  These are always worth a read:
    http://multicians.org/pgn-motherhood.html
    http://www.cs.virginia.edu/~evans/cs551/saltzer/

  -- Olin Sibert

At 01:17 PM 3/29/2006, Peter G. Neumann wrote:
>Der Mouse is barking up the right rathole.
>
>*** BEGIN SOAPBOX ***
>
>Having cut my security eye-teeth in Multics from 1965 to 1969, I am
>continually drawn back into discussions of what Multics did right that
>has been systematically (!) ignored by almost all subsequent operating
>systems.  For the younger folks among the SC-L audience, let me mention
>a few of the architectural strengths.  There were no buffer overflows in
>the stack, because anything out of the stack frame was not executable.
>The ring-structured domain architecture and file system access controls
>permitted straightforward sandboxing.  Dynamic linking and revocation
>were fundamental.  Segmentation and paging enabled layers of virtual
>machines and protected virtual memory.  The I/O system had virtual
>stream names, virtual I/O, and common device-driver software where
>appropriate, coupled with separate hardware for the input-output
>controller (GIOC).  The programming language was the stark EPL subset of
>PL/I and the corresponding McIlroy-Morris EPL compiler, which seems to
>have avoided some of the characteristic programming errors that are
>still common today.  No software was written until there was an approved
>specification, with well defined interfaces and exception conditions
>that were explicitly characterized in EPL.  And so on into a visionary
>sense of a future that has been largely lost for may perceived reasons,
>some of which are bogus, some of which are just seriously short-sighted.
>
>*** END SOAPBOX ***
>
>I'm sure this message may generate all sorts of Ifs and Ands and Buts.
>But the Butt we are kicking is our own.
>
>Cheers!  PGN
>_______________________________________________
>Secure Coding mailing list (SC-L)
>SC-L at securecoding.org
>List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
>List charter available at - http://www.securecoding.org/list/charter.php


From mouse at Rodents.Montreal.QC.CA  Wed Mar 29 17:19:22 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Wed, 29 Mar 2006 17:19:22 -0500 (EST)
Subject: [SC-L] Managed Code and Runtime Environments - Another
	layer of added security?
In-Reply-To: <7.0.1.0.2.20060329143405.03ce00d0@siliconkeep.com>
References: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
	<7.0.1.0.2.20060329143405.03ce00d0@siliconkeep.com>
Message-ID: <200603292221.RAA08063@Sparkle.Rodents.Montreal.QC.CA>

> Multics code was not immune to buffer overflows, but in most cases
> the effect was blunted because the out-of-range index values could
> only affect data beyond the current activation record--in contrast
> with most linear addressing systems where an overflow is almost
> always able to reach important values like the return address.

This is only because the libraries used store later characters in a
string at higher addresses (as compared to earlier characters).  If the
string libraries stored strings the other way around (with the earlier
characters at the higher addresses), downward-growing stacks would have
exactly this kind of buffer overrun protection.

Hmm, I wonder if there's something useful lurking there.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From gunnar at arctecgroup.net  Wed Mar 29 19:00:16 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Wed, 29 Mar 2006 19:00:16 -0500
Subject: [Full-disclosure] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: LatestIE
	vulnerability, Firefox vs IE security, Uservs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <4429B1A0.5040800@ddplus.net>
References: <033601c65153$421e1140$1204a8c0@intranet.aspectsecurity.com><4429B1A0.5040800@ddplus.net>
Message-ID: <000001c6538c$ecdfbad0$0201a8c0@Jaluno.local>

> This comes back to that great concept called 'Faith-based' Security  
> (see Gunnar Peterson's post http://1raindrop.typepad.com/1_raindrop/ 
> 2005/11/net_and_java_fa.html ), which is when people are told so  
> many times that something is secure, that that they believe that it  
> MUST be secure. Some examples:

This is also neatly summarized by Brian Snow thusly:

We will be in a truly dangerous stance: we will think we are secure  
(and act accordingly) when in fact we are not secure.

-gp

1. Notes and links on "We Need Assurance!" paper
http://1raindrop.typepad.com/1_raindrop/2005/12/the_road_to_ass.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060329/a1e53790/attachment.html 
-------------- next part --------------
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

From dinis at ddplus.net  Thu Mar 30 04:16:50 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 30 Mar 2006 10:16:50 +0100
Subject: [SC-L] On sandboxes, and why you should care
Message-ID: <442BA202.3020000@ddplus.net>

On 29/03/06, Andrew van der Stock <vanderaj at greebo.net> wrote:
> Hi there,

Hello Andrew,

As a response to your post, I will try to clarify why I believe that
Sandboxes are a fundamental piece in the security of Web Applications,
the hosting server(s) and the datacenter.

First of all, there are two issues with Verification. The first is
that you need verifiable code in both .Net and Java in order to run
that code in a Sandbox (Partial trust in .Net). The 2nd one is that if
you remove verification from the security benefits of .Net and Java,
and you admit that that is OK (which seems to be the current position
today), then you just eliminated some of the biggest security and
reliability features of these 'managed environments' (you also have
the problem that when (not if) you move your code to a secure sandbox
you will have many more problems to deal with (from performance to
unverifiable code issues))

>
> I must have missed a memo or something. I don't know about you, but
> I've reviewed many J2EE apps which had far greater things wrong than
> not running in a verified / trusted environment. I've never seen an
> attack which is realistic or usable for such attacks.

Really???  I am not so sure.

Lets look at some of your assets: The J2EE application, the supporting
database, the server(s) hosting your environment, the data center,
that companies internal network, the users (end-clients) and all users
(end-clients) that use all websites hosted in that data center (add to
this mix, items like: company public profile/confidence, customer's
private data, data privacy and SoX laws,  and end up with a complex
multilayer mesh of assets)

Now, there are different levels of compromise here (I will just list some)

- J2EE application compromise
- Database compromise
- Web Server compromise
- Database server compromise
- Data center compromise

One of the main benefits of what I am defending (Sandboxing the
execution of code) is that you are able to dramatically limit the
damage created by (for example) malicious code executed on the
application's process space.

So for example, the damage of a file upload vulnerability (which
allows you to put a *.jsp file on the server and execute it) is
limited to the permissions allocated to the Sandbox.

The reality is that if you don't run that code with ANY sandbox, then
your entire Application, Server and Datacenter security is dependent
of the non existence of any malicious code in all applications running
on all web servers.

Also remember that more and more we will have to deal with malicious
developers, or with malicious attackers that are able to inject
malicious code into a website via:
    - a library used by a developer
    - a compromised developer account details (which tend to be sent by
email)
    - a compromised developer computer (infected via Spyware) which
allows the malicious attacker to control remotely that computer and
(for example) path Eclipse or Visual Studio in memory so that every
time a piece of code its submitted (checked-in) , the malicious
payloads are inserted.

If you add up the number of people that have the capability to put one
line of malicious code on a web server, you will see that this is a
very large number indeed.

A couple more examples of ways malicious code can be uploaded to the
server: SQL Injection, XSS (payload deployed to the admin section),
authorization vulnerabilities which allow the editing of files on the
server (via for example the CMS (content management system)),
manipulating params which control which method is executed (when
Reflection is used to perform late binding on method calls based on
the commands received) ,Social engineering, etc...

Sometimes you will even find CMS (Content Management Systems) that
provide power users (or 'area x' admins) with powerful customization
features which when exploited (or not, depending if this is a
'feature') allow the injection of code.

Do you really think that it is a good idea to have your entire data
center security and CIA (Confidentiality, Integrity and Availability)
depended on such extraordinary set of circumstances?

So the first main security benefit that we have with using Sandboxes
is: Containment, Damage Limitation, and Risk Reduction (you went from
full data center compromise to a local and limited problem)

Note: the reason that I say data center compromise, is because most
(if not all) data centers (and even corporate networks) are not
designed to sustain an attack executed from inside (especially when
the malicious attacker as admin control over one server)

>
> If I find (say) 100 things wrong, the business can afford the time
> and resources to fix 65 of these and the inclination to fix none. Any
> fix is a good fix from my point of view, but I need to be careful in
> what I strongly recommend to be fixed, and what I'll let go through
> to the keeper.

Sure, but out of those 100, how many allow remote command execution or
upload of scripts to the server?

So ironically, you could find your self in a position where the first
thing you should do (from a security point of view) would be to
isolate that server/application so that a compromise of that
application is limited to that application's assets.
>
> I'm sorry, but I can't recommend turning on the verifier and asking
> the devs to go through the painful effort of figuring out exactly
> what perms their code will require when there are actual exploitable
> issues (those 65 - 80 or so) which may cause actual financial loss.

Well that depends on what those issues are, but I agree with you that
converting existing applications designed to run outside a sandbox,
into 'Sandboxable' applications, is a massive project.

Also note that just turning on the verifier is not good enough.  You
will need other protection layers.

What other Protection layers I am talking about? For example: "Offline
or realtime code profiling and analysis"

One of the reasons why I strongly believe that Full Trust code (and
the Java --noverify) should be verifiable, is because if it was, I
could analyse (offline and in real time) that code for security
problems and block its execution when malicious code is detected.

If the code is verifiable, I am able to make a series of security
decisions (with a high degree to certainty) based on the the 'risk
profile' of that code. For example: Does it make calls to unmanaged
code, does make calls to private members using reflection, does start
processes, etc...

If the code is not verifiable then It is as good as trying to analyse
a C++ binary (you basically will have no ability to make hard
decisions because you just can't predict what is inside that binary
(or unverifiable code)). Which is the reason why signature based
Anti-Virus and Anti-Spyware applications are very bad at detecting new
virus, exploits or attacks.

So the 2nd security advantage that Verifiable code gives you is: Allow
Security decisions to be made based on pre-execution or real-time code
analysis / checks.

> Ditto asking for "final" and other modifiers to be used. Turning on
> the verifier / forcing the assertion of required privs requires a
> complete re-test. For many larger apps, testing can cost millions of
> dollars.

In the current environment yes (because these applications where
designed to run with maximum privileges), but when (not if) the
applications are designed (or modified) to run in sandboxes, then the
cost of changing them to run on 'secure run-time environments' will be
more acceptable. Which is one of the reasons why the sooner
Sandboxable code starts to be created the better.

> How much has been lost with this attack? Ever?

Well, that depends on how you measure this cost?

Remember for example, that the reason why most Buffer Overflows are so
dangerous is because the payload is executed outside a sandbox :)

So I can argue that a vulnerability that allows remote .Net or Java
code to be executed on the victim, is as dangerous as a Buffer
Overflow.

And I think there have some some financial losses out there due to
Buffer Overflows exploits, don't you agree?  :)

Take for example the latest Microsoft Office Buffer Overflow
vulnerabilities. Which one is more dangerous, a Word file with such
exploit (and payload) or a Word file with that payload injected inside
a Macro? (note that in Office 2003, Macros are .Net assemblies which
require Full Trust to execute). The risk profile is about the same for
both, since both have a 90% chance of being executed.
>
> Remember, the mitigant to many risks may not be a technical control;
> it may be reactive (audit), legal (T&C's / contracts), or it may be
> process driven, such as settlement periods.
>
> I'm interested - has *anyone* seen an attack (.NET or J2EE) which
> aims at the trust model of the underlying VM?

I have (but can't talk about it). Humm, where do you see a 'trust
model on the underlying VM'? If you are running with Full Trust or
--noverify, the only 'trust model' that exists is the same one that
exists for unmanaged (C++) applications (for example OS based ACL
restrictions)

But if you want a very good public example, look at the PHP XML-RPC
worms which do exactly that. They use a vulnerability in a
application's feature, to upload code to the server and execute it
from the inside (in most cases making those computer boot-net zombies
used to launch other attacks)

If these PHP applications were running inside a sandbox, then this
worm would have never been possible if that Sandbox (for example) did
not allow direct outbound connections.

> Has it lost anyone any
> money / reputation / shareholder confidence?
Money yes, reputation and shareholder confidence, not really.

There is a small number of public disclosure of this type of attacks,
and the media doesn't tend to report that the problem is 'lack of
Sandboxing' (see the coverage on the PHP XML-RPC worm)

> I'm happy to hear if
> there has been,

Sometimes all it takes is to look at reality with another perspective.

After my explanations, do you still think that this is a non-issue

> but otherwise, I'd like to think we have more
> important things to educate devland on than worrying about a risk
> which doesn't really rate.

Well I strongly disagree that this 'risk doesn't really rate', but
since we are talking about 'devland'. let me give you my final reason
why I believe the development of verifiable and sandboxable code is so
important.

And the reason is: To allow privilege separation and to make source
code audits practical and accountable.

Lets take typical source-code security audit project. You get given an
application (App A) that has 500,000 lines of code (executed with Full
Trust or with --noverify), and you are given 1 week to: understand the
app, audit the code, find vulnerabilities, write proof of concepts and
write your report.

Now, if you need to look at every single one of those 500,000 lines of
code, can you really do it in that time frame?

No way.

Can you provide a strong level of assurance to your client that that
application has no major vulnerabilities?

No way, because you known that all you need is 1 vulnerable method
inside that 500,000 block of code, to compromise the entire solution.

So let's look at another application (App B) which has the same
functionality but, is executed in three Sandboxes:

 - Sandbox A) 450,000 lines of code executed in very restricted
Sandbox (let's say Asp.Net Low Trust)

  - Sandbox B) 48,000 lines of code executed in secure Sandbox (let's
say customized version of Asp.Net Medium Trust)

  - Sandbox C) 2,000 lines of code executed in a Sandbox which allows
calls to unmanaged code.

Given the same 1 week, you (as the security consultant auditing this
application) will spend most of your time in Sandbox C) code, less on
Sandbox B) code and even less on Sandbox A) code. Why? because only a
vulnerability in Sandbox C) would allow the compromise of the entire
App / Server / Datacenter.

More importantly, a vulnerability which in Sandbox A) you would mark
with a Critical Risk rating, in App A (due to the different DREAD
score) you would marked it with a Low Risk rating. Same code,
different Sandboxes, different Risk Profiles :)

And this brings me back to my frustration with the current status quo
(which is to write everything for Full Trust / --noverify
environments), because we already have working solutions that allow
the creation of applications like App B. What we don't have is
awareness, focus, commitment and client pressure to do it.

If today there is a good understanding / acknowledgment that
applications that need to be executed with Admin or System privileges
is not good security practices, then let's extend this and realise
that that Full Trust / --noverify code is also as bad.

I strongly believe that only when the majority (and eventually all)
applications we use look like App B (or even App C with 100% code
execution in a secure sandbox) we will have  trustworthy computing
environments.

>
> thanks,
> Andrew

No problem

Hope my explanations make sense

Dinis Cruz
Owasp .Net Project
www.owasp.net





From dinis at ddplus.net  Sun Mar 26 21:22:20 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Mon, 27 Mar 2006 03:22:20 +0100
Subject: [SC-L] [Full-disclosure] Re: [Owasp-dotnet] RE: 4 Questions: Latest
 IE
 vulnerability, Firefox vs IE security, User vs Admin risk profile,
 and browsers coded in 100% Managed Verifiable code
In-Reply-To: <020101c65054$73ffd9a0$1204a8c0@intranet.aspectsecurity.com>
References: <020101c65054$73ffd9a0$1204a8c0@intranet.aspectsecurity.com>
Message-ID: <44274C5C.4080108@ddplus.net>

Hi Jeff, comments inline

Jeff Williams wrote:
> Great topics.
>
> I'm a huge fan of sandboxes, but Dinis is right, the market hasn't really
> gotten there yet. No question that it would help if it was possible to run
> complex software like a browser inside a sandbox that restricted its ability
> to do bad things, even if there are vulnerabilities (or worse -- malicious
> code) in them.  
Absolutely, and do you see any other alternative? (or we should just
continue to TRUST every bit of code that is executed in our computers?
and TRUST every single developer/entity that had access to that code
during its development and deployment?)
>  I'm terrified about the epidemic use of libraries that are
> just downloaded from wherever (in both client and server applications). All
> that code can do *whatever* it wants in your environments folks!
>
>   
Yes they can, and one of my original questions was 'When considering the
assets, is there REALLY any major differences between running code as
normal user versus as an administrator?"
> Sandboxes are finally making some headway. Most of the Java application
> servers (Tomcat included) now run with their sandbox enabled (albeit with a
> weak policy). And I think the Java Web Start system also has the sandbox
> enabled.  So maybe we're making progress.
>   
True, but are these really secure sandboxes?

I am not a Java expert so I can't give you specific examples, but on the
.Net Framework a Partially Trusted 'Sandbox' which contains an
UnamanagedCode, MemberAccess Reflection or SkipVerification Permission,
should not be called a 'Sandbox' since it can be easily compromised.
> But, if you've ever tried to configure the Java security policy file, use
> JAAS, or implement the SecurityManager interface, you know that it's *way*
> too hard to implement a tight policy this way.
And .Net has exactly the same problem. It is super complex to create a
.Net application that can be executed in a secure Partially Trusted Sandbox.
>   You end up granting all
> kinds of privileges because it's too difficult to do it right.  
And the new VS2005 makes this allocation of privileges very easy: "Mr.
developer, your application crashed because it didn't have the required
permissions, Do you want to add these permissions, Yes No? ....
(developer clicks yes) ... "You are adding the permission
UnamanagedCodePermission, do you sure, Yes No? ... (developer clicks yes
(with support from application architect and confident that all
competitor Applications require similar permissions))"
> And only the
> developer of the software could reasonably attempt it, which is backwards,
> because it's the *user* who really needs it right. 
Yes, it is the user's responsibility (i.e. its IT Security and Server
Admin staff) to define the secure environment (i.e the Sandbox) that 3rd
party or internal-developed applications are allocated inside their data
center,

> It's possible that sandboxes are going the way of multilevel security (MLS).
> A sort of ivory tower idea that's too complex to implement or use. 
I don't agree that the problem is too complex. What we have today is
very complex architectures / systems with too many interconnections.

Simplify the lot, get enough resources with the correct focus involved,
are you will see that it is doable.
> But it
> seems like a really good idea that we should try to make practical. But even
> if they do start getting used, we can't just give up on getting software
> developers to produce secure code.  There will always be security problems
> that sandboxes designed for the platform cannot help with.
>   
Of course, I am not saying that developers should produce insecure code,
I am the first to defend that developers must have a firm and solid
understanding of the tools and technologies  that they use, and also as
important, the security implications of their code.
> I'm with Dinis that the only way to get people to care is to fix the
> externalities in the software market and put the burden on those who can
> most easily avoid the costs -- the people who build the software. Maybe then
> the business case will be more clear.
>   
Yes, but the key here is not with money (since that would also kill
large chunks of the Open Source world).

One of the solutions that I like, is the situation where all software
companies have (by law) to disclose information about the
vulnerabilities that they are aware of (look at the Eeye model of
disclosing information about 'reported but unpatched vulnerabilities').

Basically, give the user data (as in information) that he can digest and
understand, and you will see the user(s) making the correct decision(s).
> (Your last point about non-verified MSIL is terrifying. I can't think of any
> reason why you would want to turn off verification -- except perhaps startup
> speed. But that's a terrible tradeoff.)
>   
See my previous post (on this same thread) about this issue, but I think
that .Net is not alone in skipping verification for locally executed code :)

Dinis Cruz
Owasp .Net Project
www.owasp.net


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


From karger at watson.ibm.com  Thu Mar 30 10:43:32 2006
From: karger at watson.ibm.com (karger at watson.ibm.com)
Date: Thu, 30 Mar 2006 10:43:32 -0500
Subject: [SC-L] Multics history 
In-Reply-To: <200603301143.k2UBhTtL063433@ratsass.krvw.com> 
References: <200603301143.k2UBhTtL063433@ratsass.krvw.com>
Message-ID: <20060330154332.5636B36E63C@gsal-1.watson.ibm.com>


Peter and Olin make good points about Multics security.  Let me
recommend a paper that Roger Schell and I wrote a few years ago that
discusses a number of lessons from Multics that are
forgotten/ignored/unknown today.

Multics had very few if any buffer overflow problems for a number of
reasons.

Upwards growing stacks helped.  Most things being non-executable
helped.  Segmented addressing helped, because it made it very hard to
accidentally address something outside the current.

Using PL/I rather than C helped a great deal.  PL/I allows the same
low level access as C that you need for system-level code, but it has
several crucial differences. Strings and arrays are first class data
types.  References to them are NOT equivalent to doing pointer
arithmetic.  Even if stringrange and subscriptrange checking are
turned off, the compiler knows the maximum length of most strings and
arrays and generates code that stops writing to the string or array
when that length is reached.  If stringrange and subscriptrange are
turned on, then additional checking code is generated, but that wasn't
usually necessary!

Most Multics system-level code did not use the equivalent of malloc()
at all.  In fact, I think using it might have been explicitly
forbidden for system level code.  This was possible, because you could
easily allocate free memory in Multics by creating a temporary or
permanent segment.  The segmentation hardware would protect against
overflowing that memory, and if you put in the process directory, it
would be automatically garbage collected when the process terminated -
not by a traditional garbage collector, but by the entire process
directory being deleted when the process terminated.  The process
directory had a quota on it, so that you couldn't run the system out
of memory - only yourself.

Note - that is not to say that Multics was free of all security
vulnerabilities.  It certainly was not, but it was dramatically better
than almost anything in widespread use today.

The paper to look at is:

Karger, P.A. and R.R. Schell. Thirty Years Later: Lessons from the
Multics Security Evaluation. in Proceedings of the 18th Annual
Computer Security Applications Conference. 9-13 December 2002, Las
Vegas, NV: IEEE Computer Society. p. 119-126. URL:
http://www.acsa-admin.org/2002/papers/classic-multics.pdf
  

One other thing - before you send emails about how Multics was secure,
but it was bad for this or that reason, so it therefore it doesn't
count, please first take a look at Tom Van Vleck's web page about
myths about Multics.  

http://www.multicians.org/myths.html 

It's an amusing page to read, even if just for the war story about the
error message in Latin!

There is a LOT of bad information out there on the web about Multics
that simply isn't true.  Multics was certainly NOT a perfect system -
it had its flaws, but in all too many ways, the computer industry has
yet to catch up to what Multics could do back in the late 1960s!

Paul

====================================
Paul A. Karger, Ph.D.
IBM, T. J. Watson Research Center
Tel: +1 (914) 784-7294 (tieline 863)
Fax: +1 (914) 784-6205 (tieline 863)
Email: karger at watson.ibm.com
Mailing address: PO Box 704, Yorktown Heights, NY 10598, USA
For mail that cannot be sent to a Post Office Box:
Street address:  19 Skyline Drive, Hawthorne, NY 10532, USA



From smb at cs.columbia.edu  Thu Mar 30 20:30:44 2006
From: smb at cs.columbia.edu (Steven M. Bellovin)
Date: Thu, 30 Mar 2006 20:30:44 -0500
Subject: [SC-L] Managed Code and Runtime Environments - Another layer of
	added security?
In-Reply-To: <7.0.1.0.2.20060329143405.03ce00d0@siliconkeep.com>
References: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
	<7.0.1.0.2.20060329143405.03ce00d0@siliconkeep.com>
Message-ID: <20060330203044.e3e5e72b.smb@cs.columbia.edu>

On Wed, 29 Mar 2006 14:50:39 -0500, Olin Sibert <u3902 at siliconkeep.com>
wrote:

> While we're on Multics lessons, let's not forget upward-growing
> stacks (which were a natural consequence of the segmented
> addressing architecture).
> 
> Multics code was not immune to buffer overflows, but in most cases
> the effect was blunted because the out-of-range index values could
> only affect data beyond the current activation record--in contrast
> with most linear addressing systems where an overflow is almost
> always able to reach important values like the return address.
> 
I've heard that claim before; I've always thought it overrated.  In an
upward-growing stack, if you overflow a parameter passed to a
subroutine it will overwrite the subroutine's return address.  Since
many buffer overflows happen as a result of library calls -- think
strcpy() or scanf() -- this can be *more* of a danger.

The real advantage on Multics was PL/I, where character strings of
declared lengths were a built-in data type.

I'm teaching Operating Systems this semester; the textbook I'm using
constantly mentions the similarities of the Pentium hardware
architecture to Multics, complete with segments and rings.  (I've
also told my students to read Organick's book, because I can't bear
the thought of a CS major knowing nothing of Multics....)  When was the
last time you did an inter-ring call on a Pentium? The real issue, even
on Multics, wasn't the hardware features, it was the lack of
applications that were designed in a way that made them useful.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb


From karger at watson.ibm.com  Fri Mar 31 12:55:32 2006
From: karger at watson.ibm.com (karger at watson.ibm.com)
Date: Fri, 31 Mar 2006 12:55:32 -0500
Subject: [SC-L] upwards growing stacks
Message-ID: <20060331175532.B25FC36E63C@gsal-1.watson.ibm.com>


Steve Bellovin <smb at cs.columbia.edu writes:

>I've heard that claim before; I've always thought it overrated.  In an
>upward-growing stack, if you overflow a parameter passed to a
>subroutine it will overwrite the subroutine's return address.  Since
>many buffer overflows happen as a result of library calls -- think
>strcpy() or scanf() -- this can be *more* of a danger.
>
>The real advantage on Multics was PL/I, where character strings of
>declared lengths were a built-in data type.


Steve is absolutely correct.  The upwards growing stack protects a
routine against overflowing its own buffer.  If the buffer was passed
to the routine by a caller, the upwards growing stack does nothing.

However, the PL/I language does provide protection in that case.

Assume that the buffer in question is a character string.  Similar
things were done for arrays and structures.

The incoming parameter has to be declared, either with a specified
length which is known at compile time, or it must be declared as a
char(*) parameter.  If it has a specified maximum length (even if is a
varying string), the compiler knows what that length is and generates
code that either truncates or blank extends assignment statements,
as required.

If it is a char(*) parameter, then the caller is REQUIRED to pass an
argument descriptor that specifies the maximum length.  This argument
descriptor is created automatically by the compiler of the calling
routine.  The compiler generates code to use the length in the argument
descriptor to do the same truncation or blank extension as required.
The software author does not need to write anything about
argument descriptors (and indeed, cannot from PL/I).  It was all done
automatically by the Multics compilers for ALL languages, not just
PL/I.

What I described above were simple string assignment statements.  There
is also the substr() function and pseudo-op in PL/I that can specify
particular offsets within a string.  To get the offset values checked, you
had to turn on STRINGRANGE checking which would generate extra code to
do the checks.  There were probably other checks done by STRINGRANGE
that I don't remember.  (It's been a LONG time...)

I've always thought it a shame that PL/I usage has mostly died out,
although IBM still supports it for many machines.  The ANSI G subset
of PL/I was a quite reasonable language for systems programming, much
better than C, and not that much harder to compile than C.  Full PL/I
is another story.

    - Paul


From gem at cigital.com  Fri Mar 31 13:53:59 2006
From: gem at cigital.com (Gary McGraw)
Date: Fri, 31 Mar 2006 13:53:59 -0500
Subject: [SC-L] CNN podcast
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB64B701@va-mail.cigital.com>


Software security in the press...
http://www.cnn.com/services/podcasting/

gem
www.swswec.com


Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From crispin at novell.com  Sun Apr  2 18:49:57 2006
From: crispin at novell.com (Crispin Cowan)
Date: Sun, 02 Apr 2006 15:49:57 -0700
Subject: [SC-L] Re: [Owasp-dotnet] RE: 4 Questions: Latest IE
	vulnerability, Firefox vs IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <44274C5C.4080108@ddplus.net>
References: <020101c65054$73ffd9a0$1204a8c0@intranet.aspectsecurity.com>
	<44274C5C.4080108@ddplus.net>
Message-ID: <44305515.2010407@novell.com>

Dinis Cruz wrote:
> Jeff Williams wrote:  
>> I'm a huge fan of sandboxes, but Dinis is right, the market hasn't really
>> gotten there yet. No question that it would help if it was possible to run
>> complex software like a browser inside a sandbox that restricted its ability
>> to do bad things, even if there are vulnerabilities (or worse -- malicious
>> code) in them.      
> Absolutely, and do you see any other alternative? (or we should just
> continue to TRUST every bit of code that is executed in our computers?
> and TRUST every single developer/entity that had access to that code
> during its development and deployment?)
>   
This is exactly what AppArmor <http://en.opensuse.org/Apparmor> was
designed for: conveniently confining applications to only be able to do
what they need to do. Application's least privilege.

I am running this mail client (Thunderbird) from within a "sandbox" (we
call it a "profile"). I have attached this policy, which should be
pretty self-explanatory.

>> But, if you've ever tried to configure the Java security policy file, use
>> JAAS, or implement the SecurityManager interface, you know that it's *way*
>> too hard to implement a tight policy this way.    
> And .Net has exactly the same problem. It is super complex to create a
> .Net application that can be executed in a secure Partially Trusted Sandbox.
>   
This is where AppArmor really stands out. You can build an application
profile in minutes. Here is a video
<ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi> if me
demoing AppArmor in a presentation at FOSDEM 2006
<http://www.fosdem.org/2006>. The video is an hour-long lecture on
AppArmor, and for the impatient, the demo is from 16:30 through 26:00.

>> And only the
>> developer of the software could reasonably attempt it, which is backwards,
>> because it's the *user* who really needs it right. 
>>     
> Yes, it is the user's responsibility (i.e. its IT Security and Server
> Admin staff) to define the secure environment (i.e the Sandbox) that 3rd
> party or internal-developed applications are allocated inside their data
> center,
>   
It is very feasible for a user, not a developer, to build an AppArmor
profile. Prior requirements for using AppArmor are:

    * know how to use bash
    * know how to use chmod
    * know how to run the application in question


>> It's possible that sandboxes are going the way of multilevel security (MLS).
>> A sort of ivory tower idea that's too complex to implement or use.     
> I don't agree that the problem is too complex. What we have today is
> very complex architectures / systems with too many interconnections.
>   
"too many interconnections" is a Windows problem. In the UNIX world,
where (nearly) everything is a file, it is much easier to build
effective application containment policies.

> Simplify the lot, get enough resources with the correct focus involved,
> are you will see that it is doable.
>   
Indeed :)

> Basically, give the user data (as in information) that he can digest and
> understand, and you will see the user(s) making the correct decision(s).
>   
Well, maybe. Users are notorious for not making the right decision.
AppArmor lets the site admin create the policy and distribute it to
users. Of course that assumes we are talking about Linux users :)

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: opt.MozillaThunderbird.lib.thunderbird-bin
Url: http://krvw.com/pipermail/sc-l/attachments/20060402/00b63c34/attachment.ksh 

From pmeunier at cerias.purdue.edu  Mon Apr  3 10:42:52 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Mon, 03 Apr 2006 10:42:52 -0400
Subject: [SC-L] Re: [Owasp-dotnet] RE: 4 Questions: Latest IE
	vulnerability, Firefox vs IE security, User vs Admin risk profile, and
	browsers coded in 100% Managed Verifiable code
In-Reply-To: <44305515.2010407@novell.com>
Message-ID: <C056ACAC.1164C%pmeunier@cerias.purdue.edu>

AppArmor sounds like an excellent alternative to creating a VMWare image for
every application you want to run but distrust, although I can think of
cases where a VMWare image would be safer.  For example, the
installer/uninstaller may have vulnerabilities, may be "dirty" (it causes
problems by modifying things that affect other applications, or doesn't
cleanup correctly), or phones home, etc...  I guess you could make a profile
for the installer as well (I'm not very enthusiastic about that idea
though).  Also, I suspect that what you need to allow in some profiles is
possibly sufficient to enable "some level" of malicious activity.  It's
regrettable that it is only available for Suse Linux.

Perhaps one of the AppArmor mailing lists would be more appropriate to ask
this, but as you posted an example profile with "capability setuid", I must
admit I am curious as to why an email client needs that.  I tried looking up
relevant documentation on the Novell site, but it seems I was unlucky and
tried during a maintenance period because pages were loading erratically.  I
finally got to the "3.0 Building Novell AppArmor Profiles" page but it was
empty.  I would appreciate receiving more information about it.  I am also
interested in the "Linux Security Modules Interface".

Regards,
Pascal Meunier

On 4/2/06 6:49 PM, "Crispin Cowan" <crispin at novell.com> wrote:

> This is exactly what AppArmor <http://en.opensuse.org/Apparmor> was
> designed for: conveniently confining applications to only be able to do
> what they need to do. Application's least privilege.
> 
> I am running this mail client (Thunderbird) from within a "sandbox" (we
> call it a "profile"). I have attached this policy, which should be
> pretty self-explanatory.
> 




From crispin at novell.com  Mon Apr  3 12:02:27 2006
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 03 Apr 2006 09:02:27 -0700
Subject: [SC-L] Segments, eh Smithers?
In-Reply-To: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
References: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
Message-ID: <44314713.6030208@novell.com>

PGN cites many of the things that Multics did right and history did not
follow. Most of these issues are sufficiently entrenched in legacy
hardware and software that there is little chance to change them any
time soon.

Of particular and critical interest at this juncture is segmented
memory. Graybeards love segmented memory, and modern Linux kidz hate
segmented memory. A close friend has observed to me that 100% of A1
evaluated operating systems (both of them :) used segmented memory. In
stark contrast, all modern operating systems use paged memory instead.
Apparently there was a movement to hack segments into the Linux kernel a
year or so ago, but it was quickly shouted down.

Even if we could convince kernel developers to try segments, the only
hardware architectures left that still support segmented memory (x86)
are about to go extinct. x86-64 offerings from Intel and AMD have
removed the segmented memory functionality from the instruction set, and
they have no plans to put it back. Why should they, if approximately
zero operating systems will use the facility. Conversely, why should OS
developers muck about with segmentation if hardware supporting it is
about to become extinct? A classic chicken/egg problem in reverse, where
it is possible to do now, but about to die out because no one cares.

This leads me to 2 questions:

   1. Is it remotely possible to start a ground-swell of interest in
      segmentation, get keen software running on x86 CPUs, and do it
      soon enough to interest Intel or AMD in re-enabling segmentation
      support in their future x86-64 CPUs?
   2. If the answer to 1 is "no", then is it possible to build a kernel
      that offers the A1/EAL7 assurance of something like a Multics
      kernel, does it with pages instead of segments?

That second question is actually pretty technically deep. What is so
different about paged memory systems that makes them harder to secure
than segmented memory systems? My conjecture: it is the granularity of
the memory blobs. Consider:

    * In a segmented system, you have a small number of fairly large
      memory objects (segments). Segments are hefty enough that they can
      be of variable size, and also can have security tags describing
      their security level at multiple levels. So a given segment can be
      tagged as being security level 1, 2, 3, and so forth, and the TCB
      need only check the level before granting or denying access.
    * In a paged system, in contrast, you have a very large number of
      much smaller memory objects (pages). Pages are simple, even having
      fixed size. Fixed size wastes memory, but no one cares because the
      pages are small enough that it doesn't hurt much. Because pages
      are simple, you cannot tag them with a bunch of different security
      levels. For that matter, x86 architectures only recently got a
      (kind-of) ability to distinguish between read and execute
      permissions per page, so asking associate and store security
      levels per page in hardware is likely more than the TLB can handle.

So, if we hope to have a truly high security operating system in our
lifetimes, then one of several things will have to happen:

    * Intel and/or AMD reinstate segmentation support in x86-64.
    * Intel and/or AMD introduce a fancy paging hardware system that
      supports multiple security levels per page, *and* a secure kernel
      is developed that takes advantage of these page security levels to
      give us highly secure memory access control.
    * Someone develops a security kernel that effectively fakes
      segmentation in software using conventional pages, *and* they get
      it evaluated up to EAL7.

None of which seem likely.

So, I suspect that my career path of providing retro-fit security for
fundamentally insecure systems like C (StackGuard) and the UNIX family
(AppArmor) might have some legs to it :)

Crispin

Peter G. Neumann wrote:
> Der Mouse is barking up the right rathole.
>
> *** BEGIN SOAPBOX ***
>
> Having cut my security eye-teeth in Multics from 1965 to 1969, I am
> continually drawn back into discussions of what Multics did right that
> has been systematically (!) ignored by almost all subsequent operating
> systems.  For the younger folks among the SC-L audience, let me mention
> a few of the architectural strengths.  There were no buffer overflows in
> the stack, because anything out of the stack frame was not executable.
> The ring-structured domain architecture and file system access controls
> permitted straightforward sandboxing.  Dynamic linking and revocation
> were fundamental.  Segmentation and paging enabled layers of virtual
> machines and protected virtual memory.  The I/O system had virtual
> stream names, virtual I/O, and common device-driver software where
> appropriate, coupled with separate hardware for the input-output
> controller (GIOC).  The programming language was the stark EPL subset of
> PL/I and the corresponding McIlroy-Morris EPL compiler, which seems to
> have avoided some of the characteristic programming errors that are
> still common today.  No software was written until there was an approved
> specification, with well defined interfaces and exception conditions
> that were explicitly characterized in EPL.  And so on into a visionary
> sense of a future that has been largely lost for may perceived reasons,
> some of which are bogus, some of which are just seriously short-sighted.
>
> *** END SOAPBOX ***
>
> I'm sure this message may generate all sorts of Ifs and Ands and Buts.
> But the Butt we are kicking is our own.
>
> Cheers!  PGN
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>   

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com




From ljknews at mac.com  Tue Apr  4 12:41:28 2006
From: ljknews at mac.com (ljknews)
Date: Tue, 4 Apr 2006 12:41:28 -0400
Subject: [SC-L] Segments, eh Smithers?
In-Reply-To: <44314713.6030208@novell.com>
References: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
	<44314713.6030208@novell.com>
Message-ID: <p05200f0bc05850d149b4@[192.168.1.254]>

At 9:02 AM -0700 4/3/06, Crispin Cowan wrote:

> That second question is actually pretty technically deep. What is so
> different about paged memory systems that makes them harder to secure
> than segmented memory systems? My conjecture: it is the granularity of
> the memory blobs. Consider:
> 
>     * In a segmented system, you have a small number of fairly large
>       memory objects (segments). Segments are hefty enough that they can
>       be of variable size, and also can have security tags describing
>       their security level at multiple levels. So a given segment can be
>       tagged as being security level 1, 2, 3, and so forth, and the TCB
>       need only check the level before granting or denying access.
>     * In a paged system, in contrast, you have a very large number of
>       much smaller memory objects (pages). Pages are simple, even having
>       fixed size. Fixed size wastes memory, but no one cares because the
>       pages are small enough that it doesn't hurt much. Because pages
>       are simple, you cannot tag them with a bunch of different security
>       levels. For that matter, x86 architectures only recently got a
>       (kind-of) ability to distinguish between read and execute
>       permissions per page, so asking associate and store security
>       levels per page in hardware is likely more than the TLB can handle.

I will admit to not knowing much about hardware, but you seem to be
discussing a TCB implemented in software.

Consider the VAX/Alpha/Itanium on which VMS runs.  As a user program
I access pages, but I don't think of them in those terms.  I think of
them as Sections (some are Global) which contain the read-only part
of one shareable image, my own DCL symbols, etc.  Those sections to
which I have access are in my virtual address space protected so I
have that access to which I am entitled.

What is disturbing about that hardware ?  Is it the fact that the
operating system is really setting individual page protections rather
than a whole segment at a time ?

I realize you probably want more levels and compartments, but that
does not seem to me to make the task untenable.  Educate me.
-- 
Larry Kilgallen


From mshines at purdue.edu  Tue Apr  4 13:20:21 2006
From: mshines at purdue.edu (Michael S Hines)
Date: Tue, 4 Apr 2006 13:20:21 -0400
Subject: [SC-L] Segments, eh Smithers?
In-Reply-To: <p05200f0bc05850d149b4@[192.168.1.254]>
Message-ID: <00a101c6580c$0daef720$4fa7d280@OS00009>

Or consider the IBM Mainframe and z/OS Operating Systems - protected memory and paging
together - also privileged programs vs. application programs, also prefetched programs vs
loaded on demand programs.   

Mike Hines
Mainframe Systems Programmer
-----------------------------------
Michael S Hines
mshines at purdue.edu 



From mouse at Rodents.Montreal.QC.CA  Tue Apr  4 13:31:26 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Tue, 4 Apr 2006 13:31:26 -0400 (EDT)
Subject: [SC-L] Segments, eh Smithers?
In-Reply-To: <44314713.6030208@novell.com>
References: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
	<44314713.6030208@novell.com>
Message-ID: <200604041735.NAA13153@Sparkle.Rodents.Montreal.QC.CA>

> So, if we hope to have a truly high security operating system in our
> lifetimes, then one of several things will have to happen:

>     * [...]
>     * [...]
>     * Someone develops a security kernel that effectively fakes
>       segmentation in software using conventional pages, *and* they
>       get it evaluated up to EAL7.

Strictly speaking, you don't need to have it evaluated for it to be
high security.  Evaluation does not give the security; it gives
confidence in the security (or lack thereof, if it flunks).

Okay, okay, </nitpick>....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From BlueBoar at thievco.com  Tue Apr  4 13:48:09 2006
From: BlueBoar at thievco.com (Blue Boar)
Date: Tue, 04 Apr 2006 10:48:09 -0700
Subject: [SC-L] Segments, eh Smithers?
In-Reply-To: <44314713.6030208@novell.com>
References: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
	<44314713.6030208@novell.com>
Message-ID: <4432B159.4030406@thievco.com>

Crispin Cowan wrote:
> Of particular and critical interest at this juncture is segmented
> memory. Graybeards love segmented memory, and modern Linux kidz hate
> segmented memory. A close friend has observed to me that 100% of A1
> evaluated operating systems (both of them :) used segmented memory. In
> stark contrast, all modern operating systems use paged memory instead.
> Apparently there was a movement to hack segments into the Linux kernel a
> year or so ago, but it was quickly shouted down.

... What?

I thought I had the right x86 brain-damage, and knew what segments were. 
  But it doesn't sound like what you are describing.  My memory of 
segments has to do with a painful way to address 64K at a time on 16-bit 
DOS.  As opposed to a nice flat 32-bit (or more) address space.

Are you proposing that were I to access a memory address with DS: that I 
get one set of privs, and if I used ESI: I get a different set?

And what does that have to do with paging, which I thought had to do 
with mapping between physical and logical memory?

I'm not trying to flame you Crispin, I'd be willing to bet money that 
I'm the one who knows less in this area.  But I don't think you're 
explaining what you are getting at well.  Please spell it out for me.

						BB


From karger at watson.ibm.com  Tue Apr  4 13:39:24 2006
From: karger at watson.ibm.com (karger at watson.ibm.com)
Date: Tue, 04 Apr 2006 13:39:24 -0400
Subject: [SC-L] Segments, eh Smithers?
Message-ID: <20060404173924.498F136E63C@gsal-1.watson.ibm.com>


My comments are interleaved below:

Crispin Cowan writes:
>

>
>PGN cites many of the things that Multics did right and history did not
>follow. Most of these issues are sufficiently entrenched in legacy
>hardware and software that there is little chance to change them any
>time soon.
>
>Of particular and critical interest at this juncture is segmented
>memory. Graybeards love segmented memory, and modern Linux kidz hate
>segmented memory. A close friend has observed to me that 100% of A1
>evaluated operating systems (both of them :) used segmented memory. In
>stark contrast, all modern operating systems use paged memory instead.
>Apparently there was a movement to hack segments into the Linux kernel a
>year or so ago, but it was quickly shouted down.
>
>Even if we could convince kernel developers to try segments, the only
>hardware architectures left that still support segmented memory (x86)
>are about to go extinct. x86-64 offerings from Intel and AMD have
>removed the segmented memory functionality from the instruction set, and
>they have no plans to put it back. Why should they, if approximately
>zero operating systems will use the facility. Conversely, why should OS
>developers muck about with segmentation if hardware supporting it is
>about to become extinct? A classic chicken/egg problem in reverse, where
>it is possible to do now, but about to die out because no one cares.
>
>This leads me to 2 questions:
>
>   1. Is it remotely possible to start a ground-swell of interest in
>      segmentation, get keen software running on x86 CPUs, and do it
>      soon enough to interest Intel or AMD in re-enabling segmentation
>      support in their future x86-64 CPUs?

Actually, there are still current processors that have segments.
The IBM zSeries and iSeries both have segments, and iSeries actually
uses them.   For those not up on the latest IBM trademarks, zSeries
is the latest incarnation of the old 360/370 series mainframes, and iSeries
used to be called System/38 and then AS/400.  Also, Unisys still sells
systems that are descendents of the old B5000/B6700 legacy.

>   2. If the answer to 1 is "no", then is it possible to build a kernel
>      that offers the A1/EAL7 assurance of something like a Multics
>      kernel, does it with pages instead of segments?
>

The DEC A1-secure virtual machine monitor was building an A1 system on the
VAX which had no segments.  It is certainly possible, although it is 
harder.

>That second question is actually pretty technically deep. What is so
>different about paged memory systems that makes them harder to secure
>than segmented memory systems? My conjecture: it is the granularity of
>the memory blobs. Consider:
>
>    * In a segmented system, you have a small number of fairly large
>      memory objects (segments). Segments are hefty enough that they can
>      be of variable size, and also can have security tags describing
>      their security level at multiple levels. So a given segment can be
>      tagged as being security level 1, 2, 3, and so forth, and the TCB
>      need only check the level before granting or denying access.
>    * In a paged system, in contrast, you have a very large number of
>      much smaller memory objects (pages). Pages are simple, even having
>      fixed size. Fixed size wastes memory, but no one cares because the
>      pages are small enough that it doesn't hurt much. Because pages
>      are simple, you cannot tag them with a bunch of different security
>      levels. For that matter, x86 architectures only recently got a
>      (kind-of) ability to distinguish between read and execute
>      permissions per page, so asking associate and store security
>      levels per page in hardware is likely more than the TLB can handle.
>

Actually, the real benefit of segments is not the granularity so much
as the isolation.  The Alpha chip had separate read, write, and
execute permission bits for every page table entry, and that was NOT a
problem for the TLB.  It was just the VAX and the x86 that had
short-sightedly omitted an execute permission bit.  Most other virtual
memory processors had all three.  It is just unfortunate that the two
architectures that didn't became extremely popular, compared to all of
the others.

Where segmentation really helps is that you have a variable length
structure that you cannot address off the end.  If you quote a segment
offset that is bigger than the maximum size of the segment, you either
get an immediate addressing error, or the address wraps around within
the segment.  On the Burroughs B6700, you got the addressing error.
On Multics, the address wrapped around within the same segment.  In
either case, a bad segment offset could NOT cause you to reference a
different protected object.

On the DEC A1-secure VMM, we put guard pages around objects, but that
is NOT sufficient.  A reference that goes way beyond the guard page
would still work.  The zSeries (360/370) segments have the same
problem.  You can address off the end of one segment and into another
segment.  That was not possible on the Multics processors.  The result
is that you have work harder to avoid buffer overflows, either on a
purely paged machine or on a segmented machine that allows flowing
into another segment.  By contrast, it was not possible to reference
beyond the end of a B6700 or Multics segment.  The hardware would stop
you.

>So, if we hope to have a truly high security operating system in our
>lifetimes, then one of several things will have to happen:
>
>    * Intel and/or AMD reinstate segmentation support in x86-64.
>    * Intel and/or AMD introduce a fancy paging hardware system that
>      supports multiple security levels per page, *and* a secure kernel
>      is developed that takes advantage of these page security levels to
>      give us highly secure memory access control.

The odds of segments coming back in Intel or AMD are VERY small.

>    * Someone develops a security kernel that effectively fakes
>      segmentation in software using conventional pages, *and* they get
>      it evaluated up to EAL7.
>

Doing a high assurance security kernel without hard segment boundaries
is definitely possible.  It is just harder.  The DEC VMM was one such
system.  KVM/370 was another.  SCOMP and the PDP-11/45 also had segments
that you address off the end and into another segment.  They both had
high assurance systems built for them.

>None of which seem likely.
>
>So, I suspect that my career path of providing retro-fit security for
>fundamentally insecure systems like C (StackGuard) and the UNIX family
>(AppArmor) might have some legs to it :)
>

Getting rid of C seems even less likely than bringing segments back.

>Crispin
>
>Peter G. Neumann wrote:
>> Der Mouse is barking up the right rathole.
>>
>> *** BEGIN SOAPBOX ***
>>
>> Having cut my security eye-teeth in Multics from 1965 to 1969, I am
>> continually drawn back into discussions of what Multics did right that
>> has been systematically (!) ignored by almost all subsequent operating
>> systems.  For the younger folks among the SC-L audience, let me mention
>> a few of the architectural strengths.  There were no buffer overflows in
>> the stack, because anything out of the stack frame was not executable.
>> The ring-structured domain architecture and file system access controls
>> permitted straightforward sandboxing.  Dynamic linking and revocation
>> were fundamental.  Segmentation and paging enabled layers of virtual
>> machines and protected virtual memory.  The I/O system had virtual
>> stream names, virtual I/O, and common device-driver software where
>> appropriate, coupled with separate hardware for the input-output
>> controller (GIOC).  The programming language was the stark EPL subset of
>> PL/I and the corresponding McIlroy-Morris EPL compiler, which seems to
>> have avoided some of the characteristic programming errors that are
>> still common today.  No software was written until there was an approved
>> specification, with well defined interfaces and exception conditions
>> that were explicitly characterized in EPL.  And so on into a visionary
>> sense of a future that has been largely lost for may perceived reasons,
>> some of which are bogus, some of which are just seriously short-sighted.
>>
>> *** END SOAPBOX ***
>>
>> I'm sure this message may generate all sorts of Ifs and Ands and Buts.
>> But the Butt we are kicking is our own.
>>
>> Cheers!  PGN
>> _______________________________________________
>> Secure Coding mailing list (SC-L)
>> SC-L at securecoding.org
>> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
>> List charter available at - http://www.securecoding.org/list/charter.php
>>   
>
>-- 
>Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
>Director of Software Engineering, Novell  http://novell.com
>
>
>
>
>------------------------------
>
>_______________________________________________
>SC-L mailing list
>SC-L at securecoding.org
>http://krvw.com/mailman/listinfo/sc-l
>
>
>End of SC-L Digest, Vol 2, Issue 52
>***********************************



From smb at cs.columbia.edu  Tue Apr  4 14:19:48 2006
From: smb at cs.columbia.edu (Steven M. Bellovin)
Date: Tue, 4 Apr 2006 14:19:48 -0400
Subject: [SC-L] Segments, eh Smithers?
In-Reply-To: <44314713.6030208@novell.com>
References: <CMM.0.90.4.1143656232.neumann@chiron.csl.sri.com>
	<44314713.6030208@novell.com>
Message-ID: <20060404141948.f7aa6944.smb@cs.columbia.edu>

On Mon, 03 Apr 2006 09:02:27 -0700, Crispin Cowan <crispin at novell.com>
wrote:

> 
> Of particular and critical interest at this juncture is segmented
> memory. Graybeards love segmented memory, and modern Linux kidz hate
> segmented memory. A close friend has observed to me that 100% of A1
> evaluated operating systems (both of them :) used segmented memory. In
> stark contrast, all modern operating systems use paged memory instead.
> Apparently there was a movement to hack segments into the Linux kernel a
> year or so ago, but it was quickly shouted down.
> 
I'll respond more later to the rest of your post, but this merits
comments now.

First, segmentation and paging are not mutually exclusive.  Multics
itself used both; I believe that Pentiums are also capable of both.

Second, the two concepts serve different purposes.  Segments are a
user-visible concept (and the key point is that the hardware address
arithmetic does not have a carry between the high-order bit of the
offset into the low-order bit of the segment number); paging is
(mostly) invisbible to the user and primarily is used to (apparently)
expand physical RAM.

The problem with segmentation, though, is that it does limit the (easy)
size of an object.  Think back to the 286, when segments are much
smaller.  64-bit machines are a great place to use segments, though,
since it's (probably) at least 10 years before we run into the problem
again...

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb


From smb at cs.columbia.edu  Tue Apr  4 14:27:07 2006
From: smb at cs.columbia.edu (Steven M. Bellovin)
Date: Tue, 4 Apr 2006 14:27:07 -0400
Subject: [SC-L] advice from the past
Message-ID: <20060404142707.633e4d4e.smb@cs.columbia.edu>

While preparing a lecture for my OS class, I stumbled on this essay by
Peter Neumann: http://www.multicians.org/pgn-motherhood.html
This is advice very much worth heeding, more than 35 years later.  I
think very few people remember this paper, which of course is one point
it made: "We don't read. Very few system developers are familiar with
work done outside of their own project."

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb


From alekc at avet.com.pl  Tue Apr  4 18:20:01 2006
From: alekc at avet.com.pl (Aleksander P. Czarnowski)
Date: Wed, 5 Apr 2006 00:20:01 +0200
Subject: [SC-L] Segments, eh Smithers?
In-Reply-To: <44314713.6030208@novell.com>
Message-ID: <008d01c65835$ead00490$0202fea9@alektm>

Some quick thoughts on this subject regarding x86 architecture:

- I think we need to define better the term segment, because you also have
selectors in case of flat mode 
- secondly you can provide some protection mechanism using not only rings
but also memory pages and descriptor check, page directory check and page
check itself
- it's not only the problem of protecting memory areas but also what is a
privilege instruction - for example sidt or sldt opcodes used today for
identifying VMWare-alike environments
- accessing other ranges of memory like I/O ports 

Just my 2 cents...
Regards,
Alex Czarnowski
AVET INS



From ken at krvw.com  Wed Apr  5 11:33:10 2006
From: ken at krvw.com (Kenneth R. van Wyk)
Date: Wed, 5 Apr 2006 11:33:10 -0400 (EDT)
Subject: [SC-L] Underhanded C contest
Message-ID: <3644.128.237.235.67.1144251190.squirrel@mail.krvw.com>

Those interested in static source analysis (with or without tools) may be interested in the
2006 "Underhanded C Contest".  Details are available at http://www.brainhz.com/underhanded/

Sigh...

Cheers,

Ken
-- 
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




From ken at krvw.com  Wed Apr  5 12:11:25 2006
From: ken at krvw.com (Kenneth R. van Wyk)
Date: Wed, 5 Apr 2006 12:11:25 -0400 (EDT)
Subject: [SC-L] AJAX: Is your application secure enough?
Message-ID: <3756.128.237.235.67.1144253485.squirrel@mail.krvw.com>

Another interesting paper passing through slashdot today is "AJAX: Is your application
secure enough?"  You can find it at
http://www.darknet.org.uk/2006/04/ajax-is-your-application-secure-enough/

Looks to me like an interesting read, fwiw.  Much as I like the interactiveness that AJAX
brings to the game, I can't help but think that there's tons of room for major security
mistakes to be made, if only due to the complexity of knowing what's going on at each tier
of the app all the time.

Cheers,

Ken
-- 
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




From crispin at novell.com  Wed Apr  5 00:59:23 2006
From: crispin at novell.com (Crispin Cowan)
Date: Tue, 04 Apr 2006 21:59:23 -0700
Subject: [SC-L] Re: [Owasp-dotnet] RE: 4 Questions: Latest IE
	vulnerability, Firefox vs IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code
In-Reply-To: <C056ACAC.1164C%pmeunier@cerias.purdue.edu>
References: <C056ACAC.1164C%pmeunier@cerias.purdue.edu>
Message-ID: <44334EAB.2000809@novell.com>

Pascal Meunier wrote:
> AppArmor sounds like an excellent alternative to creating a VMWare image for
> every application you want to run but distrust, although I can think of
> cases where a VMWare image would be safer.  For example, the
> installer/uninstaller may have vulnerabilities, may be "dirty" (it causes
> problems by modifying things that affect other applications, or doesn't
> cleanup correctly), or phones home, etc...  I guess you could make a profile
> for the installer as well (I'm not very enthusiastic about that idea
> though).  Also, I suspect that what you need to allow in some profiles is
> possibly sufficient to enable "some level" of malicious activity.  It's
> regrettable that it is only available for Suse Linux.
>   
That is correct. AppArmor is not a virtualization layer, and cannot be
used to create virtual copies of files for maybe-good/maybe-bad software
to mess with. More over, the LSM interface in the kernel (which both
AppArmor and SELinux depend on) is also not capable of virtualization.
There were requests for virtualization features during the LSM design
phase, but we decided that we wanted to keep LSM as unintrusive as
possible so as to maximize the chance of LSM being accepted by the 
upstream kernel.

> Perhaps one of the AppArmor mailing lists would be more appropriate to ask
> this,
apparmor-dev cc'd

>  but as you posted an example profile with "capability setuid", I must
> admit I am curious as to why an email client needs that.
Well now that is a very good question, but it has nothing to do with
AppArmor. The AppArmor learning mode just records the actions that the
application performs. With or without AppArmor, the Thunderbird mail
client is using cap_setuid. AppArmor gives you the opportunity to *deny*
that capability, so you can try blocking it and find out. But for
documentation on why Thunderbird needs it, you would have to look at
mozilla.org not the AppArmor pages.

>   I tried looking up
> relevant documentation on the Novell site, but it seems I was unlucky and
> tried during a maintenance period because pages were loading erratically.  I
> finally got to the "3.0 Building Novell AppArmor Profiles" page but it was
> empty.  I would appreciate receiving more information about it.  I am also
> interested in the "Linux Security Modules Interface".
>   
For an overview, look here:

    "Linux Security Modules: General Security Support for the Linux
    Kernel". Chris Wright, Crispin Cowan, Stephen Smalley, James Morris,
    and Greg Kroah-Hartman. Presented at the 11^th USENIX Security
    Symposium <http://www.usenix.org/events/sec02/>, San Francisco, CA,
    August 2002. PDF <http://crispincowan.com/%7Ecrispin/lsm-usenix02.pdf>.

However, this paper is only a general overview, and is now far out of
date. For an accurate view, look at the kernel source code.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com




From everhart at gce.com  Wed Apr  5 22:34:08 2006
From: everhart at gce.com (Glenn Everhart)
Date: Wed, 05 Apr 2006 19:34:08 -0700
Subject: [SC-L] Some different ways to authenticate people
Message-ID: <44347E20.60605@gce.com>

Some authentication ideas I have come up with may bear mention
given all the attention problems of authenticating folks remotely
have been getting.

Let us suppose to introduce the ideas that we have some token we give
folks such that it displays a number sequence (that may vary with time 
or with uses, in the latter case being tracked) and such that an 
authenticating agency can tell what it will display. Let us suppose 
further that (seeing we don't want to be total fools) each such token 
has an identifying number visible to users, but generates a different 
number sequence from any other token. (This can be done easily by just 
having an internal counter encrypted with a key, and using a different 
key for every device. The authenticating agency needs to know the keys 
but nobody else does.)

This is pretty common stuff. After all, SecureID has been around for 
years, and ciphers - of - the - day have been around for centuries.

However it can be used for more than has been common.

If we want an authenticating agency to prove its identity to the token
holder, how about having the token holder report half the display and
have the agency then tell the holder the other half?

To prove that a known person is present, and not just that the token is
present, it has been customary to have the person transmit a PIN and 
ALSO the display value. For people who like to type a lot this is ok, 
but lots of systems only have room to send back 3 or 4 digits, and if a 
PIN is entered in plaintext, webcams, keyloggers, or other agents can 
then capture the PIN.

There's a better way.

Let's suppose your display looks like this (forgive ASCII art):

           +---+---+---+---+---+---+---+
           | 7 | 5 | 2 | 9 | 1 | 0 | 3 |
           +---+---+---+---+---+---+---+
             a   b   c   d   e   f   g

             01  23  45  67  89

where the part in the boxes is the number. (I have drawn it with no 
repeated digits for clarity.)

Now we can ask the person, ahead of time, to pick 3 positions of the 
display (he can use 3 letters to remember if he likes). This is like 
getting into your car door these days, but simpler. (Car doors often ask 
for 5 numbers.)

Suppose the person's pattern is "feb". (Can be anything, but some will 
choose to spell things. It'd be OK to print the whole alphabet, a few 
letters to a digit, if we wanted a larger selection.)

Now to identify himself and his token, a person would get the token to 
generate a number, then pick out the digits at the positions he 
selected. In the above example that would be digits 0 1 5.

Note that because the display changes every time, the chosen digits 
change every time, yet they authenticate the user and the token together 
at a stroke, and are hard to capture because the token is not connected 
to anything, and mostly won't be in range of a webcam or other spy 
gadget. Notice too that giving this information is a conscious act, not 
something a chip can be fooled into doing.

Finally, where a transaction is used, and it is desired to get a 
person's OK to spend, say, $539 on something, he could be asked to 
please pick the positions above the little digits corresponding to 539 
on his display. In the picture above, that would be the "45", the "23", 
and the "89" positions, and if the display read as shown the customer 
could key in "251" to give his OK. (This would be most important for 
large purchases and in internet type settings.)

Now this would give better authentication than we now get, without 
changing payment networks. (Credit/debit card authentication codes are 3 
digits long, for example. I'd rather use something like this than a 
fixed PIN where a PIN was needed, too.)

However there's a cheaper way to use these same schemes. Instead of 
sending out tokens (which would be considered "unproven"), if you are an 
authenticating agency you can send out "bingo cards". These would be 
printed with each one different and having again some serial number.

Suppose I try again to draw a crude one. There are more variants here,
since at each intersection can be long or short numbers. For 
illustration let me presume that at each intersection there is another 7 
digit number like the putative token display above. So the card might 
start like:



          a        b        c        d        e        f        g
      1  3265891  5276903  4437921  0513277  7902168  3180245  7421056
      2  6387009  8711244  5037837  9091234  1234567  0987654  7634216


     ... and so on.

A real card would have a lot of these printed.

Now when the authenticator wants to prove to you who he is, you send the 
coordinates (row and column) and he can tell you the number there.

For you to authenticate yourself you can again pick a pattern to select 
out of any display, and the authenticator can give you the coordinates 
to use. You then pick out your pattern of 3 or 4 positions and report 
the digits there, using the number on the bingo card. (If your pattern 
were as above, the 6th, 5th, and 2nd digits, and you had to report using 
the number on your card at d2 above (which is 9091234 above), you'd pick 
  3 2 0 and report "320".)

It is possible of course to scratch off a number and just use that, 
reporting your pattern, if it is hard to transmit a coordinate to use. 
The authenticator would be able to track what you used. This kind of 
thing is most useful for network authentication though where some added 
communication is easy.

If you were asked to approve an amount string or the like with a bingo 
card, I would suspect it easiest if you got prompted first with a 
picture of what digit positions to pick out and with a coordinate.  You 
would be able to see the digit pattern if you wanted to check that it 
was reasonable but someone who did not have your card, and had not 
authenticated himself with your pattern moments before, would not get 
that far with the transaction.

Variants of using the number could be used to check payee names if the 
need should arise.

The beauty of schemes like this, while they are a little more effort 
than some, is they need only simple devices and rely on the fact that 
the devices are not connected to any tappable things, and that people 
are pretty good at remembering simple patterns. This would after all be 
much easier than getting into your car, and would be used often enough 
not to be a problem to recall. (If you have several of them, and use the 
same position pattern for all of them, it's no big deal: the random 
display kinda/sorta encrypts the transmission for you so it is really 
hard to intercept.)

If people start stealing inputs because some sites don't authenticate to 
the user or omit the "amount check", it will still be tough to fake a 
site that does the above stuff. (Obviously the initial pattern needs to 
be transmitted separately from the bingo card or token.)

An authentication scheme that people will use ought to be voluntary and 
conscious like this, moreover. Fingerprints can be stolen in 10 seconds 
with tape, and in general biometrics must be kept un-stolen for ~100 
years...a long time once every 7-11 clerk can get to them. RFID might be 
read without your knowledge (much less consent). This is a little more 
like the old signet rings barons and kings used to use...you know you 
are using it, and for what. Also it is possible to have several of them 
pretty easily if you must, each authenticating your relationship to one 
authenticator. In effect multiple such authenticators could act like a 
"web of trust" where you show "I am a customer of x bank, y bank, z 
company, and a member of r and s clubs" if you need to use more than 
one, and that might very well be plenty to convince merchant W to grant 
you credit.

Glenn C. Everhart
everhart at gce.com


From dinis at ddplus.net  Thu Apr  6 08:51:26 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 06 Apr 2006 13:51:26 +0100
Subject: [SC-L] 4 Questions: Latest IE vulnerability,
	Firefox vs IE	security, User vs Admin risk profile,
	and browsers coded in 100% Managed	Verifiable code
In-Reply-To: <p05200f3bc04afb382293@[192.168.1.254]>
References: <44252BE7.9040603@ddplus.net>
	<p05200f3bc04afb382293@[192.168.1.254]>
Message-ID: <44350ECE.8020602@ddplus.net>

Comment inline,

ljknews wrote:
> At 11:39 AM +0000 3/25/06, Dinis Cruz wrote:
>   
>> 3) Since my assets as a user exist in user land, isn't the risk profile
>> of malicious unmanaged code (deployed via IE/Firefox) roughly the same
>> if I am running as a 'low privileged' user or as administrator? (at the
>>     
>
> If the administrator's assets are compromised, all users of the system
> will have their assets compromised.
>   
Sure, but if the main assets exist within that user's space, then the
risk is similar. 

Look at your own computer, even if you use a non-admin account (like I
am doing at the moment in my PowerBook G4), if a malicious attacker is
after your assets (email, VPNs, documents, Credit Card details, access
to your online banking accounts,  attack other computers on your local
network, etc...) then he can do all that from user-land (there is no
need for admin privileges)
>> end of the day, in both cases the malicious code will still be able to:
>> access my files, access all websites that I have stored credentials in
>> my browser (cookies or username / passwords pairs), access my VPNs,
>>     
>
> Certainly users should not store credentials in software on a computer.
>   
Ok, but this is impossible today (at least in Windows). In a normal user
session, you will have credentials (or equivalent) in multiple user-land
processes. From login accounts used in your Browser to valid Kerberous
tickets (or more to the point, valid windows security handles (i.e.
tokens) which are as good as a stored credentials).

The bottom line is, if your browser can do it, so can malicious code
executed via your browser.
>> attack other computers on the local network, install key loggers,
>>     
>
> If one is not the administrator, there should be no way to install
> software.  If there is, the operating system is underprotected.
>   
Who said that? I might not be able to put it in under the 'Program
files' folder, add files to the windows directory or write to some
sections of the registry. But since you can run executables, you can
perform all sorts of malicious actions.

A good example are .Net applications which can be executed with no
installation.
>> establish two way communication with a Internet based boot net, etc ...
>>     
>
> At least one aspect of that is a design defect in TCP/IP, allowing
> unprivileged users to create a port to receive inbound connections.
> Other networking protocols avoid that flaw.
>   
This is not a design flaw with TCP/IP, the problem here is that the OS
and the run-time-Sandbox (if there is one) are allowing this to occur.

Remember that if I can talk HTTP with an external computer (located
somewhere in the Internet), then I can use it to establish a two
communication channel.

Can you really defend that all applications that are executed in our
computers (from winzip upwards) should be able to connect to the
internal, download code and execute it with the privileges of the logged
in user?

Because that is what they can do today (if that computer is connected to
the Internet :)

Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060406/6b9e466c/attachment.html 

From dinis at ddplus.net  Thu Apr  6 08:57:30 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 06 Apr 2006 13:57:30 +0100
Subject: [SC-L] 4 Questions: Latest IE vulnerability,
	Firefox vs IE	security, User vs Admin risk profile,
	and browsers coded in 100% Managed	Verifiable code
In-Reply-To: <200603270824.DAA09788@Sparkle.Rodents.Montreal.QC.CA>
References: <44252BE7.9040603@ddplus.net>	<p05200f3bc04afb382293@[192.168.1.254]>
	<200603270824.DAA09788@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <4435103A.5090309@ddplus.net>

der Mouse wrote:
>> At least one aspect of that is a design defect in TCP/IP, allowing
>> unprivileged users to create a port to receive inbound connections.
>>     
>
> I don't think it's fair to call that any kind of defect in TCP/IP.
>   
I agree
> There is nothing at all in TCP or IP that says anything whatsoever
> about what privilege may or may not be necessary to establish a listen
> for incoming connections.  If you must call this a flaw, at least place
> the "flaw" where it actually is - in the implementation(s).
>   
I am not sure that the problem is in the implementation either. From my
point of view, the problem is in allowing malicious applications (or
code) to have access to it in the first place.

If an application is a File Compression utility, then there is no reason
why it should have access to the TCP stack. And if they do need access
to it (for example to check for updates), then those exceptions should
be very well controlled and monitored.
> I'm also not convinced it's a flaw at all; calling it one sounds to me
> like viewing a TCP stack designed for one environment from the point of
> view of a drastically different environment.  In the environment most
> current TCP stacks were designed for, listening for connections on a
> "high" port should not be a restricted operation.  In calling that a
> defect, you appear to be looking on it from a point of view which
> disagrees with that, which actually means just that you've picked the
> wrong TCP stack for your environment, not that there's anything wrong
> with the stack for its design environment.
>   
If this was doable (creating custom TCP Stacks) and practical, maybe
that would be an alternative (since there is no better security
countermeasure, than the one that removes the 'exploitable' target)


Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060406/2755cf1b/attachment.html 

From dinis at ddplus.net  Thu Apr  6 09:34:08 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 06 Apr 2006 14:34:08 +0100
Subject: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, Uservs Admin risk profile, and browsers coded in
	100% Managed Verifiable code
In-Reply-To: <006a01c652ba$00194a90$6401a8c0@agi.alexandergroupinc.com>
References: <006a01c652ba$00194a90$6401a8c0@agi.alexandergroupinc.com>
Message-ID: <443518D0.9020900@ddplus.net>

Eric Swanson wrote:
>
> > What we need now is focus, energy and commitment to create a business
> environment where it is possible (and profitable) the creation,
> deployment and maintenance of applications executed in secure sandboxes.
>
>  
>
> Traditionally, the quickest answer to a need like this is terrorism of
> some kind to get people to "wake up" to imminent threats.  But, since
> we're in the business of only helping and not hurting...
>
true, but the issue here is that the solution for this problem is not
simple and will take a huge amount of effort and focus from all parties
involved. So the later we start the process the more painful it will be.

We have been lucky so far that the number of attacker(s) with both
intent, technical capability, business-process understanding and
opportunity have been very small. It is still also hard today to make
huge amounts of money with digital assets (for example a data center)
without using extortion or blackmail (I call this the 'monetization of
digital assets')

So what you need to do is ask the question "Will the current rate of
security enhancements that we are doing to our systems will be higher
than the rate of growth in the attacker(s): numbers (as in quantity),
skills, ability to monetize digital assets and opportunity".

If those two lines (the 'security enhancements' and the 'attacker(s)
profile') don't cross (situation we live in today), we are ok. But if
the lines do cross over, then we will have a major crisis in our hands.
>
> How do we motivate management decisions to support developing more
> secure solutions?
>
You make them aware of the 'reality' of the situation, and the
consequences of the technological decisions they make everyday (i.e.
make them aware that the CIA (Confidentiality, Integrity and
Availability) or his/hers IT systems is completely dependent on the
honesty, integrity and non-malicious intent of thousands and thousands
of individuals, organizations and governments.
>
>   It's the same question as motivating better problem definitions,
> code requirements gathering, documentation, refactoring, performance
> optimizations, etc.  Time and budget.  The answer is to have an
> affordable, flexible development process and tools that support these
> motivations.
>
For me (a key part of) the answer is to have an/ '...affordable,
flexible development process and tools that support...' /the creation of
applications which can be executed in secure partial trust environments :)
>
> In .NET, code reflection and in-line XML comments coupled with
> formatting tools like "NDoc" made professional code documentation an
> instant option available to every .NET developer, even those on a
> shoe-string budget.
>
Yes, but unfortunately it also made development partially trusted code
very expensive
>
>  
>
> The answer from OWASP might be to re-evaluate development processes
> and develop both sandboxes for clients as well as security patterns,
> components, wizards, and utilities for developers. 
>
We could do that, but we would need much more resources that the ones we
currently have (and until Microsoft joins the party, it will be a
pointless exercise)
>
> We could re-write development processes like the hot topics "Agile
> Development" and "Extreme Programming" to include the SSDL, "Secure
> Software Development Lifecycle".  Perhaps we should be making a better
> business case for the SSDL, like the 2^nd Edition of Code Complete's
> "Utterly Compelling and Foolproof Argument for Doing Prerequisites
> Before Construction" (Print ISBN: 0-7356-1967-0).
>
Agree. I am a big fan of SSDL and believe that it is an integral part of
the environment required to create secure applications
>
> Our guides and vulnerability detection utilities just scratch the
> surface. 
>
Yes, and also (specially the tools) show how little interest there is in
this topic
>
> The utilities in particular do not directly address our concerns for
> motivating the community, except by opening the eyes of the developers
> who actually use them and giving them something fun to play with.
>
even then, most developers and managers don't have the security
experience to understand the implications of the security issues
highlighted by these tools (and when they do, they find that there is no
market for securer apps/hosting environments)
>
> Given the many options that lay ahead of the group, my opinion would
> be to work on better incorporating the SSDL into popular development
> processes and making a clear-cut business case (with statistics) for
> its inclusion.  To motivate participation, we continue to develop the
> utilities, patterns, components, and wizards for developers (both
> before and after the development release cycle).  Perhaps we take the
> online guides, checklists, and utilities and begin to formulate what
> SSDL looks like through OWASP's eyes.
>
That's the plan :)

Very soon we (Owasp) should be making an announcement which will talk
about this

Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060406/0ae87501/attachment.html 

From dinis at ddplus.net  Thu Apr  6 10:48:18 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 06 Apr 2006 15:48:18 +0100
Subject: [SC-L] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, 
	Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable
	code
In-Reply-To: <007501c652bc$1cee0cd0$6401a8c0@agi.alexandergroupinc.com>
References: <007501c652bc$1cee0cd0$6401a8c0@agi.alexandergroupinc.com>
Message-ID: <44352A32.9040304@ddplus.net>

Eric Swanson wrote:
>
> One further question:  Can we ever really advise developers on how to
> develop secure code when the foundations they are developing on top of
> are inherently insecure? 
>
Yes we can, as long as each layer creates/implements a secure sandbox
for the one above it.

So if each layer acts responsibly and creates a securer environment for
one build on top of it, then yes it makes sense to write secure code at
all levels (think 'Defense in Depth', 'Sandboxing', 'Sandbox inside a
Sandbox', privilege isolation, etc...)
>
> If the answer is ultimately no (without re-writing the end-client OS
> or execution framework), we must then consider the question, how can
> we make a good business case for developing secure solutions when,
> ultimately, the secure solution can be compromised?
>
There will always be a way to compromise an asset. Our job is to make
that exploit/attack: very hard to execute, very easy to detect and with
limited damage

This will scale up because the focus will be on creating secure
Sandboxes (i.e. run-time environments) instead of writing code with no
bugs and security vulnerabilities. The first one (Sandboxing) is hard
but doable, the 2nd one (code with no bugs) is probably impossible.
Another benefit will be the separation of responsibility and
accountability: the security consultants will be worried about the
Sandboxes security and the developers will be focused on features and
functionality (the security consultants are paid by the clients, and the
developers paid by the software vendor).

Note that the interfaces between layers (i.e. the APIs exposed by the
Sandbox) reduce the number of possible interconnections between multiple
components, and dramatically simplify the job of identifying normal
behavior (which necessary in order to be able to identify malicious
behavior). Note that I don't think that one will ever be able to
accurately certify that an application written in unmanaged code doesn't
perform a certain malicious activity. But I do believe that it will be
possible to make that assertion about managed and verifiable code
designed to execute in a secure partial trust environment.
>
> Complete security is never the ultimate destination, but rather
> mitigating risk through any acceptable means...
>
Absolutely, but when you have to trust 100% of the executed code, the
'only' mitigation activity that you can do is to prevent malicious code
from being executed in the first place (which is close to impossible in
today's computing environment).

Our current risk mitigation strategy seems to be reliant on the reduced
number of attackers and the large number of assets.

Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060406/898cc376/attachment.html 

From dinis at ddplus.net  Thu Apr  6 11:27:38 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 06 Apr 2006 16:27:38 +0100
Subject: [SC-L] Managed Code and Runtime Environments - Another layer
	of	added security?
In-Reply-To: <003901c65334$3b195ac0$4fa7d280@OS00009>
References: <003901c65334$3b195ac0$4fa7d280@OS00009>
Message-ID: <4435336A.7000103@ddplus.net>

Michael S Hines wrote:
> Which brings us to the point of asking why we must have this run time
> environment to protect the computing resources.  Why isn't this a
> function of and included in the Operating System code?   
We need to have these layers (i.e. more than one) because there are lots
of security decisions that can only be made several layers above the
Operating system.

An OS kernel (like Windows) can easily make a security decision based on
the user identity (either allow or deny access). But that kernel will
have a hard time in making security decisions based on the level of
trust that we have in a particular executable or code (i.e. in creating
Sandboxes which limit the functionality (i.e. permissions) available to
that 'untrusted code').

The .Net Framework CAS (Code Access Security) when used to host
applications that are executed in secure partial trusted environments,
is a good example of an environment capable of securely execute
malicious code.

Eventually, some of the current functionality provided by the .Net CLR
(Common Language Runtime) will have to be moved to the Kernel (for
security and performance reasons)
> Is this like a firewall and IDS - just another layer we have to add
> due to ineffective and insecure OS's?
The insecure OS is the one we have today which allow unmanaged malicious
code to have full access to the user's assets (this applies to Windows,
Linux and Macs).
> Are we dealing with symptoms or the real solution?   
Well I believe that Sandboxing (i.e. secure runtime environments) IS the
solution :)

Microsoft (and most of the Linux and Mac crowd) seems to think that they
can build a secure and trustworthy OS that is able to securely execute
malicious unmanaged.

I (gently) disagree with this opinion, and argue that the desired level
of security (and trustworthiness) can only be achieved via managed
verifiable code.

Dinis Cruz
Owasp .Net Project
www.owasp.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060406/c83e1e19/attachment.html 

From ljknews at mac.com  Thu Apr  6 22:54:51 2006
From: ljknews at mac.com (ljknews)
Date: Thu, 6 Apr 2006 22:54:51 -0400
Subject: [SC-L] 4 Questions: Latest IE vulnerability,  Firefox vs IE
	security, User vs Admin risk profile, and browsers coded in 100% Managed
	Verifiable code
In-Reply-To: <44350ECE.8020602@ddplus.net>
References: <44252BE7.9040603@ddplus.net>
	<p05200f3bc04afb382293@[192.168.1.254]> <44350ECE.8020602@ddplus.net>
Message-ID: <p05200f18c05b840e310e@[192.168.1.254]>

At 1:51 PM +0100 4/6/06, Dinis Cruz wrote:

> ljknews wrote:
>
> At 11:39 AM +0000 3/25/06, Dinis Cruz wrote:
>
>
> 3) Since my assets as a user exist in user land, isn't the risk profile
> of malicious unmanaged code (deployed via IE/Firefox) roughly the same
> if I am running as a 'low privileged' user or as administrator? (at the
>
>
>
> If the administrator's assets are compromised, all users of the system
> will have their assets compromised.
>
>
> Sure, but if the main assets exist within that user's space, then the
>risk is similar. 

No, the only thing at risk is the assets of _that_ user, not the other
users.

> Certainly users should not store credentials in software on a computer.
>
>
> Ok, but this is impossible today (at least in Windows).

Windows ? Is that the operating system whose publisher just said
it is hopeless to clean up after a successful attack ?

> If one is not the administrator, there should be no way to install
> software.  If there is, the operating system is underprotected.
>
>
> Who said that?

William H. Murray of Deloitte and Touche.

>I might not be able to put it in under the 'Program files'
>folder, add files to the windows directory or write to some sections of
>the registry. But since you can run executables, you can perform all sorts
>of malicious actions.

His ideal model is a machine where the users have no ability to execute
a program they introduce to the machine.  There is a strict boundary
between programs and data.

But he is talking about real security, not Windows.
-- 
Larry Kilgallen


From ljknews at mac.com  Thu Apr  6 22:59:13 2006
From: ljknews at mac.com (ljknews)
Date: Thu, 6 Apr 2006 22:59:13 -0400
Subject: [SC-L] 4 Questions: Latest IE vulnerability, 	Firefox vs IE
	security, User vs Admin risk profile, and browsers coded in 100% Managed
	Verifiable code
In-Reply-To: <4435103A.5090309@ddplus.net>
References: <44252BE7.9040603@ddplus.net>
	<p05200f3bc04afb382293@[192.168.1.254]>
	<200603270824.DAA09788@Sparkle.Rodents.Montreal.QC.CA>
	<4435103A.5090309@ddplus.net>
Message-ID: <p05200f19c05b853676cf@[192.168.1.254]>

At 1:57 PM +0100 4/6/06, Dinis Cruz wrote:

>> At least one aspect of that is a design defect in TCP/IP, allowing
>> unprivileged users to create a port to receive inbound connections.

> If an application is a File Compression utility, then there is no reason
>why it should have access to the TCP stack. And if they do need access to
>it (for example to check for updates), then those exceptions should be
>very well controlled and monitored.

The problem then, is how to prevent an unprivileged user from setting up
a File Compression utility to access TCP and establish a port to which
an incoming connection can be made without authentication.

This is back to the issue of which programs can be trusted -- and the
answer to that should be _not_ programs provided by an unprivileged user.
-- 
Larry Kilgallen


From mouse at Rodents.Montreal.QC.CA  Fri Apr  7 12:53:38 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Fri, 7 Apr 2006 12:53:38 -0400 (EDT)
Subject: [SC-L] 4 Questions: Latest IE vulnerability, 	Firefox vs IE
	security, User vs Admin risk profile, and browsers coded in 100% Managed
	Verifiable code
In-Reply-To: <p05200f19c05b853676cf@[192.168.1.254]>
References: <44252BE7.9040603@ddplus.net>
	<p05200f3bc04afb382293@[192.168.1.254]>
	<200603270824.DAA09788@Sparkle.Rodents.Montreal.QC.CA>
	<4435103A.5090309@ddplus.net>
	<p05200f19c05b853676cf@[192.168.1.254]>
Message-ID: <200604071706.NAA07367@Sparkle.Rodents.Montreal.QC.CA>

>> If an application is a File Compression utility, then there is no
>> reason why it should have access to the TCP stack.

> The problem then, is how to prevent an unprivileged user from setting
> up a File Compression utility to access TCP and establish a port to
> which an incoming connection can be made without authentication.

The problem is worse than that.  The problem becomes one of identifying
whether a particular program is something that should or shouldn't have
access to the TCP stack - or, more likely, which of several grades of
access it should have.

For example, on a typical Unix variant, there are no file compression
utilities; there are compression utilities which can be used to
compress files, but which can also be used to, say, take data from a
network connection, compress it, and send it back out that connection
in the other direction.  As such, they need to have access to send and
receive data over established TCP streams.

But then there are programs such as netcat, which to do their job need
to be able to set up listening endpoints and initiate connections.

The problem becomes one of telling the difference.  You need to either
forbid users from running un-vetted executables they provide (whether
locally compiled or not is irrelevant) or you need to trust them to
accurately state what level of access they need to the network.  The
latter is highly error-prone - just look at how many users routinely
run with admin privilege under Windows - and the former will garner
your OS widespread rejection (even if it does gain a sliver of
acceptance from those who (a) understand the security principles
involved and (b) want to run a shop that tight).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From gem at cigital.com  Fri Apr  7 21:42:26 2006
From: gem at cigital.com (Gary McGraw)
Date: Fri, 7 Apr 2006 21:42:26 -0400
Subject: [SC-L] YAI (yet another interview)
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4212DE@va-mail.cigital.com>

Hi all,
 
I finally listened to today's podcast with Jon Udell (infoworld...once Byte).  It's far ranging and intellectually interesting...starting with cognitive science and Letter Spirit (which I worked on with Doug Hofstadter), ranging through type safety, proof carrying code,  and programming languages (sandboxes anyone?), to academic software security.
 
Take a listen.  Feedback would be great.  This sure does demonstrate the difference in rigor and range in podcasts...between the CNN podcast I sent last week and this one you will find an entire world of thought.
 
http://weblog.infoworld.com/udell/2006/04/07.html#a1423 <http://weblog.infoworld.com/udell/2006/04/07.html#a1423> 
 
gem

 
 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Tue Apr 18 15:10:58 2006
From: gem at cigital.com (Gary McGraw)
Date: Tue, 18 Apr 2006 15:10:58 -0400
Subject: [SC-L] IEEE S&P: malware
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB64B95C@va-mail.cigital.com>

Hi all,

Maybe some of you will be interested in participating in this...

gem

========================================================================
====

Special issue of IEEE Security & Privacy magazine
Botnets, spyware, rootkits and assorted malware, September/October 2006

Deadline for submissions: May 31st, 2006

Guest editors: Ivan Arce (ivan.arce-AT-coresecurity.com)

The continuing evolution of security threats and countermeasures
increasingly points at spyware, rootkits, botnets and a myriad of other
software artifacts - loosely defined as "malware"- as the biggest
challenge to achieve socially acceptable levels of security and privacy
in today's IT environments.

The number of reported incidents and criminal activities attributed to
malware is believed to be growing steadily every year clearly signaling
a topic that merits more focused attention and in-depth analysis from
the information security community.

Consequently, the technological, legal and policy-related aspects of
malware are the topic of an upcoming special issue of IEEE Security &
Privacy magazine.

We are looking for feature articles with in-depth coverage of spyware,
botnets, rootkits and other related malware exploring the following
ideas:

* Malware detection, categorization and analysis
* Reverse engineering and static/dynamic binary analysis of spyware,
rootkits and other malware.
* Malware containment and removal.
* Advances in offensive and defensive malware technology
* The global and large scale trends in malware
* Malware economics and metrics
* In-depth research and case-studies of specific rootkits, spyware or
botnet systems.
* Malware-specific computer forensics and incident response
* Malware-specific legal, regulatory and policy considerations

The above list is not complete nor closed, authors are encouraged to
submit articles that explore other aspects of malware.

Submissions are due May 31st, 2006 and will be subject to the
peer-review methodology for refereed papers of the IEEE Security &
Privacy magazine. Submissions will be accepted using the IEEE Computer
Society Manuscript Central site at http://cs-ieee.manuscriptcentral.com

Articles should be understandable to a broad audience of people
interested in computing in science and engineering. The writing should
be down to earth, practical, and original. Authors should avoid theory,
mathematics, jargon, and abstract concepts. They should not assume that
the audience will have specialized experience in a particular subfield.
appearance.

Feature articles normally run from 4 to 12 magazine pages, including all
text, the abstract, keywords, biographies, illustrations, sidebars,
table text, and reference entries. Articles should be between 4,500 to
7,000 words (tables and figures count as 250 words each)

For more information see: http://www.computer.org/mc/security/author.htm

---
"Buy the ticket, take the ride" -HST

Ivan Arce
CTO

CORE SECURITY TECHNOLOGIES
http://www.coresecurity.com

PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836  B25D 207B E78E 2AD1 F65A


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From Ken at krvw.com  Fri Apr 21 08:50:51 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Fri, 21 Apr 2006 08:50:51 -0400
Subject: [SC-L] HNS - A Modular Approach to Data Validation in Web
	Applications
Message-ID: <200604210850.56068@KRvW>

FYI, I saw a paper this morning by Stephen de Vries describing "A Modular 
Approach to Data Validation in Web Applications".  The paper claims that the 
benefits of their approach include:

	"Implementing such a modular approach contributes to the application being
	loosely coupled and ensures that it can safely be extended and components
	reused, without incurring unnecessary development time to re-implement
	validation routines. "

A full abstract and a link to the (PDF format) paper can be found here:

http://www.net-security.org/article.php?id=915

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060421/93e51c19/attachment.bin 

From everhart at gce.com  Wed Apr 26 01:08:51 2006
From: everhart at gce.com (Glenn Everhart)
Date: Tue, 25 Apr 2006 22:08:51 -0700
Subject: [SC-L] Another example of the futility of hardwareless 2 factor
	authentication
Message-ID: <444F0063.7030508@gce.com>

Consider the following attempt at el-cheapo (no hardware) authentication:

It is possible to imagine an authentication scheme that wants to use 
something like a certificate with signing, encrypting random nonces 
etc., to verify that someone agrees to some transaction(s). If the 
certificate is on a PC, though, it gets exposed to theft.

In the cert is a private key. If the system were required to contact a 
"backend" server first, passing it perhaps a cipher containing its
serial number encrypted with its private key and its identity, the 
server could send back a (hopefully unique to that cert) decryption key 
that would decrypt the private key, allowing its use; the code at the PC 
would need to erase the cleartext private key when done. The server 
could check the serial number matched the "identity" (it would have the 
public key) to prevent a simple search of the server for these 
encrypting keys.

This all seems reasonable and deals well with the environment perhaps of 
the 1990s. Problem today is that it is still utterly vulnerable to 
backdoor code on the PC which could be arranged to either listen for the 
decrypting key or just pluck it out of memory while the real cert was 
being used in cleartext.

This is another demo of the difficulty of building any kind of software 
token that can be connected to uncontrolled environments and which can 
keep secrets. It may resist OFFLINE attack, but that is not the primary 
attack threat today for such a beast.

Glenn Everhart
Everhart at gce.com


From mouse at Rodents.Montreal.QC.CA  Wed Apr 26 22:50:14 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Wed, 26 Apr 2006 22:50:14 -0400 (EDT)
Subject: [SC-L] Another example of the futility of hardwareless 2 factor
	authentication
In-Reply-To: <444F0063.7030508@gce.com>
References: <444F0063.7030508@gce.com>
Message-ID: <200604270256.WAA09903@Sparkle.Rodents.Montreal.QC.CA>

> Consider the following attempt at el-cheapo (no hardware)
> authentication:  [...]

> It is possible to imagine an authentication scheme that wants to use
> something like a certificate with signing, encrypting random nonces
> etc., to verify that someone agrees to some transaction(s).  If the
> certificate is on a PC, though, it gets exposed to theft.

There is no way to avoid this (as long as you stick to the no-hardware
restriction).  You can get clever with third parties and whatnot all
you like, but anything the user's desktop can do with the data it has
(possibly including data that is typed in by the user during operation
as intended), an impostor who has the same data (lifted from disk,
snooped on keystrokes, whatever) can do equally well.

To defeat this, in principle, you need *something* the user's computer
does not have access to.  This can be as simple as the next entry on a
list of nonces (sent to the user by some other means such as snailmail)
all the way up to something as complex as the stuff underlying SecurID.

Of course, that's not to say that simpler measures can't defeat any
specific examples, such as current attacks.  You can make it moderately
difficult, in fact.  But you can't make it impossible.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From gem at cigital.com  Mon May  1 13:25:22 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 1 May 2006 13:25:22 -0400
Subject: [SC-L] New security website: darkreading
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE5C4@va-mail.cigital.com>

Hi all,

Some of you may have read some of the monthly [in]security columns I
wrote for IT Architect over the last couple of years (a collection lives
here http://www.cigital.com/resources/gem/).  CMP killed IT Architect
(taking out the [in]security column with it) in March.  Fortunately,
they created a new security website called darkreading that debuts
today.  I have a column there now.

The first iteration discusses Vista and .NET.  Type safety anyone?
http://darkreading.com/document.asp?doc_id=93335&WT.svl=column1_1

gem
www.cigital.com
www.swswc.com


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From rcs at cert.org  Mon May  1 16:36:40 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Mon, 01 May 2006 16:36:40 -0400
Subject: [SC-L] Secure Software Architecture, Design,
 Implementation and Assurance CFP
Message-ID: <44567158.5070409@cert.org>


Secure Software Architecture, Design, Implementation and Assurance
CALL FOR PAPERS

Fortieth Annual Hawai?i International Conference on System Sciences
January 3 - 6, 2007 (Wednesday-Saturday)
Hilton Waikoloa Village Resort and Spa on the Big Island
425 Waikoloa Beach Drive
Waikoloa, Hawaii 96738
Tel: 1-808-886-1234    Fax: 1-808-886-2900
www.hiltonwaikoloavillage.com

HICSS conferences are devoted to advances in the information, computer,
and system sciences, and encompass developments in both theory and
practice.   Papers may be theoretical, conceptual, tutorial or
descriptive in nature.  Submissions undergo a double-blind peer referee
process and those selected for presentation will be published in the
Conference Proceedings.

Additional detail may be found on HICSS primary web site:
http://www.hicss.hawaii.edu
Mirror site   http://www.is.cityu.edu.hk/hicss/

SCOPE
The Secure Software Architecture, Design, Implementation and Assurance
minitrack focuses on the research and automation required to develop
secure software systems that do not compromise other system properties
such as performance or reliability. Current security engineering methods
are demonstrably inadequate, as software vulnerabilities are currently
being discovered at the rate of over 4,000 per year. These
vulnerabilities are caused by software designs and implementations that
do not adequately protect systems and by development practices that do
not focus sufficiently on eliminating implementation defects that result
in security flaws. An opportunity exists for systematic improvement that
can lead to secure software architectures, designs, and implementations.

The following topics are appropriate topics for research papers:
? Static analysis tools and techniques for detecting security flaws and
  software vulnerabilities in source or binary code
? Dynamic analysis tools for detecting security flaws and software
  vulnerabilities in source or binary code
? Model checking tools for detecting security flaws and software
  vulnerabilities in software systems
? Software architectures and designs for securing against
  denial-of-service attacks and other software exploits
? Coding practices for improved security and secure library
  implementations
? Computational security engineering
? Other tools and techniques for reducing or eliminating vulnerabilities
  during development and maintenance

CO-CHAIRS
Sven Dietrich		CERT	 	ssadia at cert.org
Daniel Plakosh		CERT/CC 	ssadia at cert.org
Robert C. Seacord	CERT/CC		ssadia at cert.org

PROGRAM COMMITTEE
Julia Allen 		SEI/CMU
Hal Burch		CERT/CC
Brian Chess		Fortify Software
Bob Fleck		Secure Software
Michael Howard		Microsoft
Derek M. Jones 		Knowledge Software Ltd
Alan Krassowski 	Symantec
Fred Long		University of Wales, Aberystwyth
Tom Longstaff		CERT
Robert Martin		MITRE
Leon Moonen		Delft University of Technology
James W. Moore 		MITRE
Samuel Redwine		James Madison University
David Riley		University of Wisconsin - La Crosse
John Steven		Cigital
Carol Woody 		CERT

IMPORTANT DEADLINES
Abstracts	Authors are encouraged to contact Minitrack Chairs for
guidance and indication of appropriate content.  Manuscripts are not
accepted based on abstracts.  Full manuscripts must be submitted by June
15.

June 15	Authors submit full manuscripts to the Peer Review System,
following Author Instructions found on the HICSS web site
(www.hicss.hawaii.edu). All manuscripts will be submitted in double
column publication format and limited to 10 pages including diagrams and
references. Since manuscripts will undergo a double-blind review, author
names and affiliations must not be included on the original manuscript.
This information will be collected later through the system.

August 15	Acceptance notices are sent to Authors via the Peer Review System.

September 15	Authors submit Final Version of accepted papers following
submission instructions on the Peer Review System web site.  At least
one author of each paper must register by this date with specific plans
to attend the conference to present the paper.  Early Registration fee
applies.  (General Registration fee applies Sept 16-Dec 15.)

December 1	Deadline to guarantee your hotel room reservation at
conference rate.

December 15	  		  Deadline to receive conference registration refund.
Late registration
     	  fee applies.

SUBMISSION INSTRUCTIONS
? HICSS manuscripts must contain original material not previously
published, nor currently submitted elsewhere.
? HICSS will conduct double-blind reviews of each submitted manuscript.
? Consult the conference website (www.hicss.hawaii.edu) for the listing
and description of Minitracks for HICSS-40.
? Contact the Minitrack Chair(s) by email for guidance and verification
of appropriate content. (Optional but strongly encouraged)
? Manuscripts may not be submitted to more than one Minitrack Chair.
(One will be summarily rejected.)   If unsure which Minitrack is
appropriate, submit abstract to the Track Chair for guidance.
? Submit full manuscript according to detailed instructions found on the
Peer Review System website.

CONFERENCE TRACKS
Collaboration Systems
Co-chairs: Robert O. Briggs  bbriggs at GroupSystems.com  Jay Nunamaker
jnunamaker at cmi.arizona.edu
Decision Technologies and Service Sciences
Chair: Dan Dolk   drdolk at nps.edu
Digital Media: Content and Communication
Chair: Michael Shepherd   shepherd at cs.cal.ca
E-Government
Chair: H. Jochen Scholl   jscholl at u.washington.edu
Electric Power Systems
Chair: Robert Thomas   rjt1 at cornell.edu
Information Technology in Health Care
Chair: William Chismar  chismar at hawaii.edu
Internet & the Digital Economy
Co-chairs: David King    david.king at jda.com    Alan Dennis
ardennis at indiana.edu
Knowledge Management Systems
Co-chairs: Murray Jennex   murphjen at aol.com    Dave Croasdell
davec at unr.edu
Organizational Systems & Technology
Chair: Hugh Watson   hwatson at terry.uga.edu
Software Technology
Co-chairs:  Chair: Gul Agha   agha at cs.uiuc.edu   Rick Kazman
kazman at hawaii.edu


CONFERENCE ADMINISTRATION
Ralph Sprague, Conference Chair  		sprague at hawaii.edu
Sandra Laney, Conference Administrator	hicss at hawaii.edu
Eileen Robichaud, Track Administrator	eidennis at indiana.edu

-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC

Work: 412-268-7608
FAX: 412-268-6989


From dinis at ddplus.net  Mon May  1 20:44:13 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Tue, 02 May 2006 01:44:13 +0100
Subject: Vista and the Type Safe missed oportunity (was Re: [SC-L] New security
	website: darkreading )
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE5C4@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE5C4@va-mail.cigital.com>
Message-ID: <4456AB5D.6010804@ddplus.net>

Gary,

The Vista/.Net article 
(http://darkreading.com/document.asp?doc_id=93335&WT.svl=column1_1) is 
an excellent article which I agree 100%. Given the fact that Vista will 
crash and burn (with regards to security), this could prove to be a very 
serious mistake by Microsoft.

What makes this worse is that even in Vista, the migration to to managed 
and verifiable environments will not begin.

If vista was released with an effort to make all .Net apps run in 
partial trust (and real focus in making that work), then at least a 
major paradigm-change would occurred and we would be on the right track. 
But unfortunately, that will not happen, which means a couple more years 
wasted.

I agree with the 10 year opportunity window, and since Microsoft has 
chosen to blow they opportunity in this decade, maybe a new contender 
will appear,  put enough resources and effort behind it, and create an 
operating system on a type-safe platform (Open Source community, are you 
listening?).

A couple comment on your article:

/"... .NET has a built-in security model just like Java. //.NET is type 
safe just as Java is type safe. ..."/
  
This is only correct when .Net is executed under Partial Trust and Java 
with the Security Manager enabled.

In Full Trust .Net or Java with Security Manager disabled, the VM 
verifier is disabled and the built-in security mode is just about useless.

The main security advantage that the current .Net and Java environments 
have, is that they are not as vulnerable to buffer overflows as C/C++

/"... At the moment, it's hard to know what's going to be so great about 
Vista..."/

So far one of the security 'benefits' that Vista claims to bring is the 
ability to run applications as non admin and to add some protection to 
user land processes (see 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp). 


The problem is that these protections might be very effective in 
protecting the computer from Rootkits, but are not effective when the 
attacker is after the user's assets (which are located on user-land)

/"... The problem, it turns out, is that the .NET builders did not give 
much thought to providing many of the essential basic building blocks 
that operating systems construction crews need for their work. ..."/

I also think that the current CLR is not designed for that task. To pull 
this off you will need different types of CLR, and probably even 
different type-safe environments.

Another big problem was the lack of mass adoption of the CLI Standard 
caused probably because Microsoft never released the source code of the 
.Net Framework and decided to provide a 'Proof of Concept' thing called 
Rotor.

The path to a type-safe world is one that Microsoft cannot walk alone. 
It will require a massive amount of effort by all parts of the software 
food-chain. The momentum and energy required for such task will be very 
hard (if not impossible) to generate on top of closed (proprietary) or 
partially-open architectures.

/"... In a type-safe language like Java or .NET, there are more 
guarantees about what is what...."
/
If the verifier is enabled...

/"...//In case of monkey business, the Verifier is around to make sure 
that byte code and CLR plays by the rules of type safety..."/

This statement is not entirely correct because 99% of the .Net and Java 
code that is currently deployed is executed on an environment where the 
VM verifier is disabled,  .

What you can say is that, in principle and if all went well, the code 
produced by (for example) Visual Studio C# and VB compilers is Type Safe.

The real security implications of not running .Net code under a verifier 
are still be to researched and the more I look at it the more I think 
that there will be problems ahead.

/"... Type safety is a necessary, but not sufficient, foundation for 
modern security models like the .NET security model..."/

Absolutely, but unfortunately we don't even have that today (type safety 
code execution)

/"....In fact, if we step into the way-back machine, a number of the 
spectacular Java security holes that I helped to find 10 years ago 
involved screwing around with types using the "type confusion toolkit.".."

/And I put money that similar issues exist on the .Net Framework. In 
fact some of my .Net Type Safety research was done by studying the Java 
research on the subject and applying the exploits to the .Net's CLR :)

/"... the next huge opportunity to cause widespread adoption of 
type-safe systems comes around...."
/
Before this happens, the paradigm into Partially Trusted Applications / 
Sandboxes needs to be made.

/"...Microsoft? How about building the next operating system on a 
type-safe platform?..."

/Good luck, for me I have given up on Microsoft on this issue. I don't 
expect nothing major to occur until Vista's failure to deliver a secure 
and trustworthy computing environment is obvious to everybody.

The ones that I wish were listening are Novel and the Mono project. The 
path to a type-safe platform could start there.

Dinis Cruz
Owasp .Net Project
www.owasp.net

Gary McGraw wrote:
> Hi all,
>
> Some of you may have read some of the monthly [in]security columns I
> wrote for IT Architect over the last couple of years (a collection lives
> here http://www.cigital.com/resources/gem/).  CMP killed IT Architect
> (taking out the [in]security column with it) in March.  Fortunately,
> they created a new security website called darkreading that debuts
> today.  I have a column there now.
>
> The first iteration discusses Vista and .NET.  Type safety anyone?
> http://darkreading.com/document.asp?doc_id=93335&WT.svl=column1_1
>
> gem
> www.cigital.com
> www.swswc.com
>
>
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060502/a759ab9a/attachment.html 

From gwc at acm.org  Mon May  1 23:00:05 2006
From: gwc at acm.org (George Capehart)
Date: Mon, 01 May 2006 23:00:05 -0400
Subject: Vista and the Type Safe missed oportunity (was Re: [SC-L] New
	security	website: darkreading )
In-Reply-To: <4456AB5D.6010804@ddplus.net>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE5C4@va-mail.cigital.com>
	<4456AB5D.6010804@ddplus.net>
Message-ID: <4456CB35.1040509@acm.org>

Dinis Cruz wrote:

<snip introductory comments>

> 
> A couple comment on your article:
> 
> /"... .NET has a built-in security model just like Java. //.NET is type
> safe just as Java is type safe. ..."/
>  
> This is only correct when .Net is executed under Partial Trust and Java
> with the Security Manager enabled.
> 
> In Full Trust .Net or Java with Security Manager disabled, the VM
> verifier is disabled and the built-in security mode is just about useless.
> 
> The main security advantage that the current .Net and Java environments
> have, is that they are not as vulnerable to buffer overflows as C/C++


<snip rest of excellent discussion>

Hola Dinis et al.,

I subscribe to many security-related mailing lists, and I don't remember
on which this one occurred, but, in the past two to three months, there
was a great discussion around Multics and the Multics security model and
implementation.  Now, I'm an old phart, but not quite that old . . .
(Apologies to the Multicians out there . . .  :-)  ).  WRT type safety,
etc., one of the big appeals of Multics was that it was written in PL/I.
Now, I /*am*/ old enough to admit to having learned PL/I in Comp Sci
101, and I actually did productive work with it (when I could get to the
keypunch).  Looking back on it, PL/I protected me (a beginning
programmer) from many errors of omission that I would have made had I
been using C or C++.  In some ways, I think we are back doing the same
thing for which we excoriate others . . . not learning lessons from
those who came before us and reinventing the wheel.  IMHO, WRT operating
systems, there is ample history to guide us on what works and what
doesn't.  (And how to write OSs in HLLs).  Those who elect not to pay
attention to history and who must forge their way into the vast,
uncharted (by them) waters deserve everything they get.  And, FWIW, I'm
surprised that Butler Lampson is still Microsoft . . .

My 0.02$CURRENCY.

Cheers,

/g


From dinis at ddplus.net  Tue May  2 19:48:19 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Wed, 03 May 2006 00:48:19 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java 
Message-ID: <4457EFC3.4090605@ddplus.net>

Here is a more detailed explanation of why (in my previous post) I said: 
/"99% of .Net and Java code that is currently deployed is executed on an 
environment where the VM verifier is disabled,  ."/

------------------

In .Net the verifier (the CLR function that checks for type safety) is 
only enabled on partial trust .Net environments.

For example, in Full Trust .Net you can successfully assign Type A to 
Type B (also called a Type Confusion attack) which clearly breaks type 
safety.

I have done some research on this topic, and on my spare time I was able 
to find several examples of these situations:

    * Possible Type Confusion issue in .Net 1.1 (only works in
      FullTrust)
      (http://owasp.net/blogs/dinis_cruz/archive/2005/11/08/36.aspx)
    * Another Full Trust CLR Verification issue: Exploiting Passing
      Reference Types by Reference
      (http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/393.aspx)
    * Another Full Trust CLR Verification issue: Changing Private Field
      using Proxy Struct
      (http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/394.aspx)
    * Another Full Trust CLR Verification issue: changing the Method
      Parameters order
      (http://owasp.net/blogs/dinis_cruz/archive/2005/12/26/390.aspx)
    * C# readonly modifier is not enforced by the CLR (when in Full
      Trust (http://owasp.net/blogs/dinis_cruz/archive/2005/12/26/390.aspx)
    * Also related:
          o JIT prevents short overflow (and PeVerify doesn't catch it)
            (http://owasp.net/blogs/dinis_cruz/archive/2006/01/10/422.aspx)
               
          o and ANSI/UNICODE bug in System.Net.HttpListenerRequest
            (http://www.owasp.net//blogs/dinis_cruz/archive/2005/12/17/349.aspx)

Here is Microsoft's 'on the record' comment about this lack of 
verification (and enforcement of type safety) on Full Trust code (note: 
I received these comments via the MSRC):
/
"...
Some people have argued that Microsoft should always enforce type safety
at runtime (i.e. run the verifier) even if code is "Fully Trusted".
We've chosen not to do this for a number of reasons (e.g. historical,
perf, etc). There are at least two important things to consider about
this scenario:

1) Even if we tried to enforce type safety using the verifier for Fully
Trusted code, it wouldn't prevent Fully Trusted from accomplishing the
same thing in 100 other different ways. In other words, your example
accessed an object as if it were a different incompatible type - The
verifier could have caught this particular technique that allowed him to
violate type safety. However, he could have accomplished the same
result using private reflection, direct memory access with unsafe code,
or indirectly doing stuff like using PInvoke/native code to disable
verification by modifying the CLR's verification code either on disk or
in memory. There would be a marginal benefit to insuring people wrote
"cleaner" more "type safe" code by enforcing verification at runtime for
Full Trust, but you wouldn't get any additional security benefits
because you can perform unverifiable actions in dozens of ways the
verifier won't prevent if you are Fully Trusted.

2) As mentioned at the end of #1 above, one argument is that it's good
for programmers (even fully trusted ones) to follow type safety rules,
and doing runtime verification would keep people writing cleaner code.
However, we don't need to do the verification at "runtime" in order to
encourage good type safety hygiene. Instead, we can rely on our
languages to do this for us. For example, C# and VB by default ensure
that you produce verifiable code. If you've written your code in a
language like C#, you're not going to run into cases where you've
accidentally created unverifiable code (This can be seen in the example
posted on the blog since you needed to use the low level assembler to
hack up a program initially compiled in C#). Given that you can't
prevent Fully Trusted code from doing unverifiable things at runtime,
there's only a marginal difference between encouraging type safety at
compile time vs at runtime for the Fully Trusted code developer.

I hope that helps to convey the message on where Microsoft stands with
this issue.
..."


/Unfortunately Java is not much better. By default most Java code is 
also executed with -noverify.

Here is a good explanation from this 
(http://lists.grok.org.uk/pipermail/full-disclosure/2006-March/044505.html) 
thread (which I started) :
/
"...
 >> I am not a Java expert, but I think that the Java Verifier is NOT 
 >> used on Apps that
 >> are executed with the Security Manager disabled (which I  believe is 
the default
 >> setting) or are loaded from a local disk (see "...  applets loaded 
via the file system
 >> are not passed through the byte code verifier" in 
http://java.sun.com/sfaq/)

 > I believe that as of Java 1.2, all Java code except the core 
 > libraries must
 > go through the verifier, unless it is specifically disabled (java
 > -noverify).
//
I had the same intuition about the verifier, but have just tested 
this and it is not the case.  It seems that the -noverify is the 
default setting! If you want to verify classes loaded from the local 
filesystem, then you need to explicitly add -verify to the cmd line.  
I tested this by compiling 2 classes where one accesses a public 
member of the other.  Then recompiled the other and changed the 
method access to private.  Tested on:
Jdk 1.4.2 Mac OS X
Jdk 1.5.0 Mac OS X
Jdk 1.5.0 Win XP

all behave the same.

[~/data/dev/applettest/src]java -cp . FullApp
Noone can access me!!
[~/data/dev/applettest/src]java -cp . -verify FullApp
Exception in thread "main" java.lang.IllegalAccessError: tried to 
access field MyData.secret from class FullApp at FullApp.main
(FullApp.java:23)

Using the same code with an Applet loaded from the filesystem throws 
an IllegalAccessError exception as it should.
..."

/Any Comments?

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060503/6779b6d5/attachment.html 

From Kevin.Wall at qwest.com  Tue May  2 20:43:56 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Tue, 2 May 2006 19:43:56 -0500
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java 
Message-ID: <CF8B26B8B49184429CB084616B0019300244E35D@itomae2km05.AD.QINTRA.COM>

[Moderator: Feel free to discard some or all of Dinis' original post
below.
            I wasn't sure how much to trim because I don't know how
            much people have been paying attention to this particular
            discussion and I didn't want them to loose context and have
            to resort to searching the archives.]

It might be nice if the Java VM would / could distinguish betw running
from
a LOCAL disk vs a remote networked disk (NFS, Samba share, etc.) and
enable tye byte code verify automagically for any classes loaded
remotely. That doesn't seem too different (in terms of attack vectors)
of running applets locally using remotely loaded classes.  A similar
thing
might also be done if any jars, zip files, .class files, or the
directories in which they reside were writable by anyone other than
root (or equivalent on Windows, MacOS, etc.) or the user id executing
the Java program.  Of course that's not too likely to be too portable
across the various supported OSes, so perhaps that's why Sun choose
not to do it. Perhaps asking / begging Microsoft to do a similar thing
for .NET assemblies might be an easier sell because they wouldn't face
the OS portability issue (as much).

Dinis: I deliberately did not cross-post to the owasp-dotnet list.
       You can if you wish.

-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com    Phone: 614.215.4788
"The reason you have people breaking into your software all
over the place is because your software sucks..."
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit 

-----Original Message-----
> From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Dinis Cruz
> Sent: Tuesday, May 02, 2006 7:48 PM
> To: 'Secure Coding Mailing List'
> Cc: 'owasp-dotnet at lists.sourceforge.net'
> Subject: [SC-L] By default, the Verifier is disabled on .Net and Java 
> 
> 
> Here is a more detailed explanation of why (in my previous post) I
said: "99% of .Net and Java code that is currently deployed is executed
on an environment where the VM verifier is disabled,  ."
> 
> ------------------
> 
> In .Net the verifier (the CLR function that checks for type safety) is
only enabled on partial trust .Net environments.
> 
> For example, in Full Trust .Net you can successfully assign Type A to
Type B (also called a Type Confusion attack) which clearly breaks type
safety.
> 
> I have done some research on this topic, and on my spare time I was
able to find several examples of these situations:
> 
> 
> Possible Type Confusion issue in .Net 1.1 (only works in FullTrust)
(http://owasp.net/blogs/dinis_cruz/archive/2005/11/08/36.aspx) 
> Another Full Trust CLR Verification issue: Exploiting Passing
Reference Types by Reference
(http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/393.aspx) 
> Another Full Trust CLR Verification issue: Changing Private Field
using Proxy Struct
(http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/394.aspx) 
> Another Full Trust CLR Verification issue: changing the Method
Parameters order
(http://owasp.net/blogs/dinis_cruz/archive/2005/12/26/390.aspx) 
> C# readonly modifier is not enforced by the CLR (when in Full Trust
(http://owasp.net/blogs/dinis_cruz/archive/2005/12/26/390.aspx)
> 
> Also related: 
> 
> JIT prevents short overflow (and PeVerify doesn't catch it)
(http://owasp.net/blogs/dinis_cruz/archive/2006/01/10/422.aspx)     
> 
> and ANSI/UNICODE bug in System.Net.HttpListenerRequest
(http://www.owasp.net//blogs/dinis_cruz/archive/2005/12/17/349.aspx)
> 
> Here is Microsoft's 'on the record' comment about this lack of
verification (and enforcement of type safety) on Full Trust code (note:
I received these comments via the MSRC):
> 
> "...
> Some people have argued that Microsoft should always enforce type
safety
> at runtime (i.e. run the verifier) even if code is "Fully Trusted".
> We've chosen not to do this for a number of reasons (e.g. historical,
> perf, etc). There are at least two important things to consider about
> this scenario:
> 
> 1) Even if we tried to enforce type safety using the verifier for
Fully
> Trusted code, it wouldn't prevent Fully Trusted from accomplishing the
> same thing in 100 other different ways. In other words, your example
> accessed an object as if it were a different incompatible type - The
> verifier could have caught this particular technique that allowed him
to
> violate type safety. However, he could have accomplished the same
> result using private reflection, direct memory access with unsafe
code,
> or indirectly doing stuff like using PInvoke/native code to disable
> verification by modifying the CLR's verification code either on disk
or
> in memory. There would be a marginal benefit to insuring people wrote
> "cleaner" more "type safe" code by enforcing verification at runtime
for
> Full Trust, but you wouldn't get any additional security benefits
> because you can perform unverifiable actions in dozens of ways the
> verifier won't prevent if you are Fully Trusted.
> 
> 2) As mentioned at the end of #1 above, one argument is that it's good
> for programmers (even fully trusted ones) to follow type safety rules,
> and doing runtime verification would keep people writing cleaner code.
> However, we don't need to do the verification at "runtime" in order to
> encourage good type safety hygiene. Instead, we can rely on our
> languages to do this for us. For example, C# and VB by default ensure
> that you produce verifiable code. If you've written your code in a
> language like C#, you're not going to run into cases where you've
> accidentally created unverifiable code (This can be seen in the
example
> posted on the blog since you needed to use the low level assembler to
> hack up a program initially compiled in C#). Given that you can't
> prevent Fully Trusted code from doing unverifiable things at runtime,
> there's only a marginal difference between encouraging type safety at
> compile time vs at runtime for the Fully Trusted code developer.
> 
> I hope that helps to convey the message on where Microsoft stands with
> this issue.
> ..."
> 
> 
> Unfortunately Java is not much better. By default most Java code is
also executed with -noverify.
> 
> Here is a good explanation from this
(http://lists.grok.org.uk/pipermail/full-disclosure/2006-March/044505.ht
ml) thread (which I started) :
> 
> "... 
> >> I am not a Java expert, but I think that the Java Verifier is NOT  
> >> used on Apps that 
> >> are executed with the Security Manager disabled (which I  believe
is the default 
> >> setting) or are loaded from a local disk (see "...  applets loaded
via the file system 
> >> are not passed through the byte code verifier" in
http://java.sun.com/sfaq/)
> 
> > I believe that as of Java 1.2, all Java code except the core  
> > libraries must
> > go through the verifier, unless it is specifically disabled (java
> > -noverify).
> 
> I had the same intuition about the verifier, but have just tested  
> this and it is not the case.  It seems that the -noverify is the  
> default setting! If you want to verify classes loaded from the local  
> filesystem, then you need to explicitly add -verify to the cmd line.

> I tested this by compiling 2 classes where one accesses a public  
> member of the other.  Then recompiled the other and changed the  
> method access to private.  Tested on:
> Jdk 1.4.2 Mac OS X
> Jdk 1.5.0 Mac OS X
> Jdk 1.5.0 Win XP
> 
> all behave the same.
> 
> [~/data/dev/applettest/src]java -cp . FullApp
> Noone can access me!!
> [~/data/dev/applettest/src]java -cp . -verify FullApp
> Exception in thread "main" java.lang.IllegalAccessError: tried to  
> access field MyData.secret from class FullApp at FullApp.main 
> (FullApp.java:23)
> 
> Using the same code with an Applet loaded from the filesystem throws  
> an IllegalAccessError exception as it should.
> ..."
> 
> Any Comments?
> 
> Best regards
> 
> Dinis Cruz
> Owasp .Net Project
> www.owasp.net


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.



From jeff.williams at aspectsecurity.com  Tue May  2 22:56:57 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Tue, 2 May 2006 22:56:57 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java 
In-Reply-To: <4457EFC3.4090605@ddplus.net>
Message-ID: <11f401c66e5d$4084b290$9204a8c0@intranet.aspectsecurity.com>

Two important clarifications for Java (based on my experiments):

 

1) The verifier IS enabled for the classes that come with the Java platform,
such as those in rt.jar.  So, for example, if you create a class that tries
to set System.security (the private variable that points to the
SecurityManager instance), you get a verification exception. (If this was
possible, it would allow a complete bypass of the Java sandbox).

 

2) The verifier also seems to be enabled for classes running inside Tomcat.
I'm not sure about other J2EE containers.

 

So I don't think it's fair to say that most Java code is running without
verification.

 

But Denis is right. There is a real problem with verification, as
demonstrated in the message below.  This is a clear violation of the Java VM
Spec, yet my messages to the team at Sun developing the new verifier have
been ignored.  And it's a real issue, given the number of applications that
rely on libraries they didn't compile.  I don't think a real explanation of
how the Sun verifier actually works is too much to ask, given the risk.

 

--Jeff

 

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Dinis Cruz
Sent: Tuesday, May 02, 2006 7:48 PM
To: 'Secure Coding Mailing List'
Cc: 'owasp-dotnet at lists.sourceforge.net'
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java 

 

Here is a more detailed explanation of why (in my previous post) I said:
"99% of .Net and Java code that is currently deployed is executed on an
environment where the VM verifier is disabled,  ."

------------------

In .Net the verifier (the CLR function that checks for type safety) is only
enabled on partial trust .Net environments.

For example, in Full Trust .Net you can successfully assign Type A to Type B
(also called a Type Confusion attack) which clearly breaks type safety.

I have done some research on this topic, and on my spare time I was able to
find several examples of these situations:

*	Possible Type Confusion issue in .Net 1.1 (only works in FullTrust)
(http://owasp.net/blogs/dinis_cruz/archive/2005/11/08/36.aspx)
*	Another Full Trust CLR Verification issue: Exploiting Passing
Reference Types by Reference
(http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/393.aspx)
*	Another Full Trust CLR Verification issue: Changing Private Field
using Proxy Struct
(http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/394.aspx)
*	Another Full Trust CLR Verification issue: changing the Method
Parameters order
(http://owasp.net/blogs/dinis_cruz/archive/2005/12/26/390.aspx)
*	C# readonly modifier is not enforced by the CLR (when in Full Trust
(http://owasp.net/blogs/dinis_cruz/archive/2005/12/26/390.aspx)
*	Also related: 

*	JIT prevents short overflow (and PeVerify doesn't catch it)
(http://owasp.net/blogs/dinis_cruz/archive/2006/01/10/422.aspx)     
*	and ANSI/UNICODE bug in System.Net.HttpListenerRequest
(http://www.owasp.net//blogs/dinis_cruz/archive/2005/12/17/349.aspx
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/12/17/349.aspx> )

Here is Microsoft's 'on the record' comment about this lack of verification
(and enforcement of type safety) on Full Trust code (note: I received these
comments via the MSRC):

"...
Some people have argued that Microsoft should always enforce type safety
at runtime (i.e. run the verifier) even if code is "Fully Trusted".
We've chosen not to do this for a number of reasons (e.g. historical,
perf, etc). There are at least two important things to consider about
this scenario:

1) Even if we tried to enforce type safety using the verifier for Fully
Trusted code, it wouldn't prevent Fully Trusted from accomplishing the
same thing in 100 other different ways. In other words, your example
accessed an object as if it were a different incompatible type - The
verifier could have caught this particular technique that allowed him to
violate type safety. However, he could have accomplished the same
result using private reflection, direct memory access with unsafe code,
or indirectly doing stuff like using PInvoke/native code to disable
verification by modifying the CLR's verification code either on disk or
in memory. There would be a marginal benefit to insuring people wrote
"cleaner" more "type safe" code by enforcing verification at runtime for
Full Trust, but you wouldn't get any additional security benefits
because you can perform unverifiable actions in dozens of ways the
verifier won't prevent if you are Fully Trusted.

2) As mentioned at the end of #1 above, one argument is that it's good
for programmers (even fully trusted ones) to follow type safety rules,
and doing runtime verification would keep people writing cleaner code.
However, we don't need to do the verification at "runtime" in order to
encourage good type safety hygiene. Instead, we can rely on our
languages to do this for us. For example, C# and VB by default ensure
that you produce verifiable code. If you've written your code in a
language like C#, you're not going to run into cases where you've
accidentally created unverifiable code (This can be seen in the example
posted on the blog since you needed to use the low level assembler to
hack up a program initially compiled in C#). Given that you can't
prevent Fully Trusted code from doing unverifiable things at runtime,
there's only a marginal difference between encouraging type safety at
compile time vs at runtime for the Fully Trusted code developer.

I hope that helps to convey the message on where Microsoft stands with
this issue.
..."


Unfortunately Java is not much better. By default most Java code is also
executed with -noverify.

Here is a good explanation from this
(http://lists.grok.org.uk/pipermail/full-disclosure/2006-March/044505.html)
thread (which I started) :

"... 
>> I am not a Java expert, but I think that the Java Verifier is NOT  
>> used on Apps that 
>> are executed with the Security Manager disabled (which I  believe is the
default 
>> setting) or are loaded from a local disk (see "...  applets loaded via
the file system 
>> are not passed through the byte code verifier" in
http://java.sun.com/sfaq/)

> I believe that as of Java 1.2, all Java code except the core  
> libraries must
> go through the verifier, unless it is specifically disabled (java
> -noverify).

I had the same intuition about the verifier, but have just tested  
this and it is not the case.  It seems that the -noverify is the  
default setting! If you want to verify classes loaded from the local  
filesystem, then you need to explicitly add -verify to the cmd line.   
I tested this by compiling 2 classes where one accesses a public  
member of the other.  Then recompiled the other and changed the  
method access to private.  Tested on:
Jdk 1.4.2 Mac OS X
Jdk 1.5.0 Mac OS X
Jdk 1.5.0 Win XP

all behave the same.

[~/data/dev/applettest/src]java -cp . FullApp
Noone can access me!!
[~/data/dev/applettest/src]java -cp . -verify FullApp
Exception in thread "main" java.lang.IllegalAccessError: tried to  
access field MyData.secret from class FullApp at FullApp.main 
(FullApp.java:23)

Using the same code with an Applet loaded from the filesystem throws  
an IllegalAccessError exception as it should.
..."

Any Comments?

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060502/a75eb8a3/attachment.html 

From stephen at corsaire.com  Wed May  3 03:38:42 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Wed, 3 May 2006 14:38:42 +0700
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java 
In-Reply-To: <4457EFC3.4090605@ddplus.net>
References: <4457EFC3.4090605@ddplus.net>
Message-ID: <6D732530-ECD0-47D9-9F3C-48A16019E6E4@corsaire.com>


On 3 May 2006, at 06:48, Dinis Cruz wrote:

> Here is a more detailed explanation of why (in my previous post) I  
> said: "99% of .Net and Java code that is currently deployed is  
> executed on an environment where the VM verifier is disabled,  ."
>
> ------------------
>
> In .Net the verifier (the CLR function that checks for type safety)  
> is only enabled on partial trust .Net environments.

Java has implemented this a bit differently, in that the byte code  
verifier and the security manager are independent.  So you could for  
example, run an application with an airtight security policy (equiv  
to partial trust), but it could still be vulnerable to type confusion  
attacks if the verifier was not explicitly enabled.  To have both  
enabled you'd need to run with:
java -verify -Djava.security.policy ...

regards,

-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com







From cradle at umd.edu  Wed May  3 10:49:46 2006
From: cradle at umd.edu (David Eisner)
Date: Wed, 03 May 2006 10:49:46 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <CF8B26B8B49184429CB084616B0019300244E35D@itomae2km05.AD.QINTRA.COM>
References: <CF8B26B8B49184429CB084616B0019300244E35D@itomae2km05.AD.QINTRA.COM>
Message-ID: <4458C30A.7090708@umd.edu>

Wall, Kevin wrote:
>>  same intuition about the verifier, but have just tested  
>> this and it is not the case.  It seems that the -noverify is the  
>> default setting! If you want to verify classes loaded from the local  
>> filesystem, then you need to explicitly add -verify to the cmd line.
>>     


Is this (still) true?  The -verify and -noverify flag are no longer
documented [1], although they are still accepted.

I did a little experiment (with my default 1.5 VM).  I compiled a
HelloWorld program, then changed a few byes in the class file with a hex
editor.

-----8<----------
$ java -cp . HelloWorld
Exception in thread "main" java.lang.ClassFormatError: Interface name
has bad constant pool index 13056 in class file HelloWorld
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

$ java -cp . -verify HelloWorld
Exception in thread "main" java.lang.ClassFormatError: Interface name
has bad constant pool index 13056 in class file HelloWorld
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

$ java -cp . -noverify HelloWorld
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d7415fb, pid=3512,
tid=2260
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x615fb]
#
# An error report file with more information is saved as hs_err_pid3512.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

-----8<----------

-David

[1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html




From Kevin.Wall at qwest.com  Wed May  3 19:41:37 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Wed, 3 May 2006 18:41:37 -0500
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
Message-ID: <CF8B26B8B49184429CB084616B0019300244E363@itomae2km05.AD.QINTRA.COM>

David Eisner wrote...

> Wall, Kevin wrote:

The correct attribution for bring this up (and the one whom you are
quoting) is Dinis Cruz.

> >>  same intuition about the verifier, but have just tested
> >> this and it is not the case.  It seems that the -noverify is the
> >> default setting! If you want to verify classes loaded from the
local  
> >> filesystem, then you need to explicitly add -verify to the cmd
line.
> 
> Is this (still) true?  The -verify and -noverify flag are no longer
> documented [1], although they are still accepted.
> 
> I did a little experiment (with my default 1.5 VM).  I compiled a
> HelloWorld program, then changed a few byes in the class file with a
> hex editor.

Perhaps no longer true (at least one could hope), but I can't take
credit
for the part you quoted above. That was Dinis.

Also, from the results of your test, it seems to indicate that SOME TYPE
of verification is taking place, but if all you did was change a few
ARBITRARY bytes in the .class file, I don't think that proves the
byte code verifier is being being run in it's entirety. IIRC, the
discussion was around the issue of 'type safety'. It's hard to see how
a HelloWorld program would show that.

It's entirely possibly that the (new 1.5) default just does some
surface level of byte code verification (e.g., verify that everything
is legal "op codes" / byte code) before HotSpot starts crunching
on it and that this works differently if either the '-verify' or
'-noverify' flags are used. E.g., suppose that '-verify' flag, does
some deeper-level analysis, such as checks to ensure type safety, etc,
whereas the '-noverify' doesn't even validate the byte codes are
legal op codes or that the .class file has a legal format. This might
even make sense because checking for valid file format and valid
Java "op codes" ought to be fairly "cheap" checks compared to the
deeper analysis required for things like type safety.

You didn't discuss details of what bits you tweaked, so I'm not
quite yet ready to jump up and down for joy and conclude that Sun has
now seen the light and has made the 1.5 JVM default to run the byte
code through the *complete* byte code verifier. I think more tests
are either necessary or someone at Sun who can speak in some official
capacity steps up and gives a definitive word one way or another on
this.

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
"Linux *is* user-friendly.  It's just choosy about its friends."
    - Robert Slade, http://sun.soci.niu.edu/~rslade/bkl3h4h4.rvw


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.



From dinis at ddplus.net  Wed May  3 22:40:07 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 04 May 2006 03:40:07 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <CF8B26B8B49184429CB084616B0019300244E363@itomae2km05.AD.QINTRA.COM>
References: <CF8B26B8B49184429CB084616B0019300244E363@itomae2km05.AD.QINTRA.COM>
Message-ID: <44596987.6020003@ddplus.net>

Ok, I just did some further tests and I think I can say that Java 
(version 1.5.0_06) has similar verification issues to the ones I 
discovered on the .Net Framework (see links in my previous post).

Here is a full description of my test (which is a variation of the one 
done by Stephen de Vries in the original discussion about type safety).

-------------

Objective: Call a private method directly that belongs to a different 
class (something that should not be possible to do)

Test environment: Mac OS X10.4.6

java -version

    java version "1.5.0_06"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)
    Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)


Step by Step description of test:


Start by creation the File: publicPrivate.java

******************
class publicPrivate {
    public static void main(String[] args)
    {
        System.out.println("Hello World!"); //Display the string.
        externalClass.publicMethod();
        externalClass.publicMethod();
    }

}

class externalClass
{
    public static void publicMethod()
    {
    System.out.println("Inside the Public Method");
    }

    private static void privateMethod()
    {
    System.out.println("Inside the Private Method");
    }
}
******************

Compile this using javac publicPrivate.java and you get two class files: 
publicPrivate.class and externalClass.class

execute java publicPrivate and you will get

    Hello World!
    Inside the Public Method
    Inside the Public Method

Note that if I change on the publicPrivate.java file the lines

        externalClass.publicMethod();
        externalClass.publicMethod();

to

        externalClass.publicMethod();
        externalClass.privateMethod();

I will get the following compilation error:

    publicPrivate.java:7: privateMethod() has private access in 
externalClass
            externalClass.privateMethod();
                     ^
    1 error


This makes sense since this is the compiler detecting that we are trying 
to access a private member directly (note: this is also what happens in 
.Net's C# compiler). It also means that (like in my .Net examples) I 
will have to manipulate directly the bytecode of the class that I want 
to change

Using jEdit Oolong plug-in I disassembled  the  publicPrivate.class 
file, creating the file: publicPrivate.j

(this is a slightly edited version of the Oolong disassemble result 
since the original version didn't compile)
******************
.class public publicPrivate
    .super java/lang/Object
   
    .method public <init>()V
    .limit stack 1
    .limit locals 1
        aload_0
        invokespecial java/lang/Object/<init>()V
        return
    .end method
   
    .method public static main([Ljava/lang/String;)V
    .limit stack 2   
        getstatic java/lang/System/out Ljava/io/PrintStream;
        ldc "Hello World! - After Oolong disassemble"
        invokevirtual java/io/PrintStream/println(Ljava/lang/String;)V
       
        invokestatic externalClass/publicMethod()V
        invokestatic externalClass/publicMethod()V
   
        return
   
    .end method
**************
note the change:
    from:          ldc "Hello World!"
    to:              ldc "Hello World! - After Oolong disassemble"


I also had some problems with getting the jEdit Oolong plug-in to 
assemble the publicPrivate.j file, so I used jasmin instead:

java -jar jasmin-2.2/jasmin.jar  PublicPrivate.j

    Generated: publicPrivate.class

Executing java publicPrivate shows:

    Hello World!- After Oolong disassemble
    Inside the Public Method
    Inside the Public Method

Now, in jEdit, on the publicPrivate.j  file, I make the following change

from:
       
        invokestatic externalClass/publicMethod()V   
        invokestatic externalClass/publicMethod()V
   
to:
       
        invokestatic externalClass/publicMethod()V   
        invokestatic externalClass/privateMethod()V

Then save it and run jasmin again

java -jar jasmin-2.2/jasmin.jar  PublicPrivate.j

    Generated: publicPrivate.class

execute java publicPrivate and:

    Hello World!- After Oolong disassemble
    Inside the Public Method
    Inside the Private Method

Bingo! We successfully invoked the private method.

Now, just to confirm that this is against verification (and that the 
verifier is disabled by default)

java -noverify publicPrivate  (produces the same result)

    Hello World!- After Oolong disassemble
    Inside the Public Method
    Inside the Private Method

java -verify publicPrivate (throws an verification error)

    Hello World!- After Oolong disassemble
    Inside the Public Method
    Exception in thread "main" java.lang.IllegalAccessError: tried to 
access method externalClass.privateMethod()V from class publicPrivate
            at publicPrivate.main(PublicPrivate.j)



This should prove that the verifier is not enabled by default on java 
files loaded from the local computer.

What is interesting about this example is that we are not even doing a 
Type Confusion attack and trying to break type safety.

Ironically this same example doesn't work in the .Net CLR since the JIT 
detects this it (which is why in my 'Rooting the CLR' presentation I 
patch the JIT directly :)

Question for the Java gurus on this list (remember that I am not very 
good with Java so I might have got some of this wrong), can you 
re-confirm this test, and also see what happens on other java execution 
environments (for example on Apache)

Thanks

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net







From michaelslists at gmail.com  Wed May  3 20:06:54 2006
From: michaelslists at gmail.com (Michael Silk)
Date: Thu, 4 May 2006 10:06:54 +1000
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <CF8B26B8B49184429CB084616B0019300244E363@itomae2km05.AD.QINTRA.COM>
References: <CF8B26B8B49184429CB084616B0019300244E363@itomae2km05.AD.QINTRA.COM>
Message-ID: <5e01c29a0605031706k3f08f432x798a07a14a550262@mail.gmail.com>

Verifier in 1.5 is definately OFF by default:

to confirm this do the following:

1. Create this class:
======================================
public class Foo {
  public static int k = 23;

  static {
    System.out.println("initially k: " + k);
  }

  public static void m(){
    System.out.println("m() k: " + k);
  }
}
======================================

2. Compile it.

3. Create this class
======================================
public class Test {
  public static void main(String[] args){
    Foo.k = 34;
    Foo.m();
  }
}
======================================

4. Compile it.
5. Run it like so:
5a. java Test
5b. java -verify Test

6. Change "Foo.java" like so:
======================================
public class Foo {
  private static int k = 23;

  static {
    System.out.println("initially k: " + k);
  }

  public static void m(){
    System.out.println("m() k: " + k);
  }
}
======================================

(note "k" is now private).

7. recompile "Foo.java" (DO NOT recompile Test.java")
8. run Test.java like so:
8a. java Test
8b. java -verify Test


Note the differences ...

Tested with
===============================
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
===============================


-- Michael


On 5/4/06, Wall, Kevin <Kevin.Wall at qwest.com> wrote:
> David Eisner wrote...
>
> > Wall, Kevin wrote:
>
> The correct attribution for bring this up (and the one whom you are
> quoting) is Dinis Cruz.
>
> > >>  same intuition about the verifier, but have just tested
> > >> this and it is not the case.  It seems that the -noverify is the
> > >> default setting! If you want to verify classes loaded from the
> local
> > >> filesystem, then you need to explicitly add -verify to the cmd
> line.
> >
> > Is this (still) true?  The -verify and -noverify flag are no longer
> > documented [1], although they are still accepted.
> >
> > I did a little experiment (with my default 1.5 VM).  I compiled a
> > HelloWorld program, then changed a few byes in the class file with a
> > hex editor.
>
> Perhaps no longer true (at least one could hope), but I can't take
> credit
> for the part you quoted above. That was Dinis.
>
> Also, from the results of your test, it seems to indicate that SOME TYPE
> of verification is taking place, but if all you did was change a few
> ARBITRARY bytes in the .class file, I don't think that proves the
> byte code verifier is being being run in it's entirety. IIRC, the
> discussion was around the issue of 'type safety'. It's hard to see how
> a HelloWorld program would show that.
>
> It's entirely possibly that the (new 1.5) default just does some
> surface level of byte code verification (e.g., verify that everything
> is legal "op codes" / byte code) before HotSpot starts crunching
> on it and that this works differently if either the '-verify' or
> '-noverify' flags are used. E.g., suppose that '-verify' flag, does
> some deeper-level analysis, such as checks to ensure type safety, etc,
> whereas the '-noverify' doesn't even validate the byte codes are
> legal op codes or that the .class file has a legal format. This might
> even make sense because checking for valid file format and valid
> Java "op codes" ought to be fairly "cheap" checks compared to the
> deeper analysis required for things like type safety.
>
> You didn't discuss details of what bits you tweaked, so I'm not
> quite yet ready to jump up and down for joy and conclude that Sun has
> now seen the light and has made the 1.5 JVM default to run the byte
> code through the *complete* byte code verifier. I think more tests
> are either necessary or someone at Sun who can speak in some official
> capacity steps up and gives a definitive word one way or another on
> this.
>
> -kevin
> ---
> Kevin W. Wall           Qwest Information Technology, Inc.
> Kevin.Wall at qwest.com    Phone: 614.215.4788
> "Linux *is* user-friendly.  It's just choosy about its friends."
>    - Robert Slade, http://sun.soci.niu.edu/~rslade/bkl3h4h4.rvw
>
>
> This communication is the property of Qwest and may contain confidential or
> privileged information. Unauthorized use of this communication is strictly
> prohibited and may be unlawful.  If you have received this communication
> in error, please immediately notify the sender by reply e-mail and destroy
> all copies of the communication and any attachments.
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>



From dinis at ddplus.net  Wed May  3 23:07:13 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 04 May 2006 04:07:13 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <4458C30A.7090708@umd.edu>
References: <CF8B26B8B49184429CB084616B0019300244E35D@itomae2km05.AD.QINTRA.COM>
	<4458C30A.7090708@umd.edu>
Message-ID: <44596FE1.8040607@ddplus.net>

David Eisner wrote:
> Wall, Kevin wrote:
>   
>>>  same intuition about the verifier, but have just tested  
>>> this and it is not the case.  It seems that the -noverify is the  
>>> default setting! If you want to verify classes loaded from the local  
>>> filesystem, then you need to explicitly add -verify to the cmd line.
>>>     
>>>       
>
>
> Is this (still) true?  The -verify and -noverify flag are no longer
> documented [1], although they are still accepted.
>   
Yes it is still true (see my last email on this thread)
> I did a little experiment (with my default 1.5 VM).  I compiled a
> HelloWorld program, then changed a few byes in the class file with a hex
> editor.
>   
By doing this this (unless you were very lucky in your changes) you will 
either create an invalid Java bytecode instruction, or will corrupt the 
.class file

So the errors you are getting below don't look like verifier errors 
(although I can't really explain why the --noverify throws a different 
error).

Can you try to disassemble this corrupted class so see if we can get 
more details about where the bytecode error is

Thanks

Dinis Cruz
Owasp .Net Project
www.owasp.net
> -----8<----------
> $ java -cp . HelloWorld
> Exception in thread "main" java.lang.ClassFormatError: Interface name
> has bad constant pool index 13056 in class file HelloWorld
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>         at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
>         at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
>         at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>
> $ java -cp . -verify HelloWorld
> Exception in thread "main" java.lang.ClassFormatError: Interface name
> has bad constant pool index 13056 in class file HelloWorld
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>         at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
>         at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
>         at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>
> $ java -cp . -noverify HelloWorld
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d7415fb, pid=3512,
> tid=2260
> #
> # Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode)
> # Problematic frame:
> # V  [jvm.dll+0x615fb]
> #
> # An error report file with more information is saved as hs_err_pid3512.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> #
>
> -----8<----------
>
> -David
>
> [1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060504/671cb70a/attachment.html 

From dinis at ddplus.net  Wed May  3 23:26:29 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 04 May 2006 04:26:29 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <CF8B26B8B49184429CB084616B0019300244E363@itomae2km05.AD.QINTRA.COM>
References: <CF8B26B8B49184429CB084616B0019300244E363@itomae2km05.AD.QINTRA.COM>
Message-ID: <44597465.50809@ddplus.net>

Wall, Kevin wrote:

> Also, from the results of your test, it seems to indicate that SOME TYPE
> of verification is taking place, but if all you did was change a few
> ARBITRARY bytes in the .class file, I don't think that proves the
> byte code verifier is being being run in it's entirety. 
I agree with this analysis and think that the error on David's test was 
caused by a malformed bytecode instruction
> It's entirely possibly that the (new 1.5) default just does some
> surface level of byte code verification (e.g., verify that everything
> is legal "op codes" / byte code) 
Well, some level of verification (or bytecode check) must always occur 
during the conversion from bytecode to native code (but this has nothing 
to do with type safety)
> before HotSpot starts crunching
> on it and that this works differently if either the '-verify' or
> '-noverify' flags are used. E.g., suppose that '-verify' flag, does
> some deeper-level analysis, such as checks to ensure type safety, etc,
> whereas the '-noverify' doesn't even validate the byte codes are
> legal op codes or that the .class file has a legal format. This might
> even make sense because checking for valid file format and valid
> Java "op codes" ought to be fairly "cheap" checks compared to the
> deeper analysis required for things like type safety.
>   
I am a little bit confused here, isn't Java an open platform and almost 
Open Source?

If so, shouldn't issues like this be quite well documented? (if not on 
official documentation, at least on online discussion threads)

I have a couple books on java that discuss the verification process, but 
they are quite old, so It would be good to know the details about the 
current verification process (as implemented in the latest version)
> You didn't discuss details of what bits you tweaked, so I'm not
> quite yet ready to jump up and down for joy and conclude that Sun has
> now seen the light and has made the 1.5 JVM default to run the byte
> code through the *complete* byte code verifier. 
Unfortunately I don't think that Sun has seen the light on this one (and 
neither has Microsoft)
> I think more tests
> are either necessary or someone at Sun who can speak in some official
> capacity steps up and gives a definitive word one way or another on
> this.
>   
Talking about Sun, where are they? I know that Jeff Williams (Owasp) 
have tried several times to get a response from them on these issues but 
has been unsuccessful.

Aren't they (Sun) supposed to be much more open and transparent about 
Java? (at least when compared to Microsoft)

I am sure that there must be people from Sun on this list (likewise from 
Microsoft),  and it would be great if they joined this discussion so 
that we can understand exactly what is going on.

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net



From michaelslists at gmail.com  Thu May  4 07:29:10 2006
From: michaelslists at gmail.com (Michael Silk)
Date: Thu, 4 May 2006 21:29:10 +1000
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <44597465.50809@ddplus.net>
References: <CF8B26B8B49184429CB084616B0019300244E363@itomae2km05.AD.QINTRA.COM>
	<44597465.50809@ddplus.net>
Message-ID: <5e01c29a0605040429q1695f50cm2ef7160d1c627df3@mail.gmail.com>

On 5/4/06, Dinis Cruz <dinis at ddplus.net> wrote:
> Wall, Kevin wrote:
>
> > Also, from the results of your test, it seems to indicate that SOME TYPE
> > of verification is taking place, but if all you did was change a few
> > ARBITRARY bytes in the .class file, I don't think that proves the
> > byte code verifier is being being run in it's entirety.
> I agree with this analysis and think that the error on David's test was
> caused by a malformed bytecode instruction
> > It's entirely possibly that the (new 1.5) default just does some
> > surface level of byte code verification (e.g., verify that everything
> > is legal "op codes" / byte code)
> Well, some level of verification (or bytecode check) must always occur
> during the conversion from bytecode to native code (but this has nothing
> to do with type safety)
> > before HotSpot starts crunching
> > on it and that this works differently if either the '-verify' or
> > '-noverify' flags are used. E.g., suppose that '-verify' flag, does
> > some deeper-level analysis, such as checks to ensure type safety, etc,
> > whereas the '-noverify' doesn't even validate the byte codes are
> > legal op codes or that the .class file has a legal format. This might
> > even make sense because checking for valid file format and valid
> > Java "op codes" ought to be fairly "cheap" checks compared to the
> > deeper analysis required for things like type safety.
> >
> I am a little bit confused here, isn't Java an open platform and almost
> Open Source?

The source for the j2se sdk is available (i.e. all the classes) and
the source for the runtime is available as well, but under a
different, special license.


> If so, shouldn't issues like this be quite well documented?

Actually, the verification process is documented here:
 http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#88597

-- Michael



From Ken at krvw.com  Thu May  4 11:12:59 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Thu, 4 May 2006 11:12:59 -0400
Subject: [SC-L] HNS - Biggest X Window security hole since 2000
Message-ID: <200605041112.59794@KRvW>

Stories about this (below) X bug and the DHS-sponsored project that found it 
have been floating around the net all week.  This story caught my eye, 
though:

http://www.net-security.org/secworld.php?id=3994

The author claims, "This flaw, caused by something as seemingly harmless as a 
missing closing parenthesis, allowed local users to execute code with root 
privileges, giving them the ability to overwrite system files or initiate 
denial of service attacks."

So, it sounds like a single byte change in the entire X src tree could fix a 
bug that could give an attacker complete control of a system.  Lovely...

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060504/322e8bff/attachment.bin 

From ge at linuxbox.org  Thu May  4 12:40:17 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Thu, 4 May 2006 11:40:17 -0500 (CDT)
Subject: [SC-L] HNS - Biggest X Window security hole since 2000
In-Reply-To: <200605041112.59794@KRvW>
Message-ID: <Pine.LNX.4.21.0605041139540.11826-100000@linuxbox.org>

On Thu, 4 May 2006, Kenneth R. van Wyk wrote:
> Stories about this (below) X bug and the DHS-sponsored project that found it 
> have been floating around the net all week.  This story caught my eye, 
> though:
> 
> http://www.net-security.org/secworld.php?id=3994
> 
> The author claims, "This flaw, caused by something as seemingly harmless as a 
> missing closing parenthesis, allowed local users to execute code with root 
> privileges, giving them the ability to overwrite system files or initiate 
> denial of service attacks."
> 
> So, it sounds like a single byte change in the entire X src tree could fix a 
> bug that could give an attacker complete control of a system.  Lovely...

Hmm, I think this was fixed in earlier X versions.

	Gadi.

> 
> Cheers,
> 
> Ken van Wyk
> -- 
> KRvW Associates, LLC
> http://www.KRvW.com
> 



From Ken at krvw.com  Thu May  4 13:37:48 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Thu, 4 May 2006 13:37:48 -0400
Subject: [SC-L] HNS - Biggest X Window security hole since 2000
In-Reply-To: <Pine.LNX.4.21.0605041139540.11826-100000@linuxbox.org>
References: <Pine.LNX.4.21.0605041139540.11826-100000@linuxbox.org>
Message-ID: <200605041337.59915@KRvW>

On Thursday 04 May 2006 12:40, Gadi Evron wrote:
> Hmm, I think this was fixed in earlier X versions.

Not impossible, but the article clearly indicated that it's in 6.9.0 and 
7.0.0, which are the most current in general circulation, I believe.

But, some bugs are so important that they deserved to be fixed more than once.  
It sure wouldn't be the first time that a bug found its way back into a src 
tree.

Cheers,

Ken
-- 
KRvW Associates, LLC
http://www.KRvW.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060504/092a0290/attachment.bin 

From cradle at umd.edu  Thu May  4 13:38:35 2006
From: cradle at umd.edu (David Eisner)
Date: Thu, 04 May 2006 13:38:35 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <44596987.6020003@ddplus.net>
References: <CF8B26B8B49184429CB084616B0019300244E363@itomae2km05.AD.QINTRA.COM>
	<44596987.6020003@ddplus.net>
Message-ID: <445A3C1B.5070504@umd.edu>

Dinis Cruz wrote:
> Ok, I just did some further tests and I think I can say that Java
> (version 1.5.0_06) has similar verification issues to the ones I
> discovered on the .Net Framework (see links in my previous post).
[...]
> This should prove that the verifier is not enabled by default on java
> files loaded from the local computer.

First, apologies to Dinis and Kevin for the mis-attribution.

I agree, based on the various experiments, it looks like the bytecode
verifier is still not enabled by default for locally loaded class
files.  I'm not sure why my randomly modified HelloWorld.class file
behaved differently in the -verify / -noverify cases.  If I have more
time, I'll dig into it.

As mentioned, the source code for the jdk is available under the Sun
Community Source License. [1]  Unfortunately, this license doesn't
permit redistribution of code to non-licensees, so I'll just describe
what I found when I took a (non-exhaustive) look. 

j2se/src/share/bin/java.c:

java {-verify, -verifyremote, -noverify} are aliases for options passed
to the Java Hotspot Virtual Machine.  The options are aliased to
-Xverify:all, -Xverify:remote, and -Xverify:none, respectively.  These
options, in turn, don't seem to be documented, at least not in the VM
options documentation. [2]

Ah, but they are documented elsewhere. [3]  From that document:

----8<--------------
So, why all this verification? When class files are loaded (possibly
over the network or from an untrusted source) into a virtual machine,
there is no way of telling how its byte codes were generated. Basically,
in most cases, you can't trust the source of the Java class files. In
fact, the default verification setting in JRE 1.1 is to only verify
classes loaded from over the network. So, anything installed locally,
via CLASSPATH, is not verified. In JRE 1.1, if you have installed
something locally from a third-party and want to even verify that, too,
you can do that. Or, you can completely disable verification. The three
settings are all options to the java and jre commands:

    * -verifyremote - only perform verification process on classes
loaded over network (default)
    * -verify - verify everything
    * -noverify - verify nothing

In JDK 1.2, the default setting for verification is the same only verify
classes loaded over the network. However, the system classes are
specified from something other than the CLASSPATH environment variable,
and the command line options for verification differ. The system classes
are specified by either the System property sun.boot.class.path or the
command line option -Xbootclasspath:directories and jar files. This is
automatically set for you by the JRE and should never need to be set
manually. If you set it to add something yourself be sure to include the
original defaults, too. With regards to verification, if you wish to
manually control the level of verification, the options to the java
command with the V1.2 JRE are as follows:

    * -Xverify:remote - only perform verification process on classes
loaded over network (default)
    * -Xverify:all - verify everything
    * -Xverify:none - verify nothing

If a verification error is encountered, instead of the JRE reporting a
verification error or throwing an exception, it reports a can't find
error, like: Can't find class MyClass.
----8<--------------


On the other hand, this message from the java-security mailing list
archives [4] (from July 2001) seems to say something else:

----8<--------------
The "system classes" such as those in java.* that are contained in
rt.jar are loaded by the bootstrap class loader built-in to the Java
Virtual Machine. In Jave 2, the next class loader searched for classes
is the extension class loader which looks for classes in the jar files
in the lib/ext directory where the Java Runtime Environment is
installed. The so-called "system class loader" actually loads the
application classes found from the -classpath command line argument or
the CLASSPATH environment variable. Yes, the name "system class loader"
is confusing. It is named that way for historical reasons when both core
system classes as well as application classes were all loaded by the
bootstrap class loader in JDK 1.1.

>
> I thought that, by default, the Java API classes (rt.jar) are the only
ones
> that dont go thru the ByteCode Verifier?

        You are correct again. By default, all classes go through the
bytecode verifier except for those loaded by the bootstrap class loader.
You can change this behavior through the use of command line arguments.
This is because all classes except for those loaded by the bootstrap
class loader can by granted fine-grained security permissions. In order
to prevent those classes from cheating and trying to get more
permissions than they have been granted we need to verify them. Classes
loaded by the bootstrap class loader are always granted "AllPermission"
and cannot be granted fewer permissions. These classes are trusted as
part of the core Java runtime. Therefore there is no need to verify them
at runtime.
----8<--------------


This seems to jibe with what's in the Hotspot VM source code: If you're
curious, take a look at

jdk-1_5_0_scsl/hotspot/src/share/vm/runtime/arguments.cpp   and
jdk-1_5_0_scsl/hotspot/src/share/vm/runtime/globals.hpp
jdk-1_5_0_scsl/hotspot/src/share/vm/runtime/verifier.cpp  (start with
Verifier::verify_byte_codes)

paying attention to the BytecodeVerificationRemote and
BytecodeVerificationRemote booleans.  Semantically, "Local" seems to
mean the class loader for the class is null, and "Remote" means it
isn't.  Consulting the Classs.getClassLoader() public api documentation [5]:

"Returns the class loader for the class. Some implementations may use
null to represent the bootstrap class loader. This method will return
null in such implementations if this class was loaded by the bootstrap
class loader."

So this would seem to suggest that non-bootstrap classes *are* bytecode
verified.  Here's another experiment:

----8<------------------
$ cat HelloWorld.java
public class HelloWorld {
    public static void main( String[] args ) {
        System.out.println( "HelloWorld class loader: " +
                             HelloWorld.class.getClassLoader() );

        System.out.println( "Math class loader: " +
                             Math.class.getClassLoader() );
        System.exit(0);
    }
}

$ java -cp . HelloWorld
HelloWorld class loader: sun.misc.Launcher$AppClassLoader at e39a3e
Math class loader: null

----8<------------------


What determines when access to a private member is illegal?  Is it, in
fact, the bytecode verifier? 

-David



[1] http://www.sun.com/software/communitysource/j2se/java2/download.xml
[2] http://java.sun.com/docs/hotspot/VMOptions.html
[3]
http://java.sun.com/developer/onlineTraining/Security/Fundamentals/Security.html
[4]
http://archives.java.sun.com/cgi-bin/wa?A2=ind0107&L=java-security&D=0&P=1305
[5]
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getClassLoader()


From tholleb at teknowledge.com  Thu May  4 13:58:21 2006
From: tholleb at teknowledge.com (Tim Hollebeek)
Date: Thu, 4 May 2006 10:58:21 -0700
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <4458C30A.7090708@umd.edu>
Message-ID: <200605041745.k44HjP7l086666@ratsass.krvw.com>

 
> $ java -cp . -noverify HelloWorld
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d7415fb, 
> pid=3512, tid=2260 # # Java VM: Java HotSpot(TM) Client VM 
> (1.5.0_06-b05 mixed mode) # Problematic frame:
> # V  [jvm.dll+0x615fb]


Note that EXCEPTION_ACCESS_VIOLATION is the Windows equivalent of a
segmentation violation; this isn't the Verifier complaining, it's
the JVM crashing.

The fact that editing the .class file allows you to produce one that
causes the JVM to crash is pretty strong evidence the verifier was
NOT used to validate the file.

Tim Hollebeek
Research Scientist
Teknowledge Corp.




From gem at cigital.com  Thu May  4 14:36:25 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 4 May 2006 14:36:25 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE6D6@va-mail.cigital.com>

I'm psyched about this thread.  Rock on guys.

For those of you who may need some basics, you might want to read
Securing Java (a book I wrote with Ed Felten in 1999...the first edition
in 1996 was called Java Security).  The book is available completely for
free in searchable format at http://www.securingjava.com

I bring this up, because many of the terms being properly bandied about
in this thread are carefully described there.  Types, type confusion,
the security model, the role of the verifier, why you can't trust byte
code...etc.

Happy history.  I am feeling rather old.

gem
www.cigital.com/~gem
www.swsec.com



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From dinis at ddplus.net  Thu May  4 14:05:01 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 04 May 2006 19:05:01 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <11f401c66e5d$4084b290$9204a8c0@intranet.aspectsecurity.com>
References: <11f401c66e5d$4084b290$9204a8c0@intranet.aspectsecurity.com>
Message-ID: <445A424D.6080504@ddplus.net>

Jeff Williams wrote:
>
> Two important clarifications for Java (based on my experiments): 
>
> 1) The verifier IS enabled for the classes that come with the Java 
> platform, such as those in rt.jar.  So, for example, if you create a 
> class that tries to set System.security (the private variable that 
> points to the SecurityManager instance), you get a verification 
> exception. (If this was possible, it would allow a complete bypass of 
> the Java sandbox).
>
But with either Type Confusion attacks or with the Security Manager 
disabled, you can still completely bypass the Java Sandbox, right?
>
> 2) The verifier also seems to be enabled for classes running inside 
> Tomcat. I'm not sure about other J2EE containers.
>
This is interesting, do you have any documentation to back this up? 
Ideally there would be a document somewhere which listed which J2EE 
containers run with the verifier on by default
>
> So I don't think it's fair to say that most Java code is running 
> without verification.
>
If all jsp out there is verified then yes 99% is not a correct number, 
any idea what percentage it could be?
>
> But Denis is right. There is a real problem with verification, as 
> demonstrated in the message below.  This is a clear violation of the 
> Java VM Spec, yet my messages to the team at Sun developing the new 
> verifier have been ignored.  And it's a real issue, given the number 
> of applications that rely on libraries they didn't compile.  I don't 
> think a real explanation of how the Sun verifier actually works is too 
> much to ask, given the risk.
>
I agree, and Sun will probably do the same thing that Microsoft is doing 
at the moment: "Ignore the issue and hope that it goes away"

Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060504/d13dc556/attachment.html 

From cradle at umd.edu  Thu May  4 18:58:48 2006
From: cradle at umd.edu (David Eisner)
Date: Thu, 04 May 2006 18:58:48 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <200605041758.k44HwmLE013202@mailfw0.umd.edu>
References: <200605041758.k44HwmLE013202@mailfw0.umd.edu>
Message-ID: <445A8728.7090409@umd.edu>

Tim Hollebeek wrote:
> The fact that editing the .class file allows you to produce one that
> causes the JVM to crash is pretty strong evidence the verifier was
> NOT used to validate the file.
>   

Right.  What follows is a summary of what we know so far, and what I
think is going on.  The details get a bit gory at the end, but you can
skim it.

 I ran the corrupted .class file three ways, and obtained these results:

1) (no switch): ClassFormatError exception
2) -verify: ClassFormatError exception
3) -noverify: JVM crash (EXCEPTION_ACCESS_VIOLATION)

I thought (incorrectly) that this might indicate that providing no
switch was equivalent to -verify.  In fact, it now appears that
providing no switch is equivalent to -verifyremote (see my previous
message).  If I do the same experiment again, I see that, yes, "java
-verify" and "java -verifyremote" produce the same result, and "java
-noverify" crashes the JVM.

This suggests to me that the locally loaded HelloWorld.class file is
considered "remote" code.  On the other hand, Michael's and Dinis's
experiments show that (using Michael's example, after recompiling
Foo.java once k is made a private member):

1) (no switch / -verifyremote ): illegal access to private member ALLOWED
2) -verify (i.e. -Xverify:all):  illegal access to private member CAUGHT
3) -noverify( i.e. -Xverify:none): illegal access to private member ALLOWED

So in this case, cases 1 and 3 are the same (with my mangled .class file
experiment, cases 1 and 2 are the same).  This suggests that the
Foo.class file is being treated as "local" code.

How are we to understand this?  The short answer is that the meaning of
"remote" depends on what type of verification Sun's hotspot VM is doing.

With the help of Gary's book [1][2] (thanks!) we note that the Verifier,
in verifying classes, performs two kinds of checks: "verification time"
checks (steps 1-3 of page [2])  on the class file and its bytecodes, and
"runtime" checks, checks that can't be done at verification time because
"aspects of Java's type system cannot be statically checked."  This
includes "check[ing] the executing method for access privilege."  This
is step 4. on page [2] of Gary's book).

We see that my experiment involves static, verification-time checks. 
Michael and Divis's experiments, on the other hand, involve runtime
checks.  It appears that the VM is treating .class files loaded through
the CLASSPATH as "remote" for the purpose of verification-time (i.e.
static) checks, but treating them as "local" for the purpose of run-time
access checking verification.

Just to verify this, here is another experiment, again with the corrupt
class file (actually, this is the HelloWorld.class from my last email,
so it's a slightly different ClassFormatError).

First, I run with java -verifyremote and get the ClassFormatError.  This
means the VM thinks ./HelloWorld.class is remote.  Next, I use the
-Xbootclasspath/a switch to add the current directory to the
bootclasspath. This should cause the VM to treat ./HelloWorld.class as
it does the system classes in rt.jar, etc, i.e., "local."  And, yes,
now, I get the JVM crash, even with -verifyremote:

---8<------------------

$ java -verifyremote HelloWorld
Exception in thread "main" java.lang.ClassFormatError: Invalid method
Code length 858993413 in class file HelloWorld
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)


$ java -Xbootclasspath/a:. -verifyremote HelloWorld
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d72dacf, pid=5168,
tid=3576
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x4dacf]
#
# An error report file with more information is saved as hs_err_pid5168.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---8<------------------


Summary of what I think happens,  more or less, with the 1.5 JRE. 

1. DEFINITIONS

a) "Bootstrap Class": any class that was loaded by the "Primordial Class
Loader." [3] (aka "bootstrap class loader.") Classes in the bootstrap
classpath are one example (like classes in rt.jar).

b) "Ordinary Class": any class that was loaded by a Class Loader that is
not the Primordial class loader.  This includes classes on the local
filesystem loaded from the CLASSPATH.  (note that this is different than
the behavior described in [3]).  In other words, the set of Ordinary
Classes is the complement of the set of Bootstrap classes.  This also
includes classes loaded over the network.

c) "CP Class": any class that was loaded by the (confusingly named)
"System Class Loader."  These are the classes found through CLASSPATH or
by the -cp switch. [5]  ("CP stands for CLASSPATH, but I thought
"CLASSPATH Class" was too unwieldy.").  Classes loaded over the network
are *not* CP classes.



2. STATIC (or "verification time") VERIFICATION

Static verification refers to class-file format verification and
bytecode analsysis described in steps 1-3 of [2].  By default, static
verification is performed on Ordinary Classes only.  Specifying java
-verify/-Xverify:all causes both Bootsrap and Ordinary classes to
undergo static verification. And with -noverify/-Xverify:none, no class
will undergo static verification.

[See jdk-1_5_0_scsl/hotspot/src/share/vm/runtime/classFileParser.cpp [4]
  Notice that "_need_verify" is set by calling
Verifier::should_verify_for(), defined in
  jdk-1_5_0_scsl/hotspot/src/share/vm/runtime/verifier.cpp. 
  Then trace how BytecodeVerificationLocal and
BytecodeVerificationRemote are set by the commandline args. ]
 
  

3. RUNTIME VERIFICATION

Runtime verification refers to non-static verification that can't be
performed until class execution, including access to private/public/etc.
fields. [2]  I *think* that, by default, (e.g. no switch or
-verifyremote), only classes that are Ordinary but not CP classes
undergo runtime verification.  Network-loaded classes would be an example.

If -verify (-Xverify:all) is specified, all classes undergo verification.

Finally, if -noverify (-Xverify:none) is specified, no classes undergo
verification.

[See Reflection::verify_field_access() in
jdk-1_5_0_scsl/hotspot/src/share/vm/runtime/reflection.cpp.  This is the
method that checks whether access to a private field is permitted, for
example. 

Notice that (depending on how it is called) verify_field_access() calls
Verifier::relax_verify_for( <the class's class loader>) to see whether
it can skip the check.  It looks like (see
jdk-1_5_0_scsl/hotspot/src/share/vm/runtime/verifier.cpp again)
relax_verify_for() decides whether the passed-in Class loader (i.e. the
loader for the class trying to get access to a field) should get to skip
the access checks.  Here is how it decides (if you decode the logic):

 1.  if  -verify (i.e. -Xverify:all) was specified when the VM was
initialized, then no class loader gets to skip the access check.
 2.  else if -verifyremote (-Xverify:remote) was specified, then the
class loader gets to skip the access check if 
java_lang_ClassLoader::is_trusted_loader() says it's trusted!
 3. else nobody gets to skip the check.

And, finally (my head hurts), what is a "trusted_loader" ?  See
is_trusted_loader() in

  jdk-1_5_0_scsl/hotspot/src/share/vm/memory/javaClasses.cpp

It says (I paraphrase), "This loader is trusted if it is the 
SystemDictionary::java_system_loader(), or one of its ancestors."   This
is where I'm a little lost.  I think this is the "System Class Loader"
refered to in [5]]

Is anybody still reading? 

-David


[1] http://www.securingjava.com/chapter-two/chapter-two-5.html
[2] http://www.securingjava.com/chapter-two/chapter-two-6.html
[3] http://www.securingjava.com/chapter-two/chapter-two-7.html
[4] http://www.sun.com/software/communitysource/j2se/java2/download.xml
[5]
http://archives.java.sun.com/cgi-bin/wa?A2=ind0107&L=java-security&D=0&P=1305




From jeff.williams at aspectsecurity.com  Fri May  5 00:13:16 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Fri, 5 May 2006 00:13:16 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <445A424D.6080504@ddplus.net>
Message-ID: <042e01c66ffa$440ede10$4e01a8c0@intranet.aspectsecurity.com>


>> 2) The verifier also seems to be enabled for classes running inside
Tomcat. I'm >> not sure about other J2EE containers. 
> This is interesting, do you have any documentation to back this up?
Ideally there > would be a document somewhere which listed which J2EE
containers run with the > verifier on by default

I determined this experimentally since I cannot find any authoritative
documentation showing exactly when classes are verified and when they are
not.  The test is essentially the same as the other tests discussed in this
thread.

You can try it yourself with the attached zip file. Start with TestServlet
calling public method named privateMethod() in Foo.java.  Compile both files
"javac -classpath servlet-api.jar *.java".  Then edit Foo.java to make
privateMethod really private.  Then recompile just Foo.java "javac
-classpath servlet-api.jar Foo.java".  Copy the class files into the
WEB-INF\classes folder.  Then drop the whole TestServlet folder into the
webapps directory in a standard Tomcat directory.  Run Tomcat's startup.bat
and browse to http://localhost:8080/TestServlet/test.

Here's the output.  I'd love to hear what happens with this in other
servers, if anyone has WebSphere or WebLogic lying around.

java.lang.IllegalAccessError: tried to access method Foo.privateMethod()V
from c
lass TestServlet
        at TestServlet.doGet(TestServlet.java:22)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:252)
        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
        at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:213)
        at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:178)
        at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:126)
        at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:105)
        at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:107)
        at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:148)
        at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:868)
        at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p
rocessConnection(Http11BaseProtocol.java:663)
        at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
int.java:527)
        at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol
lowerWorkerThread.java:80)
        at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
ool.java:684)
        at java.lang.Thread.run(Thread.java:595)

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: VerifierServletTest.zip
Type: application/x-zip-compressed
Size: 93846 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060505/a752705d/attachment.bin 

From michaelslists at gmail.com  Thu May  4 20:33:08 2006
From: michaelslists at gmail.com (Michael Silk)
Date: Fri, 5 May 2006 10:33:08 +1000
Subject: [Owasp-dotnet] Re: [SC-L] By default,
	the Verifier is disabled on .Net and Java
In-Reply-To: <445A424D.6080504@ddplus.net>
References: <11f401c66e5d$4084b290$9204a8c0@intranet.aspectsecurity.com>
	<445A424D.6080504@ddplus.net>
Message-ID: <5e01c29a0605041733w7d1c4c78l8bacd832f0daa855@mail.gmail.com>

>  Two important clarifications for Java (based on my experiments):
>
>  1) The verifier IS enabled for the classes that come with the Java
> platform, such as those in rt.jar.  So, for example, if you create a class
> that tries to set System.security (the private variable that points to the
> SecurityManager instance), you get a verification exception. (If this was
> possible, it would allow a complete bypass of the Java sandbox).
>  But with either Type Confusion attacks or with the Security Manager
> disabled, you can still completely bypass the Java Sandbox, right?
>
>
>
>
>
>
>  2) The verifier also seems to be enabled for classes running inside Tomcat.
> I'm not sure about other J2EE containers.
>
>  This is interesting, do you have any documentation to back this up? Ideally
> there would be a document somewhere which listed which J2EE containers run
> with the verifier on by default
>
>
>
>
>
>
>  So I don't think it's fair to say that most Java code is running without
> verification.
>  If all jsp out there is verified then yes 99% is not a correct number, any
> idea what percentage it could be?
>
>
>
>
>
>
>
>
>  But Denis is right. There is a real problem with verification, as
> demonstrated in the message below.  This is a clear violation of the Java VM
> Spec, yet my messages to the team at Sun developing the new verifier have
> been ignored.  And it's a real issue, given the number of applications that
> rely on libraries they didn't compile.  I don't think a real explanation of
> how the Sun verifier actually works is too much to ask, given the risk.
>  I agree, and Sun will probably do the same thing that Microsoft is doing at
> the moment: "Ignore the issue and hope that it goes away"

I don't think so; they've got their Crack the Verifier initiative; and
honestly, I don't think it's a big deal of verification isn't on by
default on the desktop vm; when you double-click a jar it runs in a
new vm, not with a current app you might also be running.

As long as j2ee containers (tomcat as Jeff says, websphere as I've
heard, and BEA WebLogic as someone else suggested) all run with
verification I don't think it's a big deal [but interesting to note],
is it?

FWIW I've seen this "issue" come up many many times in the java forums
and it's never taken this track. It's interesting to see it develop
this way ...

-- Michael



From stephen at corsaire.com  Thu May  4 22:03:22 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Fri, 05 May 2006 09:03:22 +0700
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
Message-ID: <445AB26A.4050207@corsaire.com>


Jim Halfpenny on the Webappsec list has discovered that BEA's JRockit
JDK _does_ use verification by default, his complete post quoted below
(the test was to access private methods on a class):


Hi,
BEA JRockit verifies by default and as far as I am aware does not offer a
-noverify option.

$ java -cp . verifytest2.Main
java.lang.IllegalAccessError: getName
        at verifytest2/Main.<init>()V(Main.java:???)
        at verifytest2/Main.main([Ljava/lang/String;)V(Main.java:12)

Tested with JRockit 1.4.2_08.

Regards,
Jim Halfpenny




From stephen at corsaire.com  Thu May  4 22:21:52 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Fri, 05 May 2006 09:21:52 +0700
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <445A3C1B.5070504@umd.edu>
References: <CF8B26B8B49184429CB084616B0019300244E363@itomae2km05.AD.QINTRA.COM>	<44596987.6020003@ddplus.net>
	<445A3C1B.5070504@umd.edu>
Message-ID: <445AB6C0.9090700@corsaire.com>

David Eisner wrote:

<snip some good research>
> 
> What determines when access to a private member is illegal?  Is it, in
> fact, the bytecode verifier? 

Yes, it's done by the fourth pass of the verifier as described here:
http://java.sun.com/sfaq/verifier.html#HEADING13

Interestingly, Sun have posted a contest to try and crack the new
verifier in Mustang:  https://jdk.dev.java.net/CTV/learn.html


-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com


From Greenarrow1 at msn.com  Thu May  4 21:35:00 2006
From: Greenarrow1 at msn.com (Greenarrow 1)
Date: Thu, 4 May 2006 18:35:00 -0700
Subject: [SC-L] HNS - Biggest X Window security hole since 2000
References: <Pine.LNX.4.21.0605041139540.11826-100000@linuxbox.org>
	<200605041337.59915@KRvW>
Message-ID: <BAY111-DAV12C346E70BC6504FBACBECF6B50@phx.gbl>

I noticed quite a lot of Linux distros have already patched this or are as I 
write.  Do not know if X Org has yet but remember a post by Securnia about 
this a day or so.

Regards,
George
Greenarrow1
InNetInvestigations-Forensic


----- Original Message ----- 
From: "Kenneth R. van Wyk" <Ken at krvw.com>
To: "Gadi Evron" <ge at linuxbox.org>
Cc: "Secure Coding" <SC-L at securecoding.org>
Sent: Thursday, May 04, 2006 10:37 AM
Subject: Re: [SC-L] HNS - Biggest X Window security hole since 2000


> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 


From ljknews at mac.com  Fri May  5 09:05:31 2006
From: ljknews at mac.com (ljknews)
Date: Fri, 5 May 2006 09:05:31 -0400
Subject: [SC-L] HNS - Biggest X Window security hole since 2000
In-Reply-To: <200605041112.59794@KRvW>
References: <200605041112.59794@KRvW>
Message-ID: <p05200f14c080fde575ba@[192.168.1.254]>

At 11:12 AM -0400 5/4/06, Kenneth R. van Wyk wrote:
> Content-Type: multipart/signed; boundary="nextPart1887150.2DlSXmIMA5";
> 	protocol="application/pgp-signature"; micalg=pgp-sha1
> Content-Transfer-Encoding: 7bit
> 
> Stories about this (below) X bug and the DHS-sponsored project that found it 
> have been floating around the net all week.  This story caught my eye, 
> though:
> 
> http://www.net-security.org/secworld.php?id=3994
> 
> The author claims, "This flaw, caused by something as seemingly harmless as a 
> missing closing parenthesis, allowed local users to execute code with root 

Certainly that part is OS-specific.  On my VMS machine, X-windows processes
do not run as root.

> privileges, giving them the ability to overwrite system files or initiate 
> denial of service attacks."
> 
> So, it sounds like a single byte change in the entire X src tree could fix a 
> bug that could give an attacker complete control of a system.  Lovely...
-- 
Larry Kilgallen


From gem at cigital.com  Fri May  5 10:12:24 2006
From: gem at cigital.com (Gary McGraw)
Date: Fri, 5 May 2006 10:12:24 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE6F2@va-mail.cigital.com>

An interesting experiment on cracking verifiers was performed about ten years ago by brian bershad at the university of washington.  The paradigm used comparative testing on multiple verifiers to find discrepancies.  

This is covered in securing java as well.

Funny how I became interested in software security because of java security.  We're coming full circle.

gem
www.cigital.com/~gem
www.swsec.com

 -----Original Message-----
From: 	Stephen de Vries [mailto:stephen at corsaire.com]
Sent:	Fri May 05 10:06:36 2006
To:	David Eisner
Cc:	'Secure Coding Mailing List'
Subject:	Re: [SC-L] By default, the Verifier is disabled on .Net and Java

David Eisner wrote:

<snip some good research>
> 
> What determines when access to a private member is illegal?  Is it, in
> fact, the bytecode verifier? 

Yes, it's done by the fourth pass of the verifier as described here:
http://java.sun.com/sfaq/verifier.html#HEADING13

Interestingly, Sun have posted a contest to try and crack the new
verifier in Mustang:  https://jdk.dev.java.net/CTV/learn.html


-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From Ken at krvw.com  Fri May  5 13:15:52 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Fri, 5 May 2006 13:15:52 -0400
Subject: [SC-L] WSJ.com - Tech Companies Check Software Earlier for Flaws
Message-ID: <200605051315.58939@KRvW>

I saw an interesting Wall Street Journal article today that talks about 
companies adopting software security practices.  Complete story can be found 
at:

http://online.wsj.com/public/article/SB114670277515443282-B59kll7qXrkxOXId1uF0txp8NFs_20070504.html?

The article cites a couple of companies that are starting to seriously use 
some static code analysis tools (Coverity and Fortify) to scan their src 
trees for security defects.  Although it doesn't address much in the way of 
design-time security activities, it's a good start and it's encouraging to 
see this sort of coverage in mainstream media.

I really liked this quote - "In effect, software makers are now admitting that 
their previous development process was faulty. While banks and other 
companies that deal with sensitive customer data began to build security into 
software development in the late 1990s, Microsoft Corp. and other software 
makers are only now in the middle of revamping their software-writing 
processes. "

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060505/b371ee72/attachment.bin 

From mark at markgraff.com  Sat May  6 13:19:46 2006
From: mark at markgraff.com (Mark Graff)
Date: Sat, 6 May 2006 10:19:46 -0700
Subject: [SC-L] Re: WSJ.com - Tech Companies Check Software
References: <200605061600.k46G03Q2040673@ratsass.krvw.com>
Message-ID: <00a801c67131$45d12b30$0301a8c0@TallTrees>

Fascinating and heartening development. Raises a couple of questions in my 
mind.

1. Why now? Many worthies, myself included during my years at Sun, have been 
crying for years/decades *from within the software industry* for just such a 
shift. So what has changed? Ken and I outlined in "Secure Coding" the 
economic forces that have militated against security quality. These forces 
still operate, I feel sure. The "Tragedy of the Commons", for example, is 
never going to be repealed. So what accounts for this shift, which I agree 
is happening, without (as I have so often predicted) the dramatic 
airliner-trapped-in-the-sky/girl-trapped-in-the-well TV moment catalyzing 
Congress critters into knee-jerk legislation?

The significant enabling event coming over the horizon seems to be the 
development of commerical quality and well-marketed tools.

Can it be that capitalism, which (more or less) created the problem, will 
also lead to its resolution? Perhaps. I have argued elsewhere that 
"unsecure" behavior like writing bad code is analogous to polluting the 
Internet. (I have proposed that "unsecurity credits", operating like 
pollution credits, be used by enterprises to cause departments to budget 
risk as they today budget other resources.) So maybe we are seeing the birth 
of entrepeneurial cyber-environmentalism. Has it passed through a stage of 
being the concern of "cranks" (us, I mean, esteeemed fellow travelers), to a 
"niche" concern, to be followed by being "trendy", then mainstream, and so 
on? Can we hope to live long enough to be condescended to as being 
passionate about only something "everybody knows" is dangerous?

2. What is the proper role of government to encourage/foster/exploit such a 
development? I take it for granted that, as the world's largest (I think) 
software customer, the U.S. federal government ought to show preference for 
products built using such tools, and that as the primary overseer of publicy 
traded North American companies, ought to require, via SEC rules, their 
internal use by such companies. I (with others) testified in this sense 
years ago. But let's take another look now at the question of security 
quality *metrics* and *standards*. As this group have often discussed, it's 
tough to envision. No more than 1 bug per thousand lines? Must withstand 
attacks from four high school students for three hours? Able to protect for 
24 hours an encrypted Swiss Bank Account worth a million dollars on a site 
accessible from the World Wide Web? Beats the heck out of me. But my 
question: what can and should government do, now that tools are emerging, to 
help us move toward measurement and standards? It happens that NIST (that's 
the U.S. National Institute of Standards and Technology) has a modest effort 
starting up to look into the state of the art of static checkers and so 
forth. I'm not competent to state here what the goals are, or should be, of 
NIST's current and future efforts should be. So I ask the group: does the 
advent (as it appears) of effective and easy-to-use tools mean that Now is 
The Time to push for Standards? If so, who but we "cyber-environmentalists" 
can lead the effort? And what's the next step?

-mg-

p.s. I apologize, btw, if my meanderings above recapitulate annoyingly 
threads here I have missed while attending to Other Concerns.
----- Original Message ----- 
From: <sc-l-request at securecoding.org>
To: <sc-l at securecoding.org>
Sent: Saturday, May 06, 2006 9:00 AM
Subject: SC-L Digest, Vol 2, Issue 69


> Send SC-L mailing list submissions to
> sc-l at securecoding.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> Message: 1
> Date: Fri, 5 May 2006 13:15:52 -0400
> From: "Kenneth R. van Wyk" <Ken at krvw.com>
> Subject: [SC-L] WSJ.com - Tech Companies Check Software Earlier for
> Flaws
> To: Secure Coding <SC-L at securecoding.org>
> Message-ID: <200605051315.58939 at KRvW>
> Content-Type: text/plain; charset="us-ascii"
>
> I saw an interesting Wall Street Journal article today that talks about
> companies adopting software security practices.  Complete story can be 
> found
> at:
>
> http://online.wsj.com/public/article/SB114670277515443282-B59kll7qXrkxOXId1uF0txp8NFs_20070504.html?
>
> The article cites a couple of companies that are starting to seriously use
> some static code analysis tools (Coverity and Fortify) to scan their src
> trees for security defects.  Although it doesn't address much in the way 
> of
> design-time security activities, it's a good start and it's encouraging to
> see this sort of coverage in mainstream media.
>
> I really liked this quote - "In effect, software makers are now admitting 
> that
> their previous development process was faulty. While banks and other
> companies that deal with sensitive customer data began to build security 
> into
> software development in the late 1990s, Microsoft Corp. and other software
> makers are only now in the middle of revamping their software-writing
> processes. "
>
> Cheers,
>
> Ken van Wyk
> -- 
> KRvW Associates, LLC
> http://www.KRvW.com



From mouse at Rodents.Montreal.QC.CA  Sun May  7 01:04:00 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Sun, 7 May 2006 01:04:00 -0400 (EDT)
Subject: [SC-L] HNS - Biggest X Window security hole since 2000
In-Reply-To: <p05200f14c080fde575ba@[192.168.1.254]>
References: <200605041112.59794@KRvW> <p05200f14c080fde575ba@[192.168.1.254]>
Message-ID: <200605070510.BAA19189@Sparkle.Rodents.Montreal.QC.CA>

>> The author claims, "This flaw, caused by something as seemingly
>> harmless as a missing closing parenthesis, allowed local users to
>> execute code with root
> Certainly that part is OS-specific.  On my VMS machine, X-windows
> processes do not run as root.

OS- and installation-specific.  Neither the above nor the article says
just which piece of X is responsible, but I don't think any X code runs
as root on my (NetBSD) machines unless I specifically do so, such as
starting a terminal emulator from a root shell.

>> So, it sounds like a single byte change in the entire X src tree
>> could fix a bug that could give an attacker complete control of a
>> system.  Lovely...

And, of course, nobody ever bothers to say just what the problem was.
Grrr.  (Fortunately, I don't care, since I am running pre-X11R6.9.0
code, or I'd be trying to chase down the diff.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


From rcs at cert.org  Mon May  8 08:58:54 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Mon, 08 May 2006 08:58:54 -0400
Subject: [SC-L] HNS - Biggest X Window security hole since 2000
In-Reply-To: <200605070510.BAA19189@Sparkle.Rodents.Montreal.QC.CA>
References: <200605041112.59794@KRvW> <p05200f14c080fde575ba@[192.168.1.254]>
	<200605070510.BAA19189@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <445F408E.9060307@cert.org>

der Mouse wrote:

> And, of course, nobody ever bothers to say just what the problem was.
> Grrr.  (Fortunately, I don't care, since I am running pre-X11R6.9.0
> code, or I'd be trying to chase down the diff.)

Bad code:

/* First the options that are only allowed for root */	
   if (getuid() == 0 || geteuid != 0) {
     if (!strcmp(argv[i], "-modulepath"))	

Good code:

/* First the options that are only allowed for root */
  if (getuid() == 0 || geteuid() != 0)  {
     if (!strcmp(argv[i], "-modulepath"))

The problem, of course, is that the address of geteuid is
always == true.

rCs

-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC

Work: 412-268-7608
FAX: 412-268-6989


From fw at deneb.enyo.de  Mon May  8 01:47:55 2006
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 08 May 2006 07:47:55 +0200
Subject: [SC-L] HNS - Biggest X Window security hole since 2000
In-Reply-To: <p05200f14c080fde575ba@[192.168.1.254]> (ljknews@mac.com's
	message of "Fri, 5 May 2006 09:05:31 -0400")
References: <200605041112.59794@KRvW> <p05200f14c080fde575ba@[192.168.1.254]>
Message-ID: <87u0811304.fsf@mid.deneb.enyo.de>

> Certainly that part is OS-specific.  On my VMS machine, X-windows processes
> do not run as root.

The X Window server needs elevated privileges because it can trigger
DMA on the graphics card (and thus read arbitrary memory, unless
you've got an IOMMU).  Chances are, however, that your VMS
implementation does not even support the Xrender extension.

Of course, the impact of this vulnerability is exaggerated in the
article.  Local privilege escalation vulnerabilties are numerous.


From tholleb at teknowledge.com  Mon May  8 13:08:31 2006
From: tholleb at teknowledge.com (Tim Hollebeek)
Date: Mon, 8 May 2006 10:08:31 -0700
Subject: [SC-L] HNS - Biggest X Window security hole since 2000
In-Reply-To: <200605070510.BAA19189@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <200605081655.k48GtTCn097679@ratsass.krvw.com>

 
> >> So, it sounds like a single byte change in the entire X src tree 
> >> could fix a bug that could give an attacker complete control of a 
> >> system.  Lovely...

For the curious out there, it isn't one byte, it's two.  It is a PAIR
of parenthesis that are missing, not a single one, like many of the
non-technical summaries imply.

Basically, the flaw is:

     if (getuid() == 0 || geteuid == 0)

doesn't do what you intended!

-Tim

P.S. Note that this can be considered a type error if you're pedantic
enough ... it requires:

(1) an OS that uses integral types as user identifiers
(2) a language that will implicitly convert functions to pointers
(3) a language that allows pointer comparisons to zero




From dinis at ddplus.net  Mon May  8 15:24:14 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Mon, 08 May 2006 20:24:14 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <11f401c66e5d$4084b290$9204a8c0@intranet.aspectsecurity.com>
References: <11f401c66e5d$4084b290$9204a8c0@intranet.aspectsecurity.com>
Message-ID: <445F9ADE.6080609@ddplus.net>

Jeff Williams wrote:
>
> But Dinis is right. There is a real problem with verification, as 
> demonstrated in the message below. This is a clear violation of the 
> Java VM Spec, yet my messages to the team at Sun developing the new 
> verifier have been ignored. And it?s a real issue, given the number of 
> applications that rely on libraries they didn?t compile. I don?t think 
> a real explanation of how the Sun verifier actually works is too much 
> to ask, given the risk.
>
And 9 days into this discussion, Sun's comment (or somebody from Sun) is 
still nowhere to be seen (Microsoft is not the online one MIA :).

Anybody had any luck with their off list attempts to get a comment on 
this issue? What about the main Java Application Server developers? 
WebSphere , WebLogic, JBoss, Enhydra, Blazix, Resin, JOnAS etc...

It is important that they participate in this discussion, because 
amongst other things I would like them to answer my next questions, 
which are:

"What is the point of the verifier?' , 'Why use it? and 'What are the 
real security advantages of enabling the verifier if the code is 
executed in an environment with the security manager disabled?'

So far we have identified several cases where:

* the Java verifier is NOT enabled by default

- Local code (i.e. loaded from the local system)

* the Java verifier is enabled by default

- classes that come with the Java platform
- classes running inside Tomcat
- classes running inside BEA WebLogic

Given that the main attack vector (to exploit the lack of verification) 
is the same for all cases mentioned above (the attack vector being the 
injection of malicious Java code on the application being executed) then 
I would like to know the reason for the inconsistency?

I also would like to ask if the following comments are correct:

Option A) 99% of the Java code deployed to live systems is executed in 
an environment with the verifier disabled

Option B) 99% of the Java code deployed to live systems is executed in 
an environment with the verifier disabled OR with the security manager 
disabled

If not, what value should Option A and B be? 10%, 50%, 75?

Thanks for your comments

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net



From dinis at ddplus.net  Mon May  8 14:43:34 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Mon, 08 May 2006 19:43:34 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <6D732530-ECD0-47D9-9F3C-48A16019E6E4@corsaire.com>
References: <4457EFC3.4090605@ddplus.net>
	<6D732530-ECD0-47D9-9F3C-48A16019E6E4@corsaire.com>
Message-ID: <445F9156.1040206@ddplus.net>

Stephen de Vries wrote:
> Java has implemented this a bit differently, in that the byte code 
> verifier and the security manager are independent.  So you could for 
> example, run an application with an airtight security policy (equiv to 
> partial trust), but it could still be vulnerable to type confusion 
> attacks if the verifier was not explicitly enabled.  To have both 
> enabled you'd need to run with:
> java -verify -Djava.security.policy ...
This is a very weird decision by the Java Architects, since what is the 
point of creating and enforcing a airtight security policy if you can 
jump strait out of it via a Type Confusion attack?

In fact, I would argue that you can't really say that you have an 
'airtight security' policy if the verifier is not enabled!

Right?

Is there a example out there where (by default) java code is executed in 
an environment with :

    * the security manager enabled (with a strong security policy) and
    * the verifier disabled

Dinis Cruz
Owasp .Net Project
www.owasp.net




From Kevin.Wall at qwest.com  Mon May  8 19:08:24 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Mon, 8 May 2006 18:08:24 -0500
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
Message-ID: <CF8B26B8B49184429CB084616B0019300244E387@itomae2km05.AD.QINTRA.COM>

Dinis Cruz writes...

> Stephen de Vries wrote:
> > Java has implemented this a bit differently, in that the byte code 
> > verifier and the security manager are independent.  So you could for

> > example, run an application with an airtight security policy (equiv
to 
> > partial trust), but it could still be vulnerable to type confusion 
> > attacks if the verifier was not explicitly enabled.  To have both 
> > enabled you'd need to run with:
> > java -verify -Djava.security.policy ...
> This is a very weird decision by the Java Architects, since what is
the 
> point of creating and enforcing a airtight security policy if you can 
> jump strait out of it via a Type Confusion attack?
> 
> In fact, I would argue that you can't really say that you have an 
> 'airtight security' policy if the verifier is not enabled!
> 
> Right?
> 
> Is there a example out there where (by default) java code is 
> executed in an environment with :
> 
>     * the security manager enabled (with a strong security policy) and
>     * the verifier disabled

Just a hunch, but I suspect that it was designed this way to support
mobile code, or more specifically applets. There is a security manager
enabled (policy not airtight though; see McGraw/Felten's book on the
subject)
with applets, and the byte code verifier only verifies *remotely* loaded
classes,
which are the only ones presumed to be hostile. Dumb assumption, I know,
but
initially applets ran so slow, Sun probably had little choice if they
hoped
to "sell" applets. Besides, back then most of the hostile code WAS
coming
from different attack vectors--infected floppies or ftp'ing / running
infected code. AV software monitored that attack vector, but not
executable
code coming in via HTTP through your browser. (Many do today, though.)
But the assumption Sun made back then was that all locally loaded
classes
could be trusted and therefore were type-safe.

In retrospect, several wrong decisions were made regarding web security.
(Don't
even get me started on Radio-ActiveX! ;-) But as they say, backward
compatibility
is the curse of software design, so we probably are stuck with it.

Fortunately the verifier is pretty simple to enable in Java. OTOH,
coming
up with a good security policy is not so easy. I've only done it twice
and
it's been a laborious process each time assuming you start with
essentially
a fail-safe "no permissions" approach and only add permissions
as-needed.

Anyway, I'd say that applets were probably what drove this security
model. Curious
that applets probably now comprise less than %1 of all Java code today.

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
<... add your favorite pithy quote about hindsight here ...>


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.



From gem at cigital.com  Mon May  8 19:22:50 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 8 May 2006 19:22:50 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE779@va-mail.cigital.com>

That's essentially correct kevin.  The idea was to be able to run not remote, but untrusted code.  Note that modern readers will understand that local code can be untrusted.  There is a good picture of this in securing java.

gem

 -----Original Message-----
From: 	Wall, Kevin [mailto:Kevin.Wall at qwest.com]
Sent:	Mon May 08 19:17:22 2006
To:	Dinis Cruz; Stephen de Vries
Cc:	Secure Coding Mailing List
Subject:	RE: [SC-L] By default, the Verifier is disabled on .Net and Java

Dinis Cruz writes...

> Stephen de Vries wrote:
> > Java has implemented this a bit differently, in that the byte code 
> > verifier and the security manager are independent.  So you could for

> > example, run an application with an airtight security policy (equiv
to 
> > partial trust), but it could still be vulnerable to type confusion 
> > attacks if the verifier was not explicitly enabled.  To have both 
> > enabled you'd need to run with:
> > java -verify -Djava.security.policy ...
> This is a very weird decision by the Java Architects, since what is
the 
> point of creating and enforcing a airtight security policy if you can 
> jump strait out of it via a Type Confusion attack?
> 
> In fact, I would argue that you can't really say that you have an 
> 'airtight security' policy if the verifier is not enabled!
> 
> Right?
> 
> Is there a example out there where (by default) java code is 
> executed in an environment with :
> 
>     * the security manager enabled (with a strong security policy) and
>     * the verifier disabled

Just a hunch, but I suspect that it was designed this way to support
mobile code, or more specifically applets. There is a security manager
enabled (policy not airtight though; see McGraw/Felten's book on the
subject)
with applets, and the byte code verifier only verifies *remotely* loaded
classes,
which are the only ones presumed to be hostile. Dumb assumption, I know,
but
initially applets ran so slow, Sun probably had little choice if they
hoped
to "sell" applets. Besides, back then most of the hostile code WAS
coming
from different attack vectors--infected floppies or ftp'ing / running
infected code. AV software monitored that attack vector, but not
executable
code coming in via HTTP through your browser. (Many do today, though.)
But the assumption Sun made back then was that all locally loaded
classes
could be trusted and therefore were type-safe.

In retrospect, several wrong decisions were made regarding web security.
(Don't
even get me started on Radio-ActiveX! ;-) But as they say, backward
compatibility
is the curse of software design, so we probably are stuck with it.

Fortunately the verifier is pretty simple to enable in Java. OTOH,
coming
up with a good security policy is not so easy. I've only done it twice
and
it's been a laborious process each time assuming you start with
essentially
a fail-safe "no permissions" approach and only add permissions
as-needed.

Anyway, I'd say that applets were probably what drove this security
model. Curious
that applets probably now comprise less than %1 of all Java code today.

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
<... add your favorite pithy quote about hindsight here ...>


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From michaelslists at gmail.com  Mon May  8 20:13:37 2006
From: michaelslists at gmail.com (Michael Silk)
Date: Tue, 9 May 2006 10:13:37 +1000
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <445F9ADE.6080609@ddplus.net>
References: <11f401c66e5d$4084b290$9204a8c0@intranet.aspectsecurity.com>
	<445F9ADE.6080609@ddplus.net>
Message-ID: <5e01c29a0605081713i6eabeabx824a0fc2bd77be8e@mail.gmail.com>

On 5/9/06, Dinis Cruz <dinis at ddplus.net> wrote:
> Jeff Williams wrote:
> >
> > But Dinis is right. There is a real problem with verification, as
> > demonstrated in the message below. This is a clear violation of the
> > Java VM Spec, yet my messages to the team at Sun developing the new
> > verifier have been ignored. And it's a real issue, given the number of
> > applications that rely on libraries they didn't compile. I don't think
> > a real explanation of how the Sun verifier actually works is too much
> > to ask, given the risk.
> >
> And 9 days into this discussion, Sun's comment (or somebody from Sun) is
> still nowhere to be seen (Microsoft is not the online one MIA :).
>
> Anybody had any luck with their off list attempts to get a comment on
> this issue? What about the main Java Application Server developers?
> WebSphere , WebLogic, JBoss, Enhydra, Blazix, Resin, JOnAS etc...
>
> It is important that they participate in this discussion, because
> amongst other things I would like them to answer my next questions,
> which are:
>
> "What is the point of the verifier?' , 'Why use it? and 'What are the
> real security advantages of enabling the verifier if the code is
> executed in an environment with the security manager disabled?'

Huh? You can find what it does here:

http://java.sun.com/sfaq/verifier.html

The security manager and the verifier are different.

The security manager allows you to restrict runtime-knowledge type
things. Connecting a socket, opening a file, exiting the vm, and so
on.

The verifier deals with other things. As you know, right?


> So far we have identified several cases where:
>
> * the Java verifier is NOT enabled by default
>
> - Local code (i.e. loaded from the local system)
>
> * the Java verifier is enabled by default
>
> - classes that come with the Java platform
> - classes running inside Tomcat
> - classes running inside BEA WebLogic
>
> Given that the main attack vector (to exploit the lack of verification)
> is the same for all cases mentioned above (the attack vector being the
> injection of malicious Java code on the application being executed) then
> I would like to know the reason for the inconsistency?
>
> I also would like to ask if the following comments are correct:
>
> Option A) 99% of the Java code deployed to live systems is executed in
> an environment with the verifier disabled
>
> Option B) 99% of the Java code deployed to live systems is executed in
> an environment with the verifier disabled OR with the security manager
> disabled

I'd say no. We already know BEA/Tomcat/(And from my knowledge
Websphere) all run with verification ON by default. All these 3 don't
take up only "1%" of all java code.


> If not, what value should Option A and B be? 10%, 50%, 75?

Download the app servers and check the documentation? I'd guess most
have it on by default. Not off. Just my guess though ...

-- Michael



From michaelslists at gmail.com  Mon May  8 20:16:55 2006
From: michaelslists at gmail.com (Michael Silk)
Date: Tue, 9 May 2006 10:16:55 +1000
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <445F9156.1040206@ddplus.net>
References: <4457EFC3.4090605@ddplus.net>
	<6D732530-ECD0-47D9-9F3C-48A16019E6E4@corsaire.com>
	<445F9156.1040206@ddplus.net>
Message-ID: <5e01c29a0605081716o9d37a2ao2ca7e6a3884461bf@mail.gmail.com>

On 5/9/06, Dinis Cruz <dinis at ddplus.net> wrote:
> Stephen de Vries wrote:
> > Java has implemented this a bit differently, in that the byte code
> > verifier and the security manager are independent.  So you could for
> > example, run an application with an airtight security policy (equiv to
> > partial trust), but it could still be vulnerable to type confusion
> > attacks if the verifier was not explicitly enabled.  To have both
> > enabled you'd need to run with:
> > java -verify -Djava.security.policy ...
>
> This is a very weird decision by the Java Architects, since what is the
> point of creating and enforcing a airtight security policy if you can
> jump strait out of it via a Type Confusion attack?
>
> In fact, I would argue that you can't really say that you have an
> 'airtight security' policy if the verifier is not enabled!

You can't disable the security manager even with the verifier off. But
you could extend some final or private class that the security manager
gives access to.


> Is there a example out there where (by default) java code is executed in
> an environment with :
>
>     * the security manager enabled (with a strong security policy) and
>     * the verifier disabled

Yes. Your local JRE.

-- Michael



From gem at cigital.com  Tue May  9 10:39:04 2006
From: gem at cigital.com (Gary McGraw)
Date: Tue, 9 May 2006 10:39:04 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE793@va-mail.cigital.com>

The switch from "applets vs applications" security to "trusted code vs untrusted code" happened with the introduction of jdk 1.1 (way back when).   Ed and I followed the sun marketing lead in 96 when it came to applets vs applications, but we cleared this up later in Securing Java www.securingjava.com.

gem
www.swsec.com

 -----Original Message-----
From: 	Wall, Kevin [mailto:Kevin.Wall at qwest.com]
Sent:	Mon May 08 19:17:22 2006
To:	Dinis Cruz; Stephen de Vries
Cc:	Secure Coding Mailing List
Subject:	RE: [SC-L] By default, the Verifier is disabled on .Net and Java

Dinis Cruz writes...

> Stephen de Vries wrote:
> > Java has implemented this a bit differently, in that the byte code 
> > verifier and the security manager are independent.  So you could for

> > example, run an application with an airtight security policy (equiv
to 
> > partial trust), but it could still be vulnerable to type confusion 
> > attacks if the verifier was not explicitly enabled.  To have both 
> > enabled you'd need to run with:
> > java -verify -Djava.security.policy ...
> This is a very weird decision by the Java Architects, since what is
the 
> point of creating and enforcing a airtight security policy if you can 
> jump strait out of it via a Type Confusion attack?
> 
> In fact, I would argue that you can't really say that you have an 
> 'airtight security' policy if the verifier is not enabled!
> 
> Right?
> 
> Is there a example out there where (by default) java code is 
> executed in an environment with :
> 
>     * the security manager enabled (with a strong security policy) and
>     * the verifier disabled

Just a hunch, but I suspect that it was designed this way to support
mobile code, or more specifically applets. There is a security manager
enabled (policy not airtight though; see McGraw/Felten's book on the
subject)
with applets, and the byte code verifier only verifies *remotely* loaded
classes,
which are the only ones presumed to be hostile. Dumb assumption, I know,
but
initially applets ran so slow, Sun probably had little choice if they
hoped
to "sell" applets. Besides, back then most of the hostile code WAS
coming
from different attack vectors--infected floppies or ftp'ing / running
infected code. AV software monitored that attack vector, but not
executable
code coming in via HTTP through your browser. (Many do today, though.)
But the assumption Sun made back then was that all locally loaded
classes
could be trusted and therefore were type-safe.

In retrospect, several wrong decisions were made regarding web security.
(Don't
even get me started on Radio-ActiveX! ;-) But as they say, backward
compatibility
is the curse of software design, so we probably are stuck with it.

Fortunately the verifier is pretty simple to enable in Java. OTOH,
coming
up with a good security policy is not so easy. I've only done it twice
and
it's been a laborious process each time assuming you start with
essentially
a fail-safe "no permissions" approach and only add permissions
as-needed.

Anyway, I'd say that applets were probably what drove this security
model. Curious
that applets probably now comprise less than %1 of all Java code today.

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
<... add your favorite pithy quote about hindsight here ...>


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Tue May  9 15:02:40 2006
From: gem at cigital.com (Gary McGraw)
Date: Tue, 9 May 2006 15:02:40 -0400
Subject: [SC-L] Tech target interview
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE7C0@va-mail.cigital.com>


Hi all,

Today's interview speaks to software security touchpoints:
http://searchappsecurity.techtarget.com/qna/0,289202,sid92_gci1187360,00.html

gem
www.cigital.com/~gem
www.swsec.com


Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From dinis at ddplus.net  Tue May  9 20:22:01 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Wed, 10 May 2006 01:22:01 +0100
Subject: [SC-L] Why Novell should take on the 'type-safe platform' challenge
In-Reply-To: <445DD58E.6030408@novell.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE5C4@va-mail.cigital.com>
	<4456AB5D.6010804@ddplus.net> <445DD58E.6030408@novell.com>
Message-ID: <44613229.20801@ddplus.net>

Dinis Cruz wrote:

 > The ones that I wish were listening are Novell and the Mono project.
 > The path to a type-safe platform could start there.

Following this comment made on the previous thread, here are the reasons 
why I wished Novell and the Mono project where listening to that 
conversation (note: an edited version of this post was sent directly to 
several Novell contacts who asked me 'What is it you wish we would 
listen to?' :

---------------------------------

Dear Novell

What I meant by my comment, is that there is an opportunity today (2006) 
for somebody (namely a company + community) to really grab the 
'type-safe' + 'sandboxing' flag and run with it.

Here is a quick analysis of where we stand today:

    - Vista failed to deliver a OS based on a type-safe platform
    - 99% (or close) of the .Net Framework and Java code is executed in 
an environment with no sandbox (i.e. executed: a) in Full Trust, or b) 
with the Security manager disabled, or c) with no verification). Given 
the amount of code deployed out there, there is no chance that a real 
change will occur any time soon. Currently there is no interest from 
Microsoft or Sun to address this issue and invest the time, energy and 
resources required to solve it.
    - Microsoft failed to make the paradigm shift from Full Trust to 
Partial Trust when they released v2.0 of the .Net Framework (which would 
had been the perfect time to do it)
    - There is good grass roots support for type-safety
    - There is a growing need to create secure and trustworthy 
applications (with growing support from Governments, Large Corporations 
and ultimately the end users)
    - Sandboxing at the OS level, like the one in Vista's 'Integrity 
Level / Privilege Isolation' and in Suse's AppArmour (sorry Crispin for 
not replying to your posts on the previous SC discussion about 
Sandboxing (it is on my to-do-list)) will NOT prevent exploitation of 
the user's assets (like for example the user's email). These techniques 
are designed to 'control' and 'Sandbox' unmanaged code, which is 
something that I don't believe can be done today. A short term solution 
(before we get to type-safe OS) would be to have environments like these 
(which do add some security protection to the OS) supported by a 
managed/verifiable environment responsible for executing the 
managed/verifiable  (potentially malicious) code.
    - Apple has an amazing OS (which I am using at the moment) but 
doesn't seem to be focused on type-safe / sandboxing issues too. Apple 
also seems to (like most of the Open Source community) think that it is 
immune to security vulnerabilities (just look at the way they handle 
security patches at the moment)
    - Novell has gained a huge amount of respect for its support for the 
Mono-Project and for its support for Open Source
    - Basically, Microsoft has lost the plot on Security and (as Gary 
McGraw says) is too focused on bugs and not on architecture. They 
(Microsoft) will have tough times ahead when Vista proves to be as 
secure as XP SP2 was.
    - IBM has seen the future and is re-organizing itself around the 
concept of 'delivering enterprise solutions on top of Open Systems and 
Open Architectures'

So, like I said above, there is a big opportunity for an Open Source 
project, lead by a major company and based on a solid platform, to lead 
the way in the move from unmanaged/unsafe code (where I am including 
Full Trust .Net code in this category) to managed, verifiable and 
type-safe code (which can be safely executed in Sandboxes and malicious 
activity easily detected / mitigated)

Novell and Mono fits this bill perfectly.

And it would also give mono an unique point of sell, since at the moment 
it is still a 'pour cousin of the .Net Framework'.

Ultimately the goal would be to build an OS on of top of a type-safe 
platform. But before that the user-land world needs to be conquered.

A lot of research and effort must be placed on how to create powerful, 
feature-rich and fast GUI applications built on type-safe code. This is 
something that can only be done by a large community focused on a 
powerful goal: *creating secure applications for execution on 
secure/sandboxed environments.*

Imagine if this idea could be developed to such a state where (on 
Windows) it would be safer to execute C# applications on Mono than on 
the .Net Framework itself! (another area where mono could do really well 
is in Hosting of Asp.Net applications (for example based on a Linux 
distribution of a LAMM environment, hosted by a VirtualServer or VMware 
host))

I believe that we are watching today the limitations, of both Open 
Source world (with its 'many eyeballs') and Proprietary Code (with its 
Secure Development Lifecycle) to create code that doesn't contain 
critical security vulnerabilities (i.e. both can't do it (with maybe 
some notable exceptions)).

What is needed is a new paradigm (well not that new if you ask Gary 
McGraw) that *creates a financial-model that rewards the companies that 
are able to create secure applications that can be executed on secure 
environments *(the idea is not to prevent bugs/vulnerabilities from 
existing, but to prevent the damage caused by their exploitation).

Ultimately all source-code will have to be released and made public (not 
necessarily on an Open Source format, but at least available to peer 
review and external (i.e. independent) analysis) , and again here Novell 
and the other Open Source development companies have an advantage.

The other major asset which the Open Source distributions have (and one 
which will be crucial in the future) is the centralized distribution of 
Software (i.e. packages). In the future we will need entities that 
certify the security of Software applications, which in an 
unmanaged-code world (for example: C++ & Full Trust .Net ) is almost 
impossible to do (i.e. say for sure that Application XYZ does not 
contain a keyboard hook and direct access to the Internet), but quite 
possible in a managed, type-safe and verifiable world.

Of course that more CLRs (with custom GC, Security managers, Class 
loaders, verifiers, etc...) will need to be build, since the 
requirements of a powerful Windows Application, are very different from 
an Asp.Net Form, which are very different from a Device Driver.

Looking forward to your comments,

Best regards,

Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060510/8077a017/attachment.html 

From dinis at ddplus.net  Wed May 10 18:23:48 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Wed, 10 May 2006 23:23:48 +0100
Subject: [SC-L] Black Hat class: Advanced Asp.Net Exploits and
	Countermeasures
Message-ID: <446267F4.2010001@ddplus.net>

<Shameless Plug (with permission from SC-L moderator :)>

For the ones that are going to the next Black Hat in Vegas, I am 
delivering a two day course based on my .Net research which some of you 
might want to attend (or recommend to somebody).

You can read the relevant details at the end of this email or directly 
on http://www.blackhat.com/html/bh-usa-06/train-bh-us-06-io-net.html.

Dinis Cruz
Owasp .Net Project
www.owasp.net




Title: Advanced Asp.Net Exploits and Countermeasures

Overview:

In this 2 day course you will push Asp.Net to the limit and will be 
shown how Asp .NET applications and environments can be exploited by
skilled attackers. Advanced exploitation techniques will be presented 
together with low-level technical analysis of the .Net Framework. You
will also learn advanced defense techniques such as: Building an Asp 
.NET Security Protection layer (also called a Web Application Firewall)
and Real time patching of vulnerabilities in the target application, the 
..Net Framework or the CLR."

Structure:

The Course is made of 4 modules (2 per day, one in the morning and one 
in the afternoon)

Module 1: Security principles and .NET Framework Architecture

Module 2: Guerrilla Threat Modeling and Exploiting Asp.Net Applications

    * Using quick-and-dirty threat models to discover vulnerabilities 
in the target application
    * Exploiting vulnerabilities in Asp.Net applications: Data 
Validation, Authorization, Authentication, SessionState, XSS, Cookies, 
AJAX, Web Services, Remoting, etc.. (using basic and advanced techniques)
    * Exploiting Buffer Overflows and Windows vulnerabilities via 
Asp.Net Applications


Module 3: Exploiting Full Trust and Partial Trust Asp.Net Environments

    * Practical demonstrations of the power of Full Trust Asp.Net: 
Rooting the CLR (e.g. patching the .Net Framework and CLR), Reflection,
    * IIS Metabase, Shellcode injection, Launching internal attacks to 
compromise the server and the data center
    * Full Trust non-verification and Type Safety attacks (via MSIL 
manipulation)
    * Exploiting Insecure Partial Trust Asp.Net Environments

Module 4: Advanced Asp.Net Countermeasures

    * Applying real-time security patches in the target application, 
.Net Framework and CLR
    * Solutions to create secure Data Validation and Authorization 
architectures
    * Creating secure Asp.Net hosting environments
    * Building an Asp.Net Security Protection layer (also called web 
Application Firewall);
    * Using Mono

You will walk away from this class with a much better understanding of 
some of the weaknesses of .NET applications, particularly the internals 
of the .NET framework. You will also get the chance to put your skills 
to the test against a target application over the course of the class.

Requirements:

A laptop with VMWare Player pre-installed. A VMWare image containing all 
necessary lab tools will be provided.

Prerequisites:

This is an advanced course targeted at industry professionals who want 
to understand the weaknesses and the power of the .Net Framework.

To get the most of this course and to be able to do the extensive 
practice material provided (using a VMWare image), the participants must:

    * Have a good understanding of a .NET Language (Ideally C#)
    * Be familiar with MSIL/Assembly
    * Have some experience with debugging user-land applications
    * Have commercial experience on either application development or 
security auditing.

The material is presented at a pace adjusted for experienced developers 
and/or security consultants.


Trainer:

Dinis Cruz is a Senior IOActive Security Consultant based in London (UK) 
and specialized in: ASP.NET Application Security, Active Directory 
deployments, Application Security audits and .NET Security Curriculum 
Development.

Since the 1.1 release of the .Net Framework, Dinis has been one of the 
strongest proponents of the need to write .Net applications that can be 
executed in secure Partially Trusted .Net environments, and has done 
extensive research on: Rooting the CLR, exposing the dangers of Full 
Trust Asp.Net Code, Type Confusion vulnerabilities in Full Trust (i.e. 
non verifiable) code, creating .Net Security Protection Layers and using 
Reflection to dynamically manipulate .Net Client applications.

Dinis is also the current Owasp .Net Project leader and the main 
developer of several of OWASP .Net tools (SAM'SHE, ANBS, SiteGenerator, 
PenTest Reporter, Asp.Net Reflector, Online IIS Metabase Explorer).


</Shameless Plug>





From stephen at corsaire.com  Thu May 11 00:54:10 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Thu, 11 May 2006 11:54:10 +0700
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <5e01c29a0605081716o9d37a2ao2ca7e6a3884461bf@mail.gmail.com>
References: <4457EFC3.4090605@ddplus.net>	
	<6D732530-ECD0-47D9-9F3C-48A16019E6E4@corsaire.com>	
	<445F9156.1040206@ddplus.net>
	<5e01c29a0605081716o9d37a2ao2ca7e6a3884461bf@mail.gmail.com>
Message-ID: <4462C372.8080307@corsaire.com>

Michael Silk wrote:
> On 5/9/06, Dinis Cruz <dinis at ddplus.net> wrote:

<snip>

> 
>> Is there a example out there where (by default) java code is executed in
>> an environment with :
>>
>>     * the security manager enabled (with a strong security policy) and
>>     * the verifier disabled
> 
> Yes. Your local JRE.

...but only in the exceptional case where a local Java application was
started with a security manager activated, but without the -verify flag
enabled.
Most local Java applications are started without the verifier enabled
and without a security manager.

For untrusted applets and webstart apps, both the verifier and a
security manager are enabled.



-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com



From jeff.williams at aspectsecurity.com  Thu May 11 09:08:29 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Thu, 11 May 2006 09:08:29 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <4462C188.9030904@corsaire.com>
Message-ID: <007401c674fc$0276ab70$8a04a8c0@intranet.aspectsecurity.com>

Stephen de Vries wrote:
> With application servers such as Tomcat, WebLogic etc, I think we have a
> special case in that they don't run with the verifier enabled - yet they
> appear to be safe from type confusion attacks.  (If you check the
> startup scripts, there's no mention of running with -verify).

You're right -- I checked that too.  So I think it's just too simple to talk
about the verifier being either on or off.  It appears to me that the
verifier can be enabled for some code and not for other code.  I think
you're right that this behavior has something to do with the classloader
that is used, but I'd really like to understand exactly what the rules are.

--Jeff




From michaelslists at gmail.com  Thu May 11 09:59:41 2006
From: michaelslists at gmail.com (Michael Silk)
Date: Thu, 11 May 2006 23:59:41 +1000
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <007401c674fc$0276ab70$8a04a8c0@intranet.aspectsecurity.com>
References: <4462C188.9030904@corsaire.com>
	<007401c674fc$0276ab70$8a04a8c0@intranet.aspectsecurity.com>
Message-ID: <5e01c29a0605110659q4f52314ch19f72f7d7db96270@mail.gmail.com>

The "verifier" is enabled via the commandline. It is either on or off.

the VM does other forms of "verification" though.

http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79383

...

-- Michael

On 5/11/06, Jeff Williams <jeff.williams at aspectsecurity.com> wrote:
> Stephen de Vries wrote:
> > With application servers such as Tomcat, WebLogic etc, I think we have a
> > special case in that they don't run with the verifier enabled - yet they
> > appear to be safe from type confusion attacks.  (If you check the
> > startup scripts, there's no mention of running with -verify).
>
> You're right -- I checked that too.  So I think it's just too simple to talk
> about the verifier being either on or off.  It appears to me that the
> verifier can be enabled for some code and not for other code.  I think
> you're right that this behavior has something to do with the classloader
> that is used, but I'd really like to understand exactly what the rules are.
>
> --Jeff
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>



From cradle at umd.edu  Thu May 11 12:21:46 2006
From: cradle at umd.edu (David Eisner)
Date: Thu, 11 May 2006 12:21:46 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <5e01c29a0605110659q4f52314ch19f72f7d7db96270@mail.gmail.com>
References: <4462C188.9030904@corsaire.com>	<007401c674fc$0276ab70$8a04a8c0@intranet.aspectsecurity.com>
	<5e01c29a0605110659q4f52314ch19f72f7d7db96270@mail.gmail.com>
Message-ID: <4463649A.7000006@umd.edu>

Michael Silk wrote:
> The "verifier" is enabled via the commandline. It is either on or off.

I'm not sure that's true.  See:

    http://securecoding.org/pipermail/sc-l/2006/000262.html

Summary: there are *three* comandline options: -verify, -noverify, and
-verifyremote.  It is -verifyremote that is the default, which only
verifies "remote" code.  However, the definition of "remote" depends on
which of the four phases [1] of verification are being performed.

-David

[1]
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#9766




From dinis at ddplus.net  Fri May 12 03:58:11 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Fri, 12 May 2006 08:58:11 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
 
In-Reply-To: <5e01c29a0605081716o9d37a2ao2ca7e6a3884461bf@mail.gmail.com>
References: <4457EFC3.4090605@ddplus.net>	
	<6D732530-ECD0-47D9-9F3C-48A16019E6E4@corsaire.com>	
	<445F9156.1040206@ddplus.net>
	<5e01c29a0605081716o9d37a2ao2ca7e6a3884461bf@mail.gmail.com>
Message-ID: <44644013.7090206@ddplus.net>

Michael Silk wrote:
> You can't disable the security manager even with the verifier off. But
> you could extend some final or private class that the security manager
> gives access to.
This is not correct. With the verifier disabled there are multiple ways 
you can jump out of the Security Manager Sandbox.

Here is a quote from 1997's Java Security 
<http://www.cigital.com/javasecurity/preface.html> (Gary McGraw and 
Eduard W. Feltern) book, page 75, Chapter Three 'Serious Holes in the 
Security Model"
/
"... *The Type Confusion Tool Kit *The Princeton team, as a feasibility 
demonstration, created a tool kit that allows any type confusion attack 
to be turned into a disarming of Java's security. In other words, the 
tool kit servers as a way of turning a small security breach into a 
complete system penetration. The type confusion tool kit has not been 
released to the public, and is considered to dangerous to describe in 
any detail here..."

/A variation of this quote can also at the bottom of this page: Section 
7 -- You're Not My Type 
<http://www.securingjava.com/chapter-five/chapter-five-7.html>/

/Another quote from Section 7 -- You're Not My Type 
<http://www.securingjava.com/chapter-five/chapter-five-7.html>/
/

/"...As mentioned in Chapter 2 
<http://www.securingjava.com/chapter-two/>, every aspect of Java 
security depends critically on the type-safety of the language. This 
means that if Java is going to be secure, it has to make sure that all 
pointers are properly tagged; that is, the tag must match the actual 
type of object that is being pointed to./

/In a type-confusion attack, a malicious applet creates two pointers to 
the same object-with incompatible type tags. When this happens, the Java 
system is in trouble. The applet can write into that memory address 
through one pointer, and read it through another pointer. The result is 
that the applet can bypass the typing rules of Java, completely 
undermining its security...."/

The example that we have been playing around here (the direct access to 
a private member) is probably not the best one to use to test the 
verifier, since there are multiple ways that this type of illegal access 
can be 'accidentally' detected by the VM (in Java there are some cases 
where the class loading process detects this, and in .Net the JIT will 
catch it)

I think that it will be better to use the examples shown in the 
brilliant LSD paper http://lsd-pl.net/papers.html#java or a variation of 
the ones I discovered in .Net:

    * Possible Type Confusion issue in .Net 1.1 (only works in
      FullTrust)
      (http://owasp.net/blogs/dinis_cruz/archive/2005/11/08/36.aspx)
    * Another Full Trust CLR Verification issue: Exploiting Passing
      Reference Types by Reference
      (http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/393.aspx)
    * Another Full Trust CLR Verification issue: Changing Private Field
      using Proxy Struct
      (http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/394.aspx)
    * Another Full Trust CLR Verification issue: changing the Method
      Parameters order
      (http://owasp.net/blogs/dinis_cruz/archive/2005/12/26/390.aspx)

In fact, it would be great to have a 'verifier checker' tool. A set of 
scripts that would test for verifier issues on Java execution 
environments (this would make it very easy to detect who is using the 
verifier and what type of verification is performed).

After this explanation, Stephen, do you still disagree with my original 
comments:
/
"This is a very weird decision by the Java Architects, since what is the 
point of creating and enforcing a airtight security policy if you can 
jump strait out of it via a Type Confusion attack?

In fact, I would argue that you can't really say that you have an 
'airtight security' policy if the verifier is not enabled!" /

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060512/d3ee5386/attachment.html 

From dinis at ddplus.net  Fri May 12 04:04:47 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Fri, 12 May 2006 09:04:47 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <200605041745.k44HjP7l086666@ratsass.krvw.com>
References: <200605041745.k44HjP7l086666@ratsass.krvw.com>
Message-ID: <4464419F.1070208@ddplus.net>

Tim Hollebeek wrote:
>> $ java -cp . -noverify HelloWorld
>> #
>> # An unexpected error has been detected by HotSpot Virtual Machine:
>> #
>> #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d7415fb, 
>> pid=3512, tid=2260 # # Java VM: Java HotSpot(TM) Client VM 
>> (1.5.0_06-b05 mixed mode) # Problematic frame:
>> # V  [jvm.dll+0x615fb]
>>     
>
>
> Note that EXCEPTION_ACCESS_VIOLATION is the Windows equivalent of a
> segmentation violation; this isn't the Verifier complaining, it's
> the JVM crashing.
>   
Yes, I noticed that too, the byte manipulation created a situation that 
crashed the VM.

Usually these type of errors are caused by Buffer Overflows, so this 
could be a good example of how -noverify java code can be used to take 
over the local JVM process

Depending of where the exploit is placed, there is even a possibility 
that the Java ByteCode will not be affected (which would difficult the 
detection of this exploit by (for example) source code security analyzers).

Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060512/97d9cbae/attachment.html 

From dinis at ddplus.net  Fri May 12 04:30:10 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Fri, 12 May 2006 09:30:10 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <5e01c29a0605081713i6eabeabx824a0fc2bd77be8e@mail.gmail.com>
References: <11f401c66e5d$4084b290$9204a8c0@intranet.aspectsecurity.com>	
	<445F9ADE.6080609@ddplus.net>
	<5e01c29a0605081713i6eabeabx824a0fc2bd77be8e@mail.gmail.com>
Message-ID: <44644792.6090702@ddplus.net>

Michael Silk wrote:
>> "What is the point of the verifier?' , 'Why use it? and 'What are the
>> real security advantages of enabling the verifier if the code is
>> executed in an environment with the security manager disabled?'
>
> Huh? You can find what it does here:
>
> http://java.sun.com/sfaq/verifier.html
>
> The security manager and the verifier are different.
Of course they are, but it is pointless to have only ONE of them 
enabled. You need BOTH Security Manager and Verifier to start to have a 
Sandbox (and even then the Sandbox's security will depend on the 
security policies)
> The security manager allows you to restrict runtime-knowledge type
> things. Connecting a socket, opening a file, exiting the vm, and so
> on.
Sure, but when you have a security policy that restricts access to 
sockets files, if the code you are trying to restrict is executed with 
-noverify, then there are ways around those restrictions and have 
'unauthorized' access to those sockets or files.
>> Given that the main attack vector (to exploit the lack of verification)
>> is the same for all cases mentioned above (the attack vector being the
>> injection of malicious Java code on the application being executed) then
>> I would like to know the reason for the inconsistency?
>>
>> I also would like to ask if the following comments are correct:
>>
>> Option A) 99% of the Java code deployed to live systems is executed in
>> an environment with the verifier disabled
>>
>> Option B) 99% of the Java code deployed to live systems is executed in
>> an environment with the verifier disabled OR with the security manager
>> disabled
>
> I'd say no. We already know BEA/Tomcat/(And from my knowledge
> Websphere) all run with verification ON by default. All these 3 don't
> take up only "1%" of all java code.
Ok, but what about the security manager?

I agree that in Option A) the value is not 99% (since the 
BEA/Tomcat/Webshepre code will take more that %1)

But on Option B) (/" Java code deployed to live systems is executed in 
an environment with the verifier disabled OR with the security manager 
disabled" /), which it the one that matters, we are still at 99% since 
the only code that falls outside that category (i.e. executed with the 
verifier AND the security manager enabled) is the mobile code which is 
executed under the default browser Java policies (we have to exclude the 
mobile Java code which requests and is granted more privileges).
>> If not, what value should Option A and B be? 10%, 50%, 75?
> Download the app servers and check the documentation? I'd guess most
> have it on by default. Not off. Just my guess though ...
Am I the only one that finds it surprising that such a pillar of Java 
Security is not properly known and information about 'who does what' 
doesn't seem to be readily available?

Dinis Cruz
Owasp .Net Project
www.owasp.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060512/871dbc30/attachment.html 

From dinis at ddplus.net  Fri May 12 04:49:34 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Fri, 12 May 2006 09:49:34 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE793@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE793@va-mail.cigital.com>
Message-ID: <44644C1E.2050602@ddplus.net>

Gary McGraw wrote:
> The switch from "applets vs applications" security to "trusted code vs untrusted code" happened with the introduction of jdk 1.1 (way back when).   Ed and I followed the sun marketing lead in 96 when it came to applets vs applications, but we cleared this up later in Securing Java www.securingjava.com.
>   
well somebody at Java must have missed this memo (and in Microsoft too) 
since the only code that both Java and .Net don't trust is code executed 
from directly from the Internet into a Browser (and only if using the 
default policy, something that Microsoft with the 2.0 changes to the 
'Click Once' system made very easy to bypass)

Dinis Cruz
Owasp .Net Project
www.owasp.net




From dinis at ddplus.net  Fri May 12 04:57:35 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Fri, 12 May 2006 09:57:35 +0100
Subject: [SC-L] Comment on Microsoft's leaked memos,
 and the unofficial end of Microsoft 'Trustworthy Computing'
Message-ID: <44644DFF.4090002@ddplus.net>

[Due to the relevance to the current discussion on Java Verifier, here 
is a blog entry that I wrote 
<http://owasp.net/blogs/dinis_cruz/archive/2005/11/17/92.aspx>last 
November (also posted on Full Disclosure 
<http://lists.grok.org.uk/pipermail/full-disclosure/2005-November/038869.html> 
)]

_______________________________________________


        Comment on Microsoft's leaked memos, and the unofficial end of
        Microsoft 'Trustworthy Computing'

The current Microsoft CTO (Ray Ozzie 
<http://spaces.msn.com/members/rayozzie/Blog/cns%211pyct_cYtbBtOBPDVAumMEdw%21147.entry>) 
and Bill Gates published two 'leaked' memos last week (you can read Bill 
Gates memo here <http://www.scripting.com/disruption/mail.html>, and 
Ray's memo here 
<http://www.scripting.com/disruption/ozzie/TheInternetServicesDisruptio.htm>, 
published by hypercamp <http://www.hypercamp.org/2005/11/09#a43> ) which 
generated some interresting comments:

    *

      Leaked Memos Point to a "Disrupted" Microsoft
      <http://redmondmag.com/news/article.asp?editorialsid=7030>

    *

      Robert Cringely thinks that they were leaked on purpose
      <http://www.pbs.org/cringely/pulpit/pulpit20051110.html> - I
      agree, nobody writes internal memos like this

    *

      Mini-Microsoft hits again a hard analysis with A Disruptive Defrag
      for Microsoft
      <http://minimsft.blogspot.com/2005/11/disruptive-defrag-for-microsoft.html>
      - note in the comments that some Microsofties are starting to lose
      the patience with Mini (if only they knew who Mini-Microsoft is,
      read Everybody has their theories, but Mini-MSFT is...
      <http://blogs.msdn.com/jledgard/archive/2005/09/23/473511.aspx>
      for a post saying what I had thought before but didn't want to be
      the first to post: Mini-Microsoft is probably somebody quite
      important on Microsoft, if not BG himself)

Now, I did read the memos, and have to say that they show a good 
strategy in focusing on Services and highlight the fact that Microsoft 
has realized that they massive release and development cycles have to be 
replaced by simpler, effective, practical and *secure *services.

Talking about security, as news.com noted here (Gates memo: No mention 
of "trustworthy computing" 
<http://news.com.com/2061-10805_3-5942082.html>), one area that there is 
barely any comment in these memos is security.

*First let's analyze Ray's mention of Security in his memo:*

/"....In 2000, in the waning days of the dot com bubble, we yet again 
reflected on our strategy and refined our direction.  After taking a 
more deliberative look at the internet and its implications for 
software, we came to the conclusion that the internet would go beyond 
browsing and should support programmability on a global scale.  We 
observed that certain aspects of our most fundamental platform -- the 
tools and services that developers use when building their software -- 
would not likely satisfy the emerging *security *and interoperability 
requirements of the internet.  So we embarked upon .NET, a 
transformative new generation of the platform and tools built around 
managed code, the XML format and web services programming model..."

/Humm, I wonder if anybody has told Ray that 99% of .Net applications 
currently deployed have been created for Full Trust environments (which 
is insecure by default, insecure by design and insecure in deployment). 
I guess that he also doesn't know that most code that Microsoft produces 
today is still unmanaged and that the security advantages of the .Net 
framework can only exist in a Partial Trusted world (see my post What 
are the 'Real World' security advantages of the .Net Framework and the 
JVM? <http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/03/5.aspx> 
and Gunnar Peterson's excellent follow-up .Net and Java "faith-based" 
security 
<http://1raindrop.typepad.com/1_raindrop/2005/11/net_and_java_fa.html>)

/"... Complexity kills.  It sucks the life out of developers, it makes 
products difficult to plan, build and test, it introduces *security 
*challenges, and it causes end-user and administrator frustration.  
Moving forward, within all parts of the organization, each of us should 
ask "What's different?", and explore and embrace techniques to reduce 
complexity...."
/
Here, I completely agree, but I wonder then why is not Microsoft giving 
us *SIMPLER *and *LESS COMPLEX *products? I want a simpler Windows 2000, 
2003 and XP (one without the stuff that I don't need), I want a simpler 
.Net Framework (one without the stuff that is not needed to execute the 
relevant application), I want a simper IE (one with less privileges and 
able to handle malicious code).

The main case today for security issues is complexity, and only by fully 
understanding an issue and all its connections and interdependencies, 
can one secure it. This is what worries me about Vista, I see a lot of 
new 'Security Feature's where I would prefer to see more* 'Secure 
Features'* for Windows 2000, 2003 and XP (remember that XP SP2 was only 
successfully from a security point of view, because it didn't introduce 
any major new functionality (I have made some more comments about Vista 
here Security in Longhorn: Focus on Least Privilege 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/14/70.aspx>))

*And now lets look in Bill Gates memo for references about security:

*....

none, zero.

Not one mention of Security.

Does this means that for Microsoft the Security problems are all under 
control and their job is done?

The problem is that Microsoft might have solved quite successfully one 
category of security vulnerabilities (namely the high number of buffer 
overflows) but is not paying enough attention for the next wave of 
attacks and security vulnerabilities.

As the Sony Root kit issue has shown (which I blogged about here:  
Sony's DRM rootkit 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/07/31.aspx>, 
Follow up on Sony 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/10/39.aspx>, Sony 
stops rookit production, ActiveX contains vulnerabilities and 'doing a 
sony' <http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/14/64.aspx> 
and Sony ActiveX massive vulnerabilites, CDs recall and 'Where were the 
AntiVirus?' 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/16/86.aspx>), the 
next wave of attacks will be caused by malicious code executed inside 
the computer.

Let me say this very clearly: *Our computer systems MUST be able to 
SECURELY EXECUTE MALICIOUS CODE!
*
This is why I have been talking for two year now about the Security 
Vulnerabilities in Full Trust Asp.Net (see An 'Asp.Net' accident waiting 
to happen 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/16/80.aspx>, 
Microsoft must deliver 'secure environments' not tools to write 'secure 
code' 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/16/81.aspx>, My 
experience with the MSRC (Microsoft Security Response Center) 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/14/67.aspx>, Some 
comments to Misleading and False Information in: 'What ASP.NET 
Programmers Should Know About Application Domains' 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/16/82.aspx> , 
Microsoft's David Treadwell 'almost' admits the problem 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/16/84.aspx> , 
Some comments about 'The Six Dumbest Ideas in Computer Security' 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/14/68.aspx>, and 
my Owasp Presentations:  OWASP AppSec 2005 UK Presentation 
<http://www.owasp.org/docroot/owasp/misc/OWASP_UK_2005_Presentations/AppSec2005-Dinis_Cruz-Full_Trust_Asp.Net_Insecurity.ppt>  
and AppSec2004-Dinis_Cruz-Full_Trust_Asp.Net_Security_Issues.ppt 
<http://prdownloads.sourceforge.net/owasp/AppSec2004-Dinis_Cruz-Full_Trust_Asp.Net_Security_Issues.ppt?download>).

The only solution for the next wave of malicious code is to be able to 
execute them in secure run-time environments (i.e. Sandboxes) which will 
take a huge amount of work, re-engineering and commitment (the new tools 
in VS 2005 will help). *
*

*But this will not happen until Microsoft acknowledges the problem* and 
says loud and clear in (http://www.microsoft.com/security): *Full Trust 
.Net is a massive security issue and everybody needs to create 
applications (web and windows based) that execute in partially trusted 
environments *(here is where Microsoft is today on this issue: Current 
Microsoft info about CAS and Full Trust 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/03/7.aspx> ).

And lets not forget that the CLR has not been audited by an independent 
team of security consultants (i.e one without an NDA signed with 
Microsoft that limited what they could publish). During my /Rooting the 
CLR/ research I did a quick research of past JVM vulnerabilities and how 
they relate to the CLR, and, was able to quickly find a Possible Type 
Confusion issue in .Net 1.1 (only works in Full Trust) 
<http://www.owasp.net/blogs/dinis_cruz/archive/2005/11/08/36.aspx>. 
Given the fact that SQL Server 2005 is now 100% dependent on the 
integrity of the CLR and BCL, isn't it about time that an independent 
security audit is performed?

Microsoft should learn from the current Sony DRM mess and prepare itself 
for the next wave of exploits (just talking about the good guys, given 
the current windows security model, without using a partially trusted 
environment what choices do DRM makers have but to patch the kernel (for 
example: how can you protect a PDF file from being printed or copied if 
you don't  enforce it at either kernel level or System Process?))

And if Microsoft is not able to make this move, I hope that the Java 
camp does it.

I also have very high hopes in the Mono project since this (securely 
executing malicous/untrusted code) could be Mono's killer-application 
(i.e. the one that makes everybody use it). Here are some links to Mono 
and Mono's CAS:

    * http://www.mono-project.com (main mono website site)
    * CAS - where we stand
      <http://pages.infinit.net/ctech/20051005-0314.html>
    * Code Access Security in Mono
      <http://tirania.org/blog/archive/2005/Apr-20.html>
    * Mono CAS Wiki <http://www.mono-project.com/CAS>
    * Mono Security Manager Part I - Using CAS permissions
      <http://pages.infinit.net/ctech/20050623-0432.html>

Hope somebody is listening

Dinis Cruz
Owasp .Net Project
www.owasp.net

_______________________________________________


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060512/2687177e/attachment.html 

From michaelslists at gmail.com  Fri May 12 06:00:02 2006
From: michaelslists at gmail.com (Michael Silk)
Date: Fri, 12 May 2006 20:00:02 +1000
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <44644792.6090702@ddplus.net>
References: <11f401c66e5d$4084b290$9204a8c0@intranet.aspectsecurity.com>
	<445F9ADE.6080609@ddplus.net>
	<5e01c29a0605081713i6eabeabx824a0fc2bd77be8e@mail.gmail.com>
	<44644792.6090702@ddplus.net>
Message-ID: <5e01c29a0605120300w7f1084f8ia130a5fa9f39791@mail.gmail.com>

On 5/12/06, Dinis Cruz <dinis at ddplus.net> wrote:
>
>  Michael Silk wrote:
>
>
> "What is the point of the verifier?' , 'Why use it? and 'What are the
>  real security advantages of enabling the verifier if the code is
>  executed in an environment with the security manager disabled?'
>
>  Huh? You can find what it does here:
>
>  http://java.sun.com/sfaq/verifier.html
>
>  The security manager and the verifier are different.
>
>  Of course they are, but it is pointless to have only ONE of them enabled.

No it isn't.


> You need BOTH Security Manager and Verifier to start to have a Sandbox (and
> even then the Sandbox's security will depend on the security policies)

You can have a sandbox without the verifier.


> The security manager allows you to restrict runtime-knowledge type
>  things. Connecting a socket, opening a file, exiting the vm, and so
>  on.
>
>  Sure, but when you have a security policy that restricts access to sockets
> files, if the code you are trying to restrict is executed with -noverify,
> then there are ways around those restrictions and have 'unauthorized' access
> to those sockets or files.

How?


> Given that the main attack vector (to exploit the lack of verification)
>  is the same for all cases mentioned above (the attack vector being the
>  injection of malicious Java code on the application being executed) then
>  I would like to know the reason for the inconsistency?
>
>  I also would like to ask if the following comments are correct:
>
>  Option A) 99% of the Java code deployed to live systems is executed in
>  an environment with the verifier disabled
>
>  Option B) 99% of the Java code deployed to live systems is executed in
>  an environment with the verifier disabled OR with the security manager
>  disabled
>
>  I'd say no. We already know BEA/Tomcat/(And from my knowledge
>  Websphere) all run with verification ON by default. All these 3 don't
>  take up only "1%" of all java code.
>
>  Ok, but what about the security manager?
>
>  I agree that in Option A) the value is not 99% (since the
> BEA/Tomcat/Webshepre code will take more that %1)
>
>  But on Option B) (" Java code deployed to live systems is executed in an
> environment with the verifier disabled OR with the security manager
> disabled" ), which it the one that matters, we are still at 99% since the
> only code that falls outside that category (i.e. executed with the verifier
> AND the security manager enabled) is the mobile code which is executed under
> the default browser Java policies (we have to exclude the mobile Java code
> which requests and is granted more privileges).

Are you talking about java desktop applications now instead of j2ee
websites? If so, then who cares? You'll be running inside a new vm.


> If not, what value should Option A and B be? 10%, 50%, 75?
>  Download the app servers and check the documentation? I'd guess most
>  have it on by default. Not off. Just my guess though ...
>
>  Am I the only one that finds it surprising that such a pillar of Java
> Security is not properly known and information about 'who does what' doesn't
> seem to be readily available?

What are you talking about? Documentation _is_ readily available and
has been provided throughout this entire discussion.


>  Dinis Cruz
>  Owasp .Net Project
>  www.owasp.net

-- Michael



From stephen at corsaire.com  Sat May 13 01:30:54 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Sat, 13 May 2006 12:30:54 +0700
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <93544A29-27A9-4274-9591-40774374B55A@pastiche.org>
References: <042e01c66ffa$440ede10$4e01a8c0@intranet.aspectsecurity.com>
	<4462C188.9030904@corsaire.com> <4462FA33.3050608@corsaire.com>
	<93544A29-27A9-4274-9591-40774374B55A@pastiche.org>
Message-ID: <E921AC6C-E8CE-4539-B7D6-9EE2047EEA71@corsaire.com>


On 12 May 2006, at 09:10, Charles Miller wrote:
>
> It's not reflection: you're confusing IllegalAccessException and  
> IllegalAccessError.
>
> For any non-Java nerd still listening in: there are two fundamental  
> types of "Throwable" exception-conditions in Java: Exceptions and  
> Errors[1]. Exceptions represent application-level conditions --  
> things an application is likely to be able to recover from, like  
> network timeouts, trying to read beyond the end of a file, and so  
> on. Errors, on the other hand, represent VM-level problems that an  
> application can't really do anything about, like running out of  
> memory, not finding a required native library, or encountering  
> corrupted class files.
>
> IllegalAccessException happens when reflective code attempts to  
> access some field or method it's not supposed to. Because it's a  
> result of reflection, it's considered an application-level problem  
> and it's assumed your code can recover gracefully.
>
> Amusingly enough, you can get around most IllegalAccessExceptions  
> in java just by calling {field|method}.setAccessible(true). So long  
> as there's no explicit SecurityManager installed, as soon as you've  
> done that you're free to modify the field or call method to your  
> heart's content[2].
>
> IllegalAccess_Error_, on the other hand, happens when some non- 
> reflective code issues a bytecode instruction that attempts to  
> access a field or method it shouldn't be able to see. If you look  
> at its class hierarchy, the meaning of the class is pretty clear:  
> IllegalAccessError is a subclass of IncompatibleClassChangeError,  
> which is a subclass of LinkageError. Because this is a problem at  
> the bytecode/classloading level, and literally something that could  
> happen on _any_ method-call or field-access, it's flagged as an error.
>
> The Error generally occurs when class A has been compiled against a  
> version of class B where a method is public, but that method is  
> private in the version of the same class it encounters at runtime.  
> This sort of thing happens quite often in Java, you're frequently  
> stuck in "jar file hell", in a twisty turny maze of library  
> interdependencies, all with slightly different version numbers.
>
> More about the circumstances of IllegalAccessError here:
>
>    http://java.sun.com/docs/books/vmspec/2nd-edition/html/ 
> ConstantPool.doc.html
>
> Dynamic classloading isn't really at fault here. There are all  
> sorts of pits you can fall into when you start rolling your own  
> classloader (the Java webapp I develop supports dynamic runtime- 
> deployable plugins, and the classloading issues are a HUGE  
> headache), but IllegalAccessError isn't one of them.
>
> Charles
>
>    [1] Exceptions are further divided into checked exceptions and  
> runtime exceptions, but that's beyond the scope of this email
>    [2] See also: http://www.javaspecialists.co.za/archive/ 
> Issue014.html

Thanks for clearing this up Charles.
I've created another example that uses a class loader to load the  
classes, and this time, it throws an IllegalAccessError just like  
Tomcat does:

Loading class: /Users/stephen/data/dev/classloader/myclass/ 
somepackage/MyTest.class
Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/ 
Runnable.class
Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/ 
Object.class
Loading class: /Users/stephen/data/dev/classloader/myclass/ 
somepackage/MyData.class
Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/ 
System.class
Exception in thread "main" java.lang.IllegalAccessError: tried to  
access method somepackage.MyData.getName()Ljava/lang/String; from  
class somepackage.MyTest
         at somepackage.MyTest.run(MyTest.java:15)
         at classloader.Main.main(Main.java:26)
Java Result: 1

This error is thrown irrespective of the -verify flag.  So it looks  
like using a classloader causes the VM to perform verification,  
whether or not the "verifier" was enabled.  Michael Silk made a  
similar statement earlier in this thread.  Would you agree?

PoC code below:

package classloader;

public class Main {

     public Main() {
     }

     public static void main(String[] args) {
         //Illegal Access Error
         try {
             CustomLoader cl = new CustomLoader(System.getProperty 
("user.dir")+"/myclass/");
             Class myClass = cl.loadClass("somepackage.MyTest");
             Runnable r = (Runnable)myClass.newInstance();
             r.run();

         } catch (Exception e) {
             e.printStackTrace();
         }


     }

}


package classloader;

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;

public class CustomLoader extends ClassLoader {
     private String path = null;

     public CustomLoader(String path) {
         this.path = path;
     }


     private byte[] getBytes( String filename ) throws IOException {
         File file = new File( filename );
         long len = file.length();
         byte raw[] = new byte[(int)len];
         FileInputStream fin = new FileInputStream( file );
         int r = fin.read( raw );
         if (r != len)
             throw new IOException( "Can't read all, "+r+" != "+len );
         fin.close();
         return raw;
     }

     public Class loadClass( String name, boolean resolve )
     throws ClassNotFoundException {
         Class clas = null;
         String fileStub = name.replace( '.', '/' );
         String classFilename = path+fileStub+".class";
         System.out.println("Loading class: "+classFilename);
         File classFile = new File( classFilename );
         try {
             byte raw[] = getBytes( classFilename );
             clas = defineClass( name, raw, 0, raw.length );
         } catch( IOException ie ) {
         }
         if (clas==null) {
             clas = findSystemClass( name );
         }

         if (resolve && clas != null)
             resolveClass( clas );

         if (clas == null)
             throw new ClassNotFoundException( name );
         return clas;
     }
}

In current directory create a folder ./myclass/somepackage with the  
following two files:

package somepackage;

public class MyData {
     private String name;

     public MyData() {
         name = "No one can read me";
     }
    	
     public String getName() {
         System.out.println("private method called");
	return (name);
     }
}

package somepackage;

public class MyTest implements Runnable {
	MyData m;
	
	public MyTest() {
		m = new MyData();
	}
	
	public void run() {
		System.out.println(m.getName());
	}
}

Compile both these classes, then change the MyData.getName method to  
private access, and recompile MyData.



Stephen



From stephen at corsaire.com  Sat May 13 05:32:21 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Sat, 13 May 2006 16:32:21 +0700
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <44644013.7090206@ddplus.net>
References: <4457EFC3.4090605@ddplus.net>	
	<6D732530-ECD0-47D9-9F3C-48A16019E6E4@corsaire.com>	
	<445F9156.1040206@ddplus.net>
	<5e01c29a0605081716o9d37a2ao2ca7e6a3884461bf@mail.gmail.com>
	<44644013.7090206@ddplus.net>
Message-ID: <17681687-3405-4179-B9A1-1792FF231811@corsaire.com>


On 12 May 2006, at 14:58, Dinis Cruz wrote:

> Michael Silk wrote:
>> You can't disable the security manager even with the verifier off.  
>> But
>> you could extend some final or private class that the security  
>> manager
>> gives access to.
> This is not correct. With the verifier disabled there are multiple  
> ways you can jump out of the Security Manager Sandbox.
>
> Here is a quote from 1997's Java Security (Gary McGraw and Eduard  
> W. Feltern) book, page 75, Chapter Three 'Serious Holes in the  
> Security Model"

I'm a bit sceptical of this, I know Sun's track record on fixing JVM  
vulnerabilities hasn't always been great, but 9 years seems a bit  
excessive!  Unfortunately the book doesn't provide any more details  
on the vulnerabilities so we're left guessing whether these still  
affect modern JVMs.  Even with verification turned off with the - 
noverify option, I think it would be difficult to break out of a  
defined security manager.

>
> "... The Type Confusion Tool Kit The Princeton team, as a  
> feasibility demonstration, created a tool kit that allows any type  
> confusion attack to be turned into a disarming of Java's security.  
> In other words, the tool kit servers as a way of turning a small  
> security breach into a complete system penetration. The type  
> confusion tool kit has not been released to the public, and is  
> considered to dangerous to describe in any detail here..."
>
> A variation of this quote can also at the bottom of this page:  
> Section 7 -- You're Not My Type
>
> Another quote from Section 7 -- You're Not My Type
> "...As mentioned in Chapter 2, every aspect of Java security  
> depends critically on the type-safety of the language. This means  
> that if Java is going to be secure, it has to make sure that all  
> pointers are properly tagged; that is, the tag must match the  
> actual type of object that is being pointed to.
>
> In a type-confusion attack, a malicious applet creates two pointers  
> to the same object-with incompatible type tags. When this happens,  
> the Java system is in trouble. The applet can write into that  
> memory address through one pointer, and read it through another  
> pointer. The result is that the applet can bypass the typing rules  
> of Java, completely undermining its security...."
>
> The example that we have been playing around here (the direct  
> access to a private member) is probably not the best one to use to  
> test the verifier, since there are multiple ways that this type of  
> illegal access can be 'accidentally' detected by the VM (in Java  
> there are some cases where the class loading process detects this,  
> and in .Net the JIT will catch it)
>
> I think that it will be better to use the examples shown in the  
> brilliant LSD paper http://lsd-pl.net/papers.html#java

The paper mentions avenues of attack through vulnerabilities in  
Netscape 4.x's JVM and IE (Mirosoft's JVM).  These are  
vulnerabilities in specific implementations of the JVM rather than  
inherent flaws in the JVM spec.  Any type confusion attacks that are  
possible because of the lack of default verification (via -verify) in  
the JRE would affect the security of the users' own local code so  
it's unlikely that this will prove to be a practical attack vector,  
IMHO.

> or a variation of the ones I discovered in .Net:
>
> Possible Type Confusion issue in .Net 1.1 (only works in FullTrust)  
> (http://owasp.net/blogs/dinis_cruz/archive/2005/11/08/36.aspx)
> Another Full Trust CLR Verification issue: Exploiting Passing  
> Reference Types by Reference (http://owasp.net/blogs/dinis_cruz/ 
> archive/2005/12/28/393.aspx)
> Another Full Trust CLR Verification issue: Changing Private Field  
> using Proxy Struct (http://owasp.net/blogs/dinis_cruz/archive/ 
> 2005/12/28/394.aspx)
> Another Full Trust CLR Verification issue: changing the Method  
> Parameters order (http://owasp.net/blogs/dinis_cruz/archive/ 
> 2005/12/26/390.aspx)
> In fact, it would be great to have a 'verifier checker' tool. A set  
> of scripts that would test for verifier issues on Java execution  
> environments (this would make it very easy to detect who is using  
> the verifier and what type of verification is performed).
>
> After this explanation, Stephen, do you still disagree with my  
> original comments:
>
> "This is a very weird decision by the Java Architects, since what  
> is the point of creating and enforcing a airtight security policy  
> if you can jump strait out of it via a Type Confusion attack?

This is speculation.  We don't know if it's possible to break the  
security manager through a type confusion attack - the one reference  
we have is 9 years old and doesn't say much, the other targets  
specific implementation flaws older JVMs.  Java verification and  
security has many layers (as we've seen in trying to pinpoint exactly  
when it happens!), so I don't think it's accurate to equate a lack of  
local code verification with a complete breakdown of the security  
manager - unless someone demonstrates otherwise.

regards,
Stephen




From michaelslists at gmail.com  Sat May 13 07:35:58 2006
From: michaelslists at gmail.com (Michael Silk)
Date: Sat, 13 May 2006 21:35:58 +1000
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <E921AC6C-E8CE-4539-B7D6-9EE2047EEA71@corsaire.com>
References: <042e01c66ffa$440ede10$4e01a8c0@intranet.aspectsecurity.com>
	<4462C188.9030904@corsaire.com> <4462FA33.3050608@corsaire.com>
	<93544A29-27A9-4274-9591-40774374B55A@pastiche.org>
	<E921AC6C-E8CE-4539-B7D6-9EE2047EEA71@corsaire.com>
Message-ID: <5e01c29a0605130435ped8b4t3f4b33ba201d7812@mail.gmail.com>

Stephen,

 I think the reason you get the IllegalAccessError is because the VM
thinks you are loading from a remote url.

 I don't think the user of a classloader per-se forces the
verification of the class. (I wrote a class loader like yours that
just loads a file with no package in the current dir and was able to
access the private method).

 You can also note that your class isn't verified if -noverify is
passed (perhaps this is obvious :)

-- Michael



On 5/13/06, Stephen de Vries <stephen at corsaire.com> wrote:
>
> On 12 May 2006, at 09:10, Charles Miller wrote:
> >
> > It's not reflection: you're confusing IllegalAccessException and
> > IllegalAccessError.
> >
> > For any non-Java nerd still listening in: there are two fundamental
> > types of "Throwable" exception-conditions in Java: Exceptions and
> > Errors[1]. Exceptions represent application-level conditions --
> > things an application is likely to be able to recover from, like
> > network timeouts, trying to read beyond the end of a file, and so
> > on. Errors, on the other hand, represent VM-level problems that an
> > application can't really do anything about, like running out of
> > memory, not finding a required native library, or encountering
> > corrupted class files.
> >
> > IllegalAccessException happens when reflective code attempts to
> > access some field or method it's not supposed to. Because it's a
> > result of reflection, it's considered an application-level problem
> > and it's assumed your code can recover gracefully.
> >
> > Amusingly enough, you can get around most IllegalAccessExceptions
> > in java just by calling {field|method}.setAccessible(true). So long
> > as there's no explicit SecurityManager installed, as soon as you've
> > done that you're free to modify the field or call method to your
> > heart's content[2].
> >
> > IllegalAccess_Error_, on the other hand, happens when some non-
> > reflective code issues a bytecode instruction that attempts to
> > access a field or method it shouldn't be able to see. If you look
> > at its class hierarchy, the meaning of the class is pretty clear:
> > IllegalAccessError is a subclass of IncompatibleClassChangeError,
> > which is a subclass of LinkageError. Because this is a problem at
> > the bytecode/classloading level, and literally something that could
> > happen on _any_ method-call or field-access, it's flagged as an error.
> >
> > The Error generally occurs when class A has been compiled against a
> > version of class B where a method is public, but that method is
> > private in the version of the same class it encounters at runtime.
> > This sort of thing happens quite often in Java, you're frequently
> > stuck in "jar file hell", in a twisty turny maze of library
> > interdependencies, all with slightly different version numbers.
> >
> > More about the circumstances of IllegalAccessError here:
> >
> >    http://java.sun.com/docs/books/vmspec/2nd-edition/html/
> > ConstantPool.doc.html
> >
> > Dynamic classloading isn't really at fault here. There are all
> > sorts of pits you can fall into when you start rolling your own
> > classloader (the Java webapp I develop supports dynamic runtime-
> > deployable plugins, and the classloading issues are a HUGE
> > headache), but IllegalAccessError isn't one of them.
> >
> > Charles
> >
> >    [1] Exceptions are further divided into checked exceptions and
> > runtime exceptions, but that's beyond the scope of this email
> >    [2] See also: http://www.javaspecialists.co.za/archive/
> > Issue014.html
>
> Thanks for clearing this up Charles.
> I've created another example that uses a class loader to load the
> classes, and this time, it throws an IllegalAccessError just like
> Tomcat does:
>
> Loading class: /Users/stephen/data/dev/classloader/myclass/
> somepackage/MyTest.class
> Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/
> Runnable.class
> Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/
> Object.class
> Loading class: /Users/stephen/data/dev/classloader/myclass/
> somepackage/MyData.class
> Loading class: /Users/stephen/data/dev/classloader/myclass/java/lang/
> System.class
> Exception in thread "main" java.lang.IllegalAccessError: tried to
> access method somepackage.MyData.getName()Ljava/lang/String; from
> class somepackage.MyTest
>          at somepackage.MyTest.run(MyTest.java:15)
>          at classloader.Main.main(Main.java:26)
> Java Result: 1
>
> This error is thrown irrespective of the -verify flag.  So it looks
> like using a classloader causes the VM to perform verification,
> whether or not the "verifier" was enabled.  Michael Silk made a
> similar statement earlier in this thread.  Would you agree?
>
> PoC code below:
>
> package classloader;
>
> public class Main {
>
>      public Main() {
>      }
>
>      public static void main(String[] args) {
>          //Illegal Access Error
>          try {
>              CustomLoader cl = new CustomLoader(System.getProperty
> ("user.dir")+"/myclass/");
>              Class myClass = cl.loadClass("somepackage.MyTest");
>              Runnable r = (Runnable)myClass.newInstance();
>              r.run();
>
>          } catch (Exception e) {
>              e.printStackTrace();
>          }
>
>
>      }
>
> }
>
>
> package classloader;
>
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.IOException;
>
> public class CustomLoader extends ClassLoader {
>      private String path = null;
>
>      public CustomLoader(String path) {
>          this.path = path;
>      }
>
>
>      private byte[] getBytes( String filename ) throws IOException {
>          File file = new File( filename );
>          long len = file.length();
>          byte raw[] = new byte[(int)len];
>          FileInputStream fin = new FileInputStream( file );
>          int r = fin.read( raw );
>          if (r != len)
>              throw new IOException( "Can't read all, "+r+" != "+len );
>          fin.close();
>          return raw;
>      }
>
>      public Class loadClass( String name, boolean resolve )
>      throws ClassNotFoundException {
>          Class clas = null;
>          String fileStub = name.replace( '.', '/' );
>          String classFilename = path+fileStub+".class";
>          System.out.println("Loading class: "+classFilename);
>          File classFile = new File( classFilename );
>          try {
>              byte raw[] = getBytes( classFilename );
>              clas = defineClass( name, raw, 0, raw.length );
>          } catch( IOException ie ) {
>          }
>          if (clas==null) {
>              clas = findSystemClass( name );
>          }
>
>          if (resolve && clas != null)
>              resolveClass( clas );
>
>          if (clas == null)
>              throw new ClassNotFoundException( name );
>          return clas;
>      }
> }
>
> In current directory create a folder ./myclass/somepackage with the
> following two files:
>
> package somepackage;
>
> public class MyData {
>      private String name;
>
>      public MyData() {
>          name = "No one can read me";
>      }
>
>      public String getName() {
>          System.out.println("private method called");
>         return (name);
>      }
> }
>
> package somepackage;
>
> public class MyTest implements Runnable {
>         MyData m;
>
>         public MyTest() {
>                 m = new MyData();
>         }
>
>         public void run() {
>                 System.out.println(m.getName());
>         }
> }
>
> Compile both these classes, then change the MyData.getName method to
> private access, and recompile MyData.
>
>
>
> Stephen
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>



From gem at cigital.com  Sat May 13 16:42:11 2006
From: gem at cigital.com (Gary McGraw)
Date: Sat, 13 May 2006 16:42:11 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE909@va-mail.cigital.com>

Shall we ask ed felten to did out the old type confusion toolkit?

gem

 -----Original Message-----
From: 	Stephen de Vries [mailto:stephen at corsaire.com]
Sent:	Sat May 13 15:12:48 2006
To:	Dinis Cruz
Cc:	Secure Coding Mailing List
Subject:	Re: [SC-L] By default, the Verifier is disabled on .Net and Java


On 12 May 2006, at 14:58, Dinis Cruz wrote:

> Michael Silk wrote:
>> You can't disable the security manager even with the verifier off.  
>> But
>> you could extend some final or private class that the security  
>> manager
>> gives access to.
> This is not correct. With the verifier disabled there are multiple  
> ways you can jump out of the Security Manager Sandbox.
>
> Here is a quote from 1997's Java Security (Gary McGraw and Eduard  
> W. Feltern) book, page 75, Chapter Three 'Serious Holes in the  
> Security Model"

I'm a bit sceptical of this, I know Sun's track record on fixing JVM  
vulnerabilities hasn't always been great, but 9 years seems a bit  
excessive!  Unfortunately the book doesn't provide any more details  
on the vulnerabilities so we're left guessing whether these still  
affect modern JVMs.  Even with verification turned off with the - 
noverify option, I think it would be difficult to break out of a  
defined security manager.

>
> "... The Type Confusion Tool Kit The Princeton team, as a  
> feasibility demonstration, created a tool kit that allows any type  
> confusion attack to be turned into a disarming of Java's security.  
> In other words, the tool kit servers as a way of turning a small  
> security breach into a complete system penetration. The type  
> confusion tool kit has not been released to the public, and is  
> considered to dangerous to describe in any detail here..."
>
> A variation of this quote can also at the bottom of this page:  
> Section 7 -- You're Not My Type
>
> Another quote from Section 7 -- You're Not My Type
> "...As mentioned in Chapter 2, every aspect of Java security  
> depends critically on the type-safety of the language. This means  
> that if Java is going to be secure, it has to make sure that all  
> pointers are properly tagged; that is, the tag must match the  
> actual type of object that is being pointed to.
>
> In a type-confusion attack, a malicious applet creates two pointers  
> to the same object-with incompatible type tags. When this happens,  
> the Java system is in trouble. The applet can write into that  
> memory address through one pointer, and read it through another  
> pointer. The result is that the applet can bypass the typing rules  
> of Java, completely undermining its security...."
>
> The example that we have been playing around here (the direct  
> access to a private member) is probably not the best one to use to  
> test the verifier, since there are multiple ways that this type of  
> illegal access can be 'accidentally' detected by the VM (in Java  
> there are some cases where the class loading process detects this,  
> and in .Net the JIT will catch it)
>
> I think that it will be better to use the examples shown in the  
> brilliant LSD paper http://lsd-pl.net/papers.html#java

The paper mentions avenues of attack through vulnerabilities in  
Netscape 4.x's JVM and IE (Mirosoft's JVM).  These are  
vulnerabilities in specific implementations of the JVM rather than  
inherent flaws in the JVM spec.  Any type confusion attacks that are  
possible because of the lack of default verification (via -verify) in  
the JRE would affect the security of the users' own local code so  
it's unlikely that this will prove to be a practical attack vector,  
IMHO.

> or a variation of the ones I discovered in .Net:
>
> Possible Type Confusion issue in .Net 1.1 (only works in FullTrust)  
> (http://owasp.net/blogs/dinis_cruz/archive/2005/11/08/36.aspx)
> Another Full Trust CLR Verification issue: Exploiting Passing  
> Reference Types by Reference (http://owasp.net/blogs/dinis_cruz/ 
> archive/2005/12/28/393.aspx)
> Another Full Trust CLR Verification issue: Changing Private Field  
> using Proxy Struct (http://owasp.net/blogs/dinis_cruz/archive/ 
> 2005/12/28/394.aspx)
> Another Full Trust CLR Verification issue: changing the Method  
> Parameters order (http://owasp.net/blogs/dinis_cruz/archive/ 
> 2005/12/26/390.aspx)
> In fact, it would be great to have a 'verifier checker' tool. A set  
> of scripts that would test for verifier issues on Java execution  
> environments (this would make it very easy to detect who is using  
> the verifier and what type of verification is performed).
>
> After this explanation, Stephen, do you still disagree with my  
> original comments:
>
> "This is a very weird decision by the Java Architects, since what  
> is the point of creating and enforcing a airtight security policy  
> if you can jump strait out of it via a Type Confusion attack?

This is speculation.  We don't know if it's possible to break the  
security manager through a type confusion attack - the one reference  
we have is 9 years old and doesn't say much, the other targets  
specific implementation flaws older JVMs.  Java verification and  
security has many layers (as we've seen in trying to pinpoint exactly  
when it happens!), so I don't think it's accurate to equate a lack of  
local code verification with a complete breakdown of the security  
manager - unless someone demonstrates otherwise.

regards,
Stephen


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From dinis at ddplus.net  Sun May 14 03:40:20 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Sun, 14 May 2006 08:40:20 +0100
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <CF8B26B8B49184429CB084616B00193001588EBA@itomae2km05.AD.QINTRA.COM>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE909@va-mail.cigital.com>
	<CF8B26B8B49184429CB084616B00193001588EBA@itomae2km05.AD.QINTRA.COM>
Message-ID: <4466DEE4.7070201@ddplus.net>

Kevin is correct, a type confusion attack will allow the bypass of the 
security manager simply because via a type confusion attack you will be 
able to change what the security manager is 'seeing'

In both .Net and Java, the sandboxes logic (CAS and Security manager) 
are external to the the JVM/CLR, that is the security checks ("can I 
access this file?", "do I have permissions to call this method?", 
etc...) are performed in the middle of the core Framework libraries. 
Basically what the core Framework developers do, is to analyze all 
public entry points, and make sure that all are protected with a 
Security Demand (using .Net terminology).

These public methods will then call private methods, who will be the 
ones that actually access the resources being protected (note that in 
these private methods there are no security checks).

So in an environment where you have a solid Security Policy (enforced by 
a Security Manager) but the verifier is NOT enabled, then to jump out of 
the sandbox all that you need to do is to create a Type Confusion 
exploit that allows you to access a private member that either: calls 
the protected resource directly or disables the Security Manager (which 
based on the description provided is the demo that I think Ed Felten did).

Of course that there will be other ways to exploit a non-verify world. 
Without verification it should be possible to create Buffer Overflows 
and other types of direct manipulation of memory objects which all occur 
before the security manager has a change to do anything.

Using a 'Matrix' Analogy, the Security Manager is the Police Department 
that operates inside the virtual world, where the verifier is the one 
that make sure that all characters (including the Police) behaves 
accordingly to the rules defined for that virtual world. In this analogy 
Neo (the hero) was able to perform several Type Safety or Verifier 
attacks which gave him those extra powers :)

I will stick to my guns and say that in a Virtual Machine environment 
like the JVM or CLR it doesn't make sense to have the overhead of a 
security system (like CAS or Security Manager) if the verifier is disabled.

Basically code executed with no verification is as 'secure' and 
contained as unmanaged code.

And remember that this code will be able to access ALL resources that 
the account used to execute that code has (from emails to VPNs to 
documents to online financial services, etc...)

But probably the best way forward (since the guys from SUN and other 
Java Application server can't be bothered (or don't have permission) to 
participate in this discussion) will be to do a proof of concept example.

Why don't we do a 'break from a non verified Sandbox' challenge?

Dinis Cruz
Owasp .Net Project
www.owasp.net

Wall, Kevin wrote:
> Gary McGraw wrote...
>
>   
>> Shall we ask ed felten to did out the old type confusion toolkit?
>>     
>
> That might be a good idea, but depending on the exact exploits
> the 2 of you used, they may not work on JDK 1.5. However--and this
> is just a guess--that in principle, type confusion attacks could
> allow you to by-pass at least some of the SecurityManager
> permission checks, and so I agree that you really ought to have
> the verifier enabled if you are going to use the security manager.
>
> ---
> Kevin W. Wall		Qwest Information Technology, Inc.
> Kevin.Wall at qwest.com	Phone: 614.215.4788
> "The reason you have people breaking into your software all 
> over the place is because your software sucks..."
>  -- Former whitehouse cybersecurity advisor, Richard Clarke,
>     at eWeek Security Summit
>
>
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org on behalf of Gary McGraw
> Sent: Sat 5/13/2006 4:42 PM
> To: Stephen de Vries; Dinis Cruz
> Cc: Secure Coding Mailing List
> Subject: Re: [SC-L] By default, the Verifier is disabled on .Net and Java
>  
> Shall we ask ed felten to dig out the old type confusion toolkit?
>
> gem
>
>  -----Original Message-----
> From: 	Stephen de Vries [mailto:stephen at corsaire.com]
> Sent:	Sat May 13 15:12:48 2006
> To:	Dinis Cruz
> Cc:	Secure Coding Mailing List
> Subject:	Re: [SC-L] By default, the Verifier is disabled on .Net and Java
>
>
> On 12 May 2006, at 14:58, Dinis Cruz wrote:
>
>   
>> Michael Silk wrote:
>>     
>>> You can't disable the security manager even with the verifier off.  
>>> But
>>> you could extend some final or private class that the security  
>>> manager
>>> gives access to.
>>>       
>> This is not correct. With the verifier disabled there are multiple  
>> ways you can jump out of the Security Manager Sandbox.
>>
>> Here is a quote from 1997's Java Security (Gary McGraw and Eduard  
>> W. Feltern) book, page 75, Chapter Three 'Serious Holes in the  
>> Security Model"
>>     
>
> I'm a bit sceptical of this, I know Sun's track record on fixing JVM  
> vulnerabilities hasn't always been great, but 9 years seems a bit  
> excessive!  Unfortunately the book doesn't provide any more details  
> on the vulnerabilities so we're left guessing whether these still  
> affect modern JVMs.  Even with verification turned off with the - 
> noverify option, I think it would be difficult to break out of a  
> defined security manager.
>
>   
>> "... The Type Confusion Tool Kit The Princeton team, as a  
>> feasibility demonstration, created a tool kit that allows any type  
>> confusion attack to be turned into a disarming of Java's security.  
>> In other words, the tool kit servers as a way of turning a small  
>> security breach into a complete system penetration. The type  
>> confusion tool kit has not been released to the public, and is  
>> considered to dangerous to describe in any detail here..."
>>
>> A variation of this quote can also at the bottom of this page:  
>> Section 7 -- You're Not My Type
>>
>> Another quote from Section 7 -- You're Not My Type
>> "...As mentioned in Chapter 2, every aspect of Java security  
>> depends critically on the type-safety of the language. This means  
>> that if Java is going to be secure, it has to make sure that all  
>> pointers are properly tagged; that is, the tag must match the  
>> actual type of object that is being pointed to.
>>
>> In a type-confusion attack, a malicious applet creates two pointers  
>> to the same object-with incompatible type tags. When this happens,  
>> the Java system is in trouble. The applet can write into that  
>> memory address through one pointer, and read it through another  
>> pointer. The result is that the applet can bypass the typing rules  
>> of Java, completely undermining its security...."
>>
>> The example that we have been playing around here (the direct  
>> access to a private member) is probably not the best one to use to  
>> test the verifier, since there are multiple ways that this type of  
>> illegal access can be 'accidentally' detected by the VM (in Java  
>> there are some cases where the class loading process detects this,  
>> and in .Net the JIT will catch it)
>>
>> I think that it will be better to use the examples shown in the  
>> brilliant LSD paper http://lsd-pl.net/papers.html#java
>>     
>
> The paper mentions avenues of attack through vulnerabilities in  
> Netscape 4.x's JVM and IE (Mirosoft's JVM).  These are  
> vulnerabilities in specific implementations of the JVM rather than  
> inherent flaws in the JVM spec.  Any type confusion attacks that are  
> possible because of the lack of default verification (via -verify) in  
> the JRE would affect the security of the users' own local code so  
> it's unlikely that this will prove to be a practical attack vector,  
> IMHO.
>
>   
>> or a variation of the ones I discovered in .Net:
>>
>> Possible Type Confusion issue in .Net 1.1 (only works in FullTrust)  
>> (http://owasp.net/blogs/dinis_cruz/archive/2005/11/08/36.aspx)
>> Another Full Trust CLR Verification issue: Exploiting Passing  
>> Reference Types by Reference (http://owasp.net/blogs/dinis_cruz/ 
>> archive/2005/12/28/393.aspx)
>> Another Full Trust CLR Verification issue: Changing Private Field  
>> using Proxy Struct (http://owasp.net/blogs/dinis_cruz/archive/ 
>> 2005/12/28/394.aspx)
>> Another Full Trust CLR Verification issue: changing the Method  
>> Parameters order (http://owasp.net/blogs/dinis_cruz/archive/ 
>> 2005/12/26/390.aspx)
>> In fact, it would be great to have a 'verifier checker' tool. A set  
>> of scripts that would test for verifier issues on Java execution  
>> environments (this would make it very easy to detect who is using  
>> the verifier and what type of verification is performed).
>>
>> After this explanation, Stephen, do you still disagree with my  
>> original comments:
>>
>> "This is a very weird decision by the Java Architects, since what  
>> is the point of creating and enforcing a airtight security policy  
>> if you can jump strait out of it via a Type Confusion attack?
>>     
>
> This is speculation.  We don't know if it's possible to break the  
> security manager through a type confusion attack - the one reference  
> we have is 9 years old and doesn't say much, the other targets  
> specific implementation flaws older JVMs.  Java verification and  
> security has many layers (as we've seen in trying to pinpoint exactly  
> when it happens!), so I don't think it's accurate to equate a lack of  
> local code verification with a complete breakdown of the security  
> manager - unless someone demonstrates otherwise.
>
> regards,
> Stephen
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
>
>
>
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
>
>
> This communication is the property of Qwest and may contain confidential or
> privileged information. Unauthorized use of this communication is strictly 
> prohibited and may be unlawful.  If you have received this communication 
> in error, please immediately notify the sender by reply e-mail and destroy 
> all copies of the communication and any attachments.
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060514/de28fdec/attachment.html 

From dinis at ddplus.net  Sun May 14 13:19:39 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Sun, 14 May 2006 18:19:39 +0100
Subject: [SC-L] Robert Cringely on Type Safety (well sort of :)
Message-ID: <446766AB.8050701@ddplus.net>

On this week's post (see 
http://www.pbs.org/cringely/pulpit/pulpit20060511.html) Robert Cringely 
hits it spot on:
/
"... If Microsoft really wanted to compete -- if they really wanted (or 
even knew how) to truly defend their turf, here is what they would do. 
They would throw away Vista and develop a new operating system, one that 
is simpler, lighter, and more secure -- an OS that would run on any 
machine now running Windows 2000 or XP. They would price it right, which 
is to say cheap ($49.95). The associated and trimmed-down version of 
Office would be priced the same ($49.95). The upgrade market is probably 
five times bigger than the OEM PC market, so Microsoft needs (but 
probably doesn't realize it) an OS that will run well on most of the PC 
installed base. It needs to set the pricing of the OS so that we'll run 
to the store to get it. Instead of designing products exclusively for 
new equipment, now it's time for Microsoft to focus on the installed 
base...."

/ I would only make one small correction:

     /'...They would throw away Vista and develop a new *type safe* 
operating system, one that is simpler, lighter and more secure...'./

I'm sure that is what Robert meant to say :)

In par with the proposed pricing for the OS, Microsoft should also do 
what I proposed here:  Response to comments and an idea for Microsoft: 
Create and Sell Products for Windows NT 4.0, 2000 and 2003 
<http://owasp.net/blogs/dinis_cruz/archive/2005/11/18/176.aspx> 
(http://owasp.net/blogs/dinis_cruz/archive/2005/11/18/176.aspx) since 
that would create a positive model where Microsoft products would 
compete fairly and would not have to engage the current 'lock-in' 
practices (which are responsible for large part of Microsoft's security 
problems)

Dinis Cruz
Owasp .Net Project
www.owasp.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060514/132b3684/attachment.html 

From lunerwood at yahoo.com  Mon May 15 00:54:52 2006
From: lunerwood at yahoo.com (j lunerwood)
Date: Sun, 14 May 2006 21:54:52 -0700 (PDT)
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
Message-ID: <20060515045452.18747.qmail@web37409.mail.mud.yahoo.com>

in reply to 

>Dinis Cruz dinis at ddplus.net
>Sun May 14 03:40:20 EDT 2006
<...skipped...>
>So in an environment where you have a solid Security
Policy (enforced by 
>a Security Manager) but the verifier is NOT enabled,
then to jump out of 
>the sandbox all that you need to do is to create a
Type Confusion 
>exploit that allows you to access a private member
that either: calls 
>the protected resource directly or disables the
Security Manager (which 
>based on the description provided is the demo that I
think Ed Felten did).
<....skipped...>


I guess this is exactly the logic that was behind the
implementation decision that by default 

Code isn't verified when and only when it is granted
"All Permissions" 

mentioned here
http://archives.java.sun.com/cgi-bin/wa?A2=ind0107&L=java-security&P=1305

Though the post at the link avove talks only about
boot strap classes, i guess this policy is now
implemented across the whole JVM (obviously some
digging through the java sources would be needed to
confirm this)

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From michaelslists at gmail.com  Sun May 14 22:51:06 2006
From: michaelslists at gmail.com (Michael Silk)
Date: Mon, 15 May 2006 12:51:06 +1000
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
In-Reply-To: <4466DEE4.7070201@ddplus.net>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BE909@va-mail.cigital.com>
	<CF8B26B8B49184429CB084616B00193001588EBA@itomae2km05.AD.QINTRA.COM>
	<4466DEE4.7070201@ddplus.net>
Message-ID: <5e01c29a0605141951s7a6e7645u62d85814e8428be8@mail.gmail.com>

On 5/14/06, Dinis Cruz <dinis at ddplus.net> wrote:
>
> Kevin is correct, a type confusion attack will allow the bypass of the
> security manager simply because via a type confusion attack you will be able
> to change what the security manager is 'seeing'
>
> In both .Net and Java, the sandboxes logic (CAS and Security manager) are
> external to the the JVM/CLR, that is the security checks ("can I access this
> file?", "do I have permissions to call this method?", etc...) are performed
> in the middle of the core Framework libraries. Basically what the core
> Framework developers do, is to analyze all public entry points, and make
> sure that all are protected with a Security Demand (using .Net terminology).
>
> These public methods will then call private methods, who will be the ones
> that actually access the resources being protected (note that in these
> private methods there are no security checks).
>
> So in an environment where you have a solid Security Policy (enforced by a
> Security Manager) but the verifier is NOT enabled, then to jump out of the
> sandbox all that you need to do is to create a Type Confusion exploit that
> allows you to access a private member that either: calls the protected
> resource directly or disables the Security Manager (which based on the
> description provided is the demo that I think Ed Felten did).
>
>  Of course that there will be other ways to exploit a non-verify world.
> Without verification it should be possible to create Buffer Overflows and
> other types of direct manipulation of memory objects which all occur before
> the security manager has a change to do anything.

Please read the java documentation.

http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#40222

Maybe you are also interested in BCEL by apache.


> Using a 'Matrix' Analogy, the Security Manager is the Police Department
> that operates inside the virtual world, where the verifier is the one that
> make sure that all characters (including the Police) behaves accordingly to
> the rules defined for that virtual world. In this analogy Neo (the hero) was
> able to perform several Type Safety or Verifier attacks which gave him those
> extra powers :)
>
>  I will stick to my guns and say that in a Virtual Machine environment like
> the JVM or CLR it doesn't make sense to have the overhead of a security
> system (like CAS or Security Manager) if the verifier is disabled.
>
>  Basically code executed with no verification is as 'secure' and contained
> as unmanaged code.

What do you mean by verification?


>  And remember that this code will be able to access ALL resources that the
> account used to execute that code has (from emails to VPNs to documents to
> online financial services, etc...)
>
>  But probably the best way forward (since the guys from SUN and other Java
> Application server can't be bothered (or don't have permission) to
> participate in this discussion) will be to do a proof of concept example.
>
>  Why don't we do a 'break from a non verified Sandbox' challenge?

"We" ? Why don't _YOU_ do it. This is your crusade.

Your code must break out of a "-noverify" sandbox, but fail to break a
-verifiy sandbox.


>  Dinis Cruz
>  Owasp .Net Project
>  www.owasp.net

-- Michael



From leichter_jerrold at emc.com  Mon May 15 14:31:46 2006
From: leichter_jerrold at emc.com (leichter_jerrold at emc.com)
Date: Mon, 15 May 2006 14:31:46 -0400
Subject: [SC-L] By default, the Verifier is disabled on .Net and Java
Message-ID: <Pine.SOL.4.61.0605151415420.8990@mental>

| Kevin is correct, a type confusion attack will allow the bypass of the 
| security manager simply because via a type confusion attack you will be
able 
| to change what the security manager is 'seeing'....
| 
| So in an environment where you have a solid Security Policy (enforced by a

| Security Manager) but the verifier is NOT enabled, then to jump out of the

| sandbox all that you need to do is to create a Type Confusion exploit that

| allows you to access a private member that either: calls the protected 
| resource directly or disables the Security Manager (which based on the 
| description provided is the demo that I think Ed Felten did)....
| 
| I will stick to my guns and say that in a Virtual Machine environment like

| the JVM or CLR it doesn't make sense to have the overhead of a security 
| system (like CAS or Security Manager) if the verifier is disabled....
This is taking a bit too extreme a point of view.

The issue here is what's trusted, and for what purpose.  *Something* has
to be trusted.  The verifier, the security manager, the JVM - if you
can't trust these, you have no hope.

The Java/.Net defaults explicitly say:  (a) I trust the compiler not to
generate dangerous code; (b) I trust the local user not to put stuff
on the local disk where it can be executed unless it came from the
compiler and he trusts it; (c) I trust the OS to protect the stuff on
the local disk.  On the other hand, I *don't* trust stuff that comes
off the network.

Given the realities of the last 10 years of virus-like attacks, this
trust model may well be questionable.  But keep in mind that just
because a Java application passes every verification and is acceptable
to even a very strict security policy doesn't mean it isn't a trojan
horse at a higher semantic level!

Verifying bytecodes certainly blocks many attack vectors, and is a
fine idea - but things are not all black and white.  Runtime
checking will inherently cost you performance.  Someone will
always have an application where the extra cost is "too high"
relative to the risk of running unverified.

Rather than absolute statements about requiring verification
for all user-written code - while leaving it off for the
large volume of system-provided code - we need a more nuanced
view, a better way to quantify risks and costs and trade them
off.  Otherwise, the same forces that to this day argue that
Java is unacceptable because of the overhead of garbage
collection will continue to push for writing in completely
unsafe languages.
							-- Jerry



From gem at cigital.com  Mon May 15 20:32:54 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 15 May 2006 20:32:54 -0400
Subject: [SC-L] New podcast (sneak preview)
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB42133B@va-mail.cigital.com>

Hi all,
 
Tomorrow, we'll announce the existence of the Silver Bullet Security Podcast with Gary McGraw.  Woo hoo.  The first interview is with Avi Rubin.  This activity is sponsored by IEEE S&P Magazine...who by now all sc-l readers should know well!
 
See www.cigital.com/silverbullet
 
Hope you all like it!
 
gem
 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Tue May 16 20:48:18 2006
From: gem at cigital.com (Gary McGraw)
Date: Tue, 16 May 2006 20:48:18 -0400
Subject: [SC-L] More irony?
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEA22@va-mail.cigital.com>


Sorry about the "silver bullet" name for the podcast...seems to have ruffled at least one feather out there.  You do know there is no silver bullet, right?!!  Actually, i'm not sorry!  That was irony.

Here's more:

"A computer expert has described his astonishment at seeing the BBC's 
24-hour news channel interview a taxi driver - in the mistaken belief it was him."

http://www.mailonsunday.co.uk/pages/live/articles/news/news.html?in_article_id=386136&in_page_id=1770&in_page_id=1770


This clip is the stuff of legend...become a computer expert today!

gem




Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Thu May 18 19:42:26 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 18 May 2006 19:42:26 -0400
Subject: [SC-L] Ajax one panel
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEAE5@va-mail.cigital.com>


Ok...it was java one.  But it seemed like ajax one on the show floor.   I participated in a panel yesterday with superstar bill joy.  I had a chance to talk to bill for a while after the gig and asked him why java did not have closure.  Bill said he was on a committee of five, and got out-voted 2 to 3 on that one (and some other stuff too).  You know the other pro vote had to be guy steele.  Most interesting.  Tyranny of the majority even in java.

Btw, bill also said they tried twice to build an OS on java and failed both times.  We both agree that a type safe OS will happen one day.

Here's a blog entry from john waters that describes the panel from his point of view.

http://www.adtmag.com/blogs/blog.aspx?a=18564

gem
www.cigital.com
www.swsec.com


Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Sat May 20 16:24:36 2006
From: gem at cigital.com (Gary McGraw)
Date: Sat, 20 May 2006 16:24:36 -0400
Subject: [SC-L] Ajax one panel
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEB47@va-mail.cigital.com>

Hi yo!

Closure is very helpful when doing things like crossing trust boundaries.  If you look at the craziness involved in properly invoking the doprivilege() stuff in java2, the need for closure is strikingly obvious.

However, closure itself is not as important as type safety is.   So the fact that javascript may (or may not) have closure fails in comparison to the fact that it is not type safe.

Ajax is a disaster from a security perspective.

gem

 -----Original Message-----
From: 	Johan Peeters [mailto:info at secappdev.org]
Sent:	Sat May 20 15:44:46 2006
To:	Gary McGraw
Cc:	Mailing List, Secure Coding; SSG
Subject:	Re: [SC-L] Ajax one panel

I think Java would have been a better language with closures, but I am 
intrigued that you raise them here. Do you think closures present 
security benefits? Or is this a veiled reference to Ajax? I guess 
JavaScript has closures.

kr,

Yo

Gary McGraw wrote:
> Ok...it was java one.  But it seemed like ajax one on the show floor.   I participated in a panel yesterday with superstar bill joy.  I had a chance to talk to bill for a while after the gig and asked him why java did not have closure.  Bill said he was on a committee of five, and got out-voted 2 to 3 on that one (and some other stuff too).  You know the other pro vote had to be guy steele.  Most interesting.  Tyranny of the majority even in java.
> 
> Btw, bill also said they tried twice to build an OS on java and failed both times.  We both agree that a type safe OS will happen one day.
> 
> Here's a blog entry from john waters that describes the panel from his point of view.
> 
> http://www.adtmag.com/blogs/blog.aspx?a=18564
> 
> gem
> www.cigital.com
> www.swsec.com
> 
> 
> Sent from my treo.
> 
> 
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 
> 

-- 
Johan Peeters
program director
http://www.secappdev.org
+32 16 649000




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Sun May 21 11:40:04 2006
From: gem at cigital.com (Gary McGraw)
Date: Sun, 21 May 2006 11:40:04 -0400
Subject: [SC-L] Ajax one panel
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEB4C@va-mail.cigital.com>

You guys are both right, but talking about different things.

You can kludge pretend closure for a security critical section using the static final nonsense to make a hole on the unbound environment.  I described this in some detail in a 1999 javaworld article.  Havung closure would lead to a better sandbox.

The luring attacks that john describes were not what I was getting at, but they lend more weight to the argument for closure.

Yay, language arcana!

gem
 

 -----Original Message-----
From: 	Johan Peeters [mailto:info at secappdev.org]
Sent:	Sun May 21 09:08:14 2006
To:	John Steven
Cc:	Gary McGraw; Mailing List, Secure Coding; SSG
Subject:	Re: [SC-L] Ajax one panel

We may be at cross purposes. I understand your concern about luring 
attacks, John. I am sure you are right and they are feasible, but I 
interpreted Gary's comment as meaning 'closures can be used to build a 
more reliable sandbox'. But maybe this is not what is meant?

kr,

Yo

John Steven wrote:
> Johan,
> 
> Yes, the attacks are feasible. Please refer to the Java language  spec. 
> on inner/outer class semantics and fool around with simple test  cases 
> (and javap -c) to show yourself what's happening during the  compile step.
> 
> Attacks require getting code inside the victim VM but mine pass  
> verification silently (even with verifier turned on). Calling the  
> privileged class to lure it into doing your bidding requires only an  
> open package (not signed and sealed -- again see spec.) and other fun- 
> and-excitement can be had if the Developer hasn't been careful enough  
> to define the PriviledgedAction subclass as an explicit top-level  class 
> and they've passed information to-and-fro using the inner class  
> syntactic sugar--rather than explicit method calls defined pre- compile 
> time.
> 
> ----
> John Steven
> Technical Director; Principal, Software Security Group
> Direct: (703) 404-5726 Cell: (703) 727-4034
> Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F
> http://www.cigital.com
> Software Confidence. Achieved.
> 
> 
> On May 21, 2006, at 8:23 AM, Johan Peeters wrote:
> 
>> That sounds like a very exciting idea, but I am not sure about the  
>> mechanics of getting that to work. I assume the permissions for the  
>> untrusted code would be in the closure's environment. Who would put  
>> them there? How would the untrusted code call privileged code?
>> Has anyone done this?
>>
>> kr,
>>
>> Yo
>>
>> Gary McGraw wrote:
>>
>>> Hi yo!
>>> Closure is very helpful when doing things like crossing trust  
>>> boundaries.  If you look at the craziness involved in properly  
>>> invoking the doprivilege() stuff in java2, the need for closure is  
>>> strikingly obvious.
>>> However, closure itself is not as important as type safety is.    So 
>>> the fact that javascript may (or may not) have closure fails in  
>>> comparison to the fact that it is not type safe.
>>> Ajax is a disaster from a security perspective.
>>> gem
>>>  -----Original Message-----
>>> From:     Johan Peeters [mailto:info at secappdev.org]
>>> Sent:    Sat May 20 15:44:46 2006
>>> To:    Gary McGraw
>>> Cc:    Mailing List, Secure Coding; SSG
>>> Subject:    Re: [SC-L] Ajax one panel
>>> I think Java would have been a better language with closures, but  I 
>>> am intrigued that you raise them here. Do you think closures  present 
>>> security benefits? Or is this a veiled reference to Ajax?  I guess 
>>> JavaScript has closures.
>>> kr,
>>> Yo
>>> Gary McGraw wrote:
>>>
>>>> Ok...it was java one.  But it seemed like ajax one on the show  
>>>> floor.   I participated in a panel yesterday with superstar bill  
>>>> joy.  I had a chance to talk to bill for a while after the gig  and 
>>>> asked him why java did not have closure.  Bill said he was on  a 
>>>> committee of five, and got out-voted 2 to 3 on that one (and  some 
>>>> other stuff too).  You know the other pro vote had to be guy  
>>>> steele.  Most interesting.  Tyranny of the majority even in java.
>>>>
>>>> Btw, bill also said they tried twice to build an OS on java and  
>>>> failed both times.  We both agree that a type safe OS will happen  
>>>> one day.
>>>>
>>>> Here's a blog entry from john waters that describes the panel  from 
>>>> his point of view.
>>>>
>>>> http://www.adtmag.com/blogs/blog.aspx?a=18564
>>>>
>>>> gem
>>>> www.cigital.com
>>>> www.swsec.com
>>>>
>>>>
>>>> Sent from my treo.
>>>>
>>>>
>>>> -------------------------------------------------------------------- 
>>>> --------
>>>> This electronic message transmission contains information that  may be
>>>> confidential or privileged.  The information contained herein is  
>>>> intended
>>>> solely for the recipient and use by any other party is not  
>>>> authorized.  If
>>>> you are not the intended recipient (or otherwise authorized to  
>>>> receive this
>>>> message by the intended recipient), any disclosure, copying,  
>>>> distribution or
>>>> use of the contents of the information is prohibited.  If you  have 
>>>> received
>>>> this electronic message transmission in error, please contact the  
>>>> sender by
>>>> reply email and delete all copies of this message.  Cigital, Inc.  
>>>> accepts no
>>>> responsibility for any loss or damage resulting directly or  
>>>> indirectly from
>>>> the use of this email or its contents.
>>>> Thank You.
>>>> -------------------------------------------------------------------- 
>>>> --------
>>>>
>>>> _______________________________________________
>>>> Secure Coding mailing list (SC-L)
>>>> SC-L at securecoding.org
>>>> List information, subscriptions, etc - http://krvw.com/mailman/ 
>>>> listinfo/sc-l
>>>> List charter available at - http://www.securecoding.org/list/ 
>>>> charter.php
>>>>
>>>>
>>
>> -- 
>> Johan Peeters
>> program director
>> http://www.secappdev.org
>> +32 16 649000
> 
> 
> 
> 
> ---------------------------------------------------------------------------- 
> 
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, 
> distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. 
> accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ---------------------------------------------------------------------------- 
> 
> 
> 

-- 
Johan Peeters
program director
http://www.secappdev.org
+32 16 649000




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From info at secappdev.org  Sat May 20 15:33:33 2006
From: info at secappdev.org (Johan Peeters)
Date: Sat, 20 May 2006 21:33:33 +0200
Subject: [SC-L] Ajax one panel
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEAE5@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEAE5@va-mail.cigital.com>
Message-ID: <446F6F0D.3020507@secappdev.org>

I think Java would have been a better language with closures, but I am 
intrigued that you raise them here. Do you think closures present 
security benefits? Or is this a veiled reference to Ajax? I guess 
JavaScript has closures.

kr,

Yo

Gary McGraw wrote:
> Ok...it was java one.  But it seemed like ajax one on the show floor.   I participated in a panel yesterday with superstar bill joy.  I had a chance to talk to bill for a while after the gig and asked him why java did not have closure.  Bill said he was on a committee of five, and got out-voted 2 to 3 on that one (and some other stuff too).  You know the other pro vote had to be guy steele.  Most interesting.  Tyranny of the majority even in java.
> 
> Btw, bill also said they tried twice to build an OS on java and failed both times.  We both agree that a type safe OS will happen one day.
> 
> Here's a blog entry from john waters that describes the panel from his point of view.
> 
> http://www.adtmag.com/blogs/blog.aspx?a=18564
> 
> gem
> www.cigital.com
> www.swsec.com
> 
> 
> Sent from my treo.
> 
> 
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 
> 

-- 
Johan Peeters
program director
http://www.secappdev.org
+32 16 649000


From info at secappdev.org  Sun May 21 08:23:28 2006
From: info at secappdev.org (Johan Peeters)
Date: Sun, 21 May 2006 14:23:28 +0200
Subject: [SC-L] Ajax one panel
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEB47@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEB47@va-mail.cigital.com>
Message-ID: <44705BC0.7000004@secappdev.org>

That sounds like a very exciting idea, but I am not sure about the 
mechanics of getting that to work. I assume the permissions for the 
untrusted code would be in the closure's environment. Who would put them 
there? How would the untrusted code call privileged code?
Has anyone done this?

kr,

Yo

Gary McGraw wrote:
> Hi yo!
> 
> Closure is very helpful when doing things like crossing trust boundaries.  If you look at the craziness involved in properly invoking the doprivilege() stuff in java2, the need for closure is strikingly obvious.
> 
> However, closure itself is not as important as type safety is.   So the fact that javascript may (or may not) have closure fails in comparison to the fact that it is not type safe.
> 
> Ajax is a disaster from a security perspective.
> 
> gem
> 
>  -----Original Message-----
> From: 	Johan Peeters [mailto:info at secappdev.org]
> Sent:	Sat May 20 15:44:46 2006
> To:	Gary McGraw
> Cc:	Mailing List, Secure Coding; SSG
> Subject:	Re: [SC-L] Ajax one panel
> 
> I think Java would have been a better language with closures, but I am 
> intrigued that you raise them here. Do you think closures present 
> security benefits? Or is this a veiled reference to Ajax? I guess 
> JavaScript has closures.
> 
> kr,
> 
> Yo
> 
> Gary McGraw wrote:
> 
>>Ok...it was java one.  But it seemed like ajax one on the show floor.   I participated in a panel yesterday with superstar bill joy.  I had a chance to talk to bill for a while after the gig and asked him why java did not have closure.  Bill said he was on a committee of five, and got out-voted 2 to 3 on that one (and some other stuff too).  You know the other pro vote had to be guy steele.  Most interesting.  Tyranny of the majority even in java.
>>
>>Btw, bill also said they tried twice to build an OS on java and failed both times.  We both agree that a type safe OS will happen one day.
>>
>>Here's a blog entry from john waters that describes the panel from his point of view.
>>
>>http://www.adtmag.com/blogs/blog.aspx?a=18564
>>
>>gem
>>www.cigital.com
>>www.swsec.com
>>
>>
>>Sent from my treo.
>>
>>
>>----------------------------------------------------------------------------
>>This electronic message transmission contains information that may be
>>confidential or privileged.  The information contained herein is intended
>>solely for the recipient and use by any other party is not authorized.  If
>>you are not the intended recipient (or otherwise authorized to receive this
>>message by the intended recipient), any disclosure, copying, distribution or
>>use of the contents of the information is prohibited.  If you have received
>>this electronic message transmission in error, please contact the sender by
>>reply email and delete all copies of this message.  Cigital, Inc. accepts no
>>responsibility for any loss or damage resulting directly or indirectly from
>>the use of this email or its contents.
>>Thank You.
>>----------------------------------------------------------------------------
>>
>>_______________________________________________
>>Secure Coding mailing list (SC-L)
>>SC-L at securecoding.org
>>List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
>>List charter available at - http://www.securecoding.org/list/charter.php
>>
>>
> 
> 

-- 
Johan Peeters
program director
http://www.secappdev.org
+32 16 649000


From info at secappdev.org  Sun May 21 08:56:32 2006
From: info at secappdev.org (Johan Peeters)
Date: Sun, 21 May 2006 14:56:32 +0200
Subject: [SC-L] Ajax one panel
In-Reply-To: <F0A7498A-92DE-4476-9505-415139555C95@cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEB47@va-mail.cigital.com>
	<44705BC0.7000004@secappdev.org>
	<F0A7498A-92DE-4476-9505-415139555C95@cigital.com>
Message-ID: <44706380.9060703@secappdev.org>

We may be at cross purposes. I understand your concern about luring 
attacks, John. I am sure you are right and they are feasible, but I 
interpreted Gary's comment as meaning 'closures can be used to build a 
more reliable sandbox'. But maybe this is not what is meant?

kr,

Yo

John Steven wrote:
> Johan,
> 
> Yes, the attacks are feasible. Please refer to the Java language  spec. 
> on inner/outer class semantics and fool around with simple test  cases 
> (and javap -c) to show yourself what's happening during the  compile step.
> 
> Attacks require getting code inside the victim VM but mine pass  
> verification silently (even with verifier turned on). Calling the  
> privileged class to lure it into doing your bidding requires only an  
> open package (not signed and sealed -- again see spec.) and other fun- 
> and-excitement can be had if the Developer hasn't been careful enough  
> to define the PriviledgedAction subclass as an explicit top-level  class 
> and they've passed information to-and-fro using the inner class  
> syntactic sugar--rather than explicit method calls defined pre- compile 
> time.
> 
> ----
> John Steven
> Technical Director; Principal, Software Security Group
> Direct: (703) 404-5726 Cell: (703) 727-4034
> Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F
> http://www.cigital.com
> Software Confidence. Achieved.
> 
> 
> On May 21, 2006, at 8:23 AM, Johan Peeters wrote:
> 
>> That sounds like a very exciting idea, but I am not sure about the  
>> mechanics of getting that to work. I assume the permissions for the  
>> untrusted code would be in the closure's environment. Who would put  
>> them there? How would the untrusted code call privileged code?
>> Has anyone done this?
>>
>> kr,
>>
>> Yo
>>
>> Gary McGraw wrote:
>>
>>> Hi yo!
>>> Closure is very helpful when doing things like crossing trust  
>>> boundaries.  If you look at the craziness involved in properly  
>>> invoking the doprivilege() stuff in java2, the need for closure is  
>>> strikingly obvious.
>>> However, closure itself is not as important as type safety is.    So 
>>> the fact that javascript may (or may not) have closure fails in  
>>> comparison to the fact that it is not type safe.
>>> Ajax is a disaster from a security perspective.
>>> gem
>>>  -----Original Message-----
>>> From:     Johan Peeters [mailto:info at secappdev.org]
>>> Sent:    Sat May 20 15:44:46 2006
>>> To:    Gary McGraw
>>> Cc:    Mailing List, Secure Coding; SSG
>>> Subject:    Re: [SC-L] Ajax one panel
>>> I think Java would have been a better language with closures, but  I 
>>> am intrigued that you raise them here. Do you think closures  present 
>>> security benefits? Or is this a veiled reference to Ajax?  I guess 
>>> JavaScript has closures.
>>> kr,
>>> Yo
>>> Gary McGraw wrote:
>>>
>>>> Ok...it was java one.  But it seemed like ajax one on the show  
>>>> floor.   I participated in a panel yesterday with superstar bill  
>>>> joy.  I had a chance to talk to bill for a while after the gig  and 
>>>> asked him why java did not have closure.  Bill said he was on  a 
>>>> committee of five, and got out-voted 2 to 3 on that one (and  some 
>>>> other stuff too).  You know the other pro vote had to be guy  
>>>> steele.  Most interesting.  Tyranny of the majority even in java.
>>>>
>>>> Btw, bill also said they tried twice to build an OS on java and  
>>>> failed both times.  We both agree that a type safe OS will happen  
>>>> one day.
>>>>
>>>> Here's a blog entry from john waters that describes the panel  from 
>>>> his point of view.
>>>>
>>>> http://www.adtmag.com/blogs/blog.aspx?a=18564
>>>>
>>>> gem
>>>> www.cigital.com
>>>> www.swsec.com
>>>>
>>>>
>>>> Sent from my treo.
>>>>
>>>>
>>>> -------------------------------------------------------------------- 
>>>> --------
>>>> This electronic message transmission contains information that  may be
>>>> confidential or privileged.  The information contained herein is  
>>>> intended
>>>> solely for the recipient and use by any other party is not  
>>>> authorized.  If
>>>> you are not the intended recipient (or otherwise authorized to  
>>>> receive this
>>>> message by the intended recipient), any disclosure, copying,  
>>>> distribution or
>>>> use of the contents of the information is prohibited.  If you  have 
>>>> received
>>>> this electronic message transmission in error, please contact the  
>>>> sender by
>>>> reply email and delete all copies of this message.  Cigital, Inc.  
>>>> accepts no
>>>> responsibility for any loss or damage resulting directly or  
>>>> indirectly from
>>>> the use of this email or its contents.
>>>> Thank You.
>>>> -------------------------------------------------------------------- 
>>>> --------
>>>>
>>>> _______________________________________________
>>>> Secure Coding mailing list (SC-L)
>>>> SC-L at securecoding.org
>>>> List information, subscriptions, etc - http://krvw.com/mailman/ 
>>>> listinfo/sc-l
>>>> List charter available at - http://www.securecoding.org/list/ 
>>>> charter.php
>>>>
>>>>
>>
>> -- 
>> Johan Peeters
>> program director
>> http://www.secappdev.org
>> +32 16 649000
> 
> 
> 
> 
> ---------------------------------------------------------------------------- 
> 
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, 
> distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. 
> accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ---------------------------------------------------------------------------- 
> 
> 
> 

-- 
Johan Peeters
program director
http://www.secappdev.org
+32 16 649000


From info at secappdev.org  Sun May 21 15:19:03 2006
From: info at secappdev.org (Johan Peeters)
Date: Sun, 21 May 2006 21:19:03 +0200
Subject: [SC-L] Ajax one panel
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEB4C@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEB4C@va-mail.cigital.com>
Message-ID: <4470BD27.1080901@secappdev.org>

thanks for the clarification, Gary. So I would like to restate my 
question as follows: do you know of any (atempts at) implementations of 
a sandbox based on closures? It seems to me that there are some tricky 
issues like how the permissions get into the closure or how privileged 
code is called. But that's probably due to the limitations on my 
imagination.

Meanwhile, at Artima 
(http://www.artima.com/weblogs/viewpost.jsp?thread=161019) and 
ObjectMentor 
(http://blogs.objectmentor.com/ArticleS.MichaelFeathers.ItsTimeToDeprecateFinal), 
people are also discussing the 'final kludge', calling for 'final' to 
become deprecated. It would be nice to think there is something that 
could take its place :-)

kr,

Yo

Gary McGraw wrote:
> You guys are both right, but talking about different things.
> 
> You can kludge pretend closure for a security critical section using the static final nonsense to make a hole on the unbound environment.  I described this in some detail in a 1999 javaworld article.  Havung closure would lead to a better sandbox.
> 
> The luring attacks that john describes were not what I was getting at, but they lend more weight to the argument for closure.
> 
> Yay, language arcana!
> 
> gem
>  
> 
>  -----Original Message-----
> From: 	Johan Peeters [mailto:info at secappdev.org]
> Sent:	Sun May 21 09:08:14 2006
> To:	John Steven
> Cc:	Gary McGraw; Mailing List, Secure Coding; SSG
> Subject:	Re: [SC-L] Ajax one panel
> 
> We may be at cross purposes. I understand your concern about luring 
> attacks, John. I am sure you are right and they are feasible, but I 
> interpreted Gary's comment as meaning 'closures can be used to build a 
> more reliable sandbox'. But maybe this is not what is meant?
> 
> kr,
> 
> Yo
> 
> John Steven wrote:
> 
>>Johan,
>>
>>Yes, the attacks are feasible. Please refer to the Java language  spec. 
>>on inner/outer class semantics and fool around with simple test  cases 
>>(and javap -c) to show yourself what's happening during the  compile step.
>>
>>Attacks require getting code inside the victim VM but mine pass  
>>verification silently (even with verifier turned on). Calling the  
>>privileged class to lure it into doing your bidding requires only an  
>>open package (not signed and sealed -- again see spec.) and other fun- 
>>and-excitement can be had if the Developer hasn't been careful enough  
>>to define the PriviledgedAction subclass as an explicit top-level  class 
>>and they've passed information to-and-fro using the inner class  
>>syntactic sugar--rather than explicit method calls defined pre- compile 
>>time.
>>
>>----
>>John Steven
>>Technical Director; Principal, Software Security Group
>>Direct: (703) 404-5726 Cell: (703) 727-4034
>>Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F
>>http://www.cigital.com
>>Software Confidence. Achieved.
>>
>>
>>On May 21, 2006, at 8:23 AM, Johan Peeters wrote:
>>
>>
>>>That sounds like a very exciting idea, but I am not sure about the  
>>>mechanics of getting that to work. I assume the permissions for the  
>>>untrusted code would be in the closure's environment. Who would put  
>>>them there? How would the untrusted code call privileged code?
>>>Has anyone done this?
>>>
>>>kr,
>>>
>>>Yo
>>>
>>>Gary McGraw wrote:
>>>
>>>
>>>>Hi yo!
>>>>Closure is very helpful when doing things like crossing trust  
>>>>boundaries.  If you look at the craziness involved in properly  
>>>>invoking the doprivilege() stuff in java2, the need for closure is  
>>>>strikingly obvious.
>>>>However, closure itself is not as important as type safety is.    So 
>>>>the fact that javascript may (or may not) have closure fails in  
>>>>comparison to the fact that it is not type safe.
>>>>Ajax is a disaster from a security perspective.
>>>>gem
>>>> -----Original Message-----
>>>>From:     Johan Peeters [mailto:info at secappdev.org]
>>>>Sent:    Sat May 20 15:44:46 2006
>>>>To:    Gary McGraw
>>>>Cc:    Mailing List, Secure Coding; SSG
>>>>Subject:    Re: [SC-L] Ajax one panel
>>>>I think Java would have been a better language with closures, but  I 
>>>>am intrigued that you raise them here. Do you think closures  present 
>>>>security benefits? Or is this a veiled reference to Ajax?  I guess 
>>>>JavaScript has closures.
>>>>kr,
>>>>Yo
>>>>Gary McGraw wrote:
>>>>
>>>>
>>>>>Ok...it was java one.  But it seemed like ajax one on the show  
>>>>>floor.   I participated in a panel yesterday with superstar bill  
>>>>>joy.  I had a chance to talk to bill for a while after the gig  and 
>>>>>asked him why java did not have closure.  Bill said he was on  a 
>>>>>committee of five, and got out-voted 2 to 3 on that one (and  some 
>>>>>other stuff too).  You know the other pro vote had to be guy  
>>>>>steele.  Most interesting.  Tyranny of the majority even in java.
>>>>>
>>>>>Btw, bill also said they tried twice to build an OS on java and  
>>>>>failed both times.  We both agree that a type safe OS will happen  
>>>>>one day.
>>>>>
>>>>>Here's a blog entry from john waters that describes the panel  from 
>>>>>his point of view.
>>>>>
>>>>>http://www.adtmag.com/blogs/blog.aspx?a=18564
>>>>>
>>>>>gem
>>>>>www.cigital.com
>>>>>www.swsec.com
>>>>>
>>>>>
>>>>>Sent from my treo.
>>>>>
>>>>>
>>>>>-------------------------------------------------------------------- 
>>>>>--------
>>>>>This electronic message transmission contains information that  may be
>>>>>confidential or privileged.  The information contained herein is  
>>>>>intended
>>>>>solely for the recipient and use by any other party is not  
>>>>>authorized.  If
>>>>>you are not the intended recipient (or otherwise authorized to  
>>>>>receive this
>>>>>message by the intended recipient), any disclosure, copying,  
>>>>>distribution or
>>>>>use of the contents of the information is prohibited.  If you  have 
>>>>>received
>>>>>this electronic message transmission in error, please contact the  
>>>>>sender by
>>>>>reply email and delete all copies of this message.  Cigital, Inc.  
>>>>>accepts no
>>>>>responsibility for any loss or damage resulting directly or  
>>>>>indirectly from
>>>>>the use of this email or its contents.
>>>>>Thank You.
>>>>>-------------------------------------------------------------------- 
>>>>>--------
>>>>>
>>>>>_______________________________________________
>>>>>Secure Coding mailing list (SC-L)
>>>>>SC-L at securecoding.org
>>>>>List information, subscriptions, etc - http://krvw.com/mailman/ 
>>>>>listinfo/sc-l
>>>>>List charter available at - http://www.securecoding.org/list/ 
>>>>>charter.php
>>>>>
>>>>>
>>>
>>>-- 
>>>Johan Peeters
>>>program director
>>>http://www.secappdev.org
>>>+32 16 649000
>>
>>
>>
>>
>>---------------------------------------------------------------------------- 
>>
>>This electronic message transmission contains information that may be
>>confidential or privileged.  The information contained herein is intended
>>solely for the recipient and use by any other party is not authorized.  If
>>you are not the intended recipient (or otherwise authorized to receive this
>>message by the intended recipient), any disclosure, copying, 
>>distribution or
>>use of the contents of the information is prohibited.  If you have received
>>this electronic message transmission in error, please contact the sender by
>>reply email and delete all copies of this message.  Cigital, Inc. 
>>accepts no
>>responsibility for any loss or damage resulting directly or indirectly from
>>the use of this email or its contents.
>>Thank You.
>>---------------------------------------------------------------------------- 
>>
>>
>>
> 
> 

-- 
Johan Peeters
program director
http://www.secappdev.org
+32 16 649000


From jsteven at cigital.com  Sun May 21 08:43:51 2006
From: jsteven at cigital.com (John Steven)
Date: Sun, 21 May 2006 08:43:51 -0400
Subject: [SC-L] Ajax one panel
In-Reply-To: <44705BC0.7000004@secappdev.org>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEB47@va-mail.cigital.com>
	<44705BC0.7000004@secappdev.org>
Message-ID: <F0A7498A-92DE-4476-9505-415139555C95@cigital.com>

Johan,

Yes, the attacks are feasible. Please refer to the Java language  
spec. on inner/outer class semantics and fool around with simple test  
cases (and javap -c) to show yourself what's happening during the  
compile step.

Attacks require getting code inside the victim VM but mine pass  
verification silently (even with verifier turned on). Calling the  
privileged class to lure it into doing your bidding requires only an  
open package (not signed and sealed -- again see spec.) and other fun- 
and-excitement can be had if the Developer hasn't been careful enough  
to define the PriviledgedAction subclass as an explicit top-level  
class and they've passed information to-and-fro using the inner class  
syntactic sugar--rather than explicit method calls defined pre- 
compile time.

----
John Steven
Technical Director; Principal, Software Security Group
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F
http://www.cigital.com
Software Confidence. Achieved.


On May 21, 2006, at 8:23 AM, Johan Peeters wrote:

> That sounds like a very exciting idea, but I am not sure about the  
> mechanics of getting that to work. I assume the permissions for the  
> untrusted code would be in the closure's environment. Who would put  
> them there? How would the untrusted code call privileged code?
> Has anyone done this?
>
> kr,
>
> Yo
>
> Gary McGraw wrote:
>> Hi yo!
>> Closure is very helpful when doing things like crossing trust  
>> boundaries.  If you look at the craziness involved in properly  
>> invoking the doprivilege() stuff in java2, the need for closure is  
>> strikingly obvious.
>> However, closure itself is not as important as type safety is.    
>> So the fact that javascript may (or may not) have closure fails in  
>> comparison to the fact that it is not type safe.
>> Ajax is a disaster from a security perspective.
>> gem
>>  -----Original Message-----
>> From: 	Johan Peeters [mailto:info at secappdev.org]
>> Sent:	Sat May 20 15:44:46 2006
>> To:	Gary McGraw
>> Cc:	Mailing List, Secure Coding; SSG
>> Subject:	Re: [SC-L] Ajax one panel
>> I think Java would have been a better language with closures, but  
>> I am intrigued that you raise them here. Do you think closures  
>> present security benefits? Or is this a veiled reference to Ajax?  
>> I guess JavaScript has closures.
>> kr,
>> Yo
>> Gary McGraw wrote:
>>> Ok...it was java one.  But it seemed like ajax one on the show  
>>> floor.   I participated in a panel yesterday with superstar bill  
>>> joy.  I had a chance to talk to bill for a while after the gig  
>>> and asked him why java did not have closure.  Bill said he was on  
>>> a committee of five, and got out-voted 2 to 3 on that one (and  
>>> some other stuff too).  You know the other pro vote had to be guy  
>>> steele.  Most interesting.  Tyranny of the majority even in java.
>>>
>>> Btw, bill also said they tried twice to build an OS on java and  
>>> failed both times.  We both agree that a type safe OS will happen  
>>> one day.
>>>
>>> Here's a blog entry from john waters that describes the panel  
>>> from his point of view.
>>>
>>> http://www.adtmag.com/blogs/blog.aspx?a=18564
>>>
>>> gem
>>> www.cigital.com
>>> www.swsec.com
>>>
>>>
>>> Sent from my treo.
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> --------
>>> This electronic message transmission contains information that  
>>> may be
>>> confidential or privileged.  The information contained herein is  
>>> intended
>>> solely for the recipient and use by any other party is not  
>>> authorized.  If
>>> you are not the intended recipient (or otherwise authorized to  
>>> receive this
>>> message by the intended recipient), any disclosure, copying,  
>>> distribution or
>>> use of the contents of the information is prohibited.  If you  
>>> have received
>>> this electronic message transmission in error, please contact the  
>>> sender by
>>> reply email and delete all copies of this message.  Cigital, Inc.  
>>> accepts no
>>> responsibility for any loss or damage resulting directly or  
>>> indirectly from
>>> the use of this email or its contents.
>>> Thank You.
>>> -------------------------------------------------------------------- 
>>> --------
>>>
>>> _______________________________________________
>>> Secure Coding mailing list (SC-L)
>>> SC-L at securecoding.org
>>> List information, subscriptions, etc - http://krvw.com/mailman/ 
>>> listinfo/sc-l
>>> List charter available at - http://www.securecoding.org/list/ 
>>> charter.php
>>>
>>>
>
> -- 
> Johan Peeters
> program director
> http://www.secappdev.org
> +32 16 649000



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From dinis at ddplus.net  Tue May 23 18:34:00 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Tue, 23 May 2006 23:34:00 +0100
Subject: [SC-L] Re: [WEB SECURITY] On sandboxes, and why you should care
In-Reply-To: <AEF0C4CD-70B7-4178-BAA5-58CC1BE5C938@corsaire.com>
References: <442BA1C2.3080008@ddplus.net>
	<AEF0C4CD-70B7-4178-BAA5-58CC1BE5C938@corsaire.com>
Message-ID: <44738DD8.1070803@ddplus.net>

(sorry for the long time that it took for this response, see comments 
inline)

Stephen de Vries wrote:
> Hi Dinis,
>
> I think you're overestimating the effectiveness of a sandbox in 
> preventing common web app vulnerabilities, and you're instead 
> focussing on the tiny fraction of specific attacks that can be stopped 
> with sandboxes.
Well Stephen, I would argue that you are underestimating that 
effectiveness :)

I also don't think that I am focusing on a tiny fraction of specific 
attacks. Sandboxes have the capability to resolve most of the current 
types of attacks we have today. And the ones that it is not able solve, 
it will make them easy to detect.

In fact, I would argue that Sandboxing could actually make the 
'Sandboxed Application' more simple, effective, cheaper to develop and 
easier to audit.
> The fundamental point of departure between our points of view is that 
> I would argue that, the crown jewels are already inside the sandbox!
I think that you are thinking of a unidimensional Sandbox model similar 
to the one created by the Operating system between user-land process and 
kernel, or the one implemented by .Net / Java for mobile code executed 
on a web browser.

In the solution that I am envisioning, you will have multiple Sandboxes, 
one inside the other, separated by very clearly defined layers (the 
input choke points / attack surface) where each sandbox is allocated 
privileges accordingly to what it needs to get the job done (principle 
of least privilege),  the amount of trust that we have in that code 
(Code Access Security) and the identity used to executed it (Role Based 
Security).

Unfortunately the Partial Trust Sandboxes that currently exist on the 
.Net Framework (namely Medium Trust) are not good examples of Sandboxes 
since they still allow the creation of easy exploitable Asp.Net code 
(i.e. the security vulnerabilities that you mention below would still 
occur on a web application executed under Medium Trust).
> So spending time and effort to strengthen the walls isn't going to do 
> any real good in preventing an attacker from getting hold of them.
The plan is to put has many walls as possible between the attacker and 
the assets.
>> <snip>
>>
>> Also remember that more and more we will have to deal with malicious
>> developers, or with malicious attackers that are able to inject
>> malicious code into a website via:
>>     - a library used by a developer
>>     - a compromised developer account details (which tend to be sent by
>> email)
>>     - a compromised developer computer (infected via Spyware) which
>> allows the malicious attacker to control remotely that computer and
>> (for example) Eclipse or Visual Studio in memory so that every
>> time a piece of code its submitted (checked-in) , the malicious
>> payloads are inserted.
>
> I don't follow your argument here.  You're saying that by running in a 
> sandbox we would prevent a developer with malicious intent from 
> executing evil code(?).  Granted that a sandbox may limit specific 
> operations such as writing or reading from the OS or making network 
> connections, but that doesn't mean you would prevent them from 
> accessing all the private data in the database or from allowing one 
> user to view another's data.  
Of course you can.

I can create a .Net environment which prevents those developers from 
accessing directly the database (in the case where malicious code was 
uploaded to the server).

CAS allows the creation of custom permissions which could be used to 
implement 'Data-Sandboxed environments' which enforce application-logic 
to the sandboxed code (for example not-allowing access to private data 
stored within the database or other user's data)
> Sandboxing is not going to make any difference here, but external 
> controls such as vetting your developers and auditing the code would 
> make a very real contribution to improving the security.
Although this is important, and will have to be done for certain types 
of code (namely the ones we will place more trust (and will pay more 
for)), this will not scale up (i.e. work for ALL software that is 
executed in your computer).

Just do this simple test: analyze your computer and list every single 
application that you have installed (if you have time, try also listing 
the writers of the individual components (dlls, static libraries, 
etc...) used by those applications), once you have that list of 
applications which will have access to ALL your user-land assets (let's 
ignore for now the ones that also have (or had) administrative 
privileges to your box), ask yourself  the question: "Do I really trust 
every single developer that worked on this applications/modules?".

And even if somebody had vetted their developers and audited their code, 
how would you know?

Another thing that I like about the Sandboxed model is the fact that it 
would also allow the pragmatic analysis of different applications 
security (i.e. metrics)
> If you add up the number of people that have the capability to put one
>> line of malicious code on a web server, you will see that this is a
>> very large number indeed.
>
> And that one line of malicious code can do a lot of damage _even in a 
> sandboxed environment_.
>
That depends on the Sandboxed environment :)

If that Sandboxed environment is properly enforced, then the amount of 
damage created by this one line of could be controlled, limited and (if 
anybody was looking) detected
>> <snip>
>> A couple more examples of ways malicious code can be uploaded to the
>> server: SQL Injection,
if the code 'injected' by an SQL Injection is executed in a Sandboxed 
environment, then the damage potential for that SQL Injection is very 
limited.
>> XSS (payload deployed to the admin section),
XSS (since being a client-side exploit) is one where the Sandbox 
approach would be harder to implement (unless the affected user is also 
using a Sandboxed browser where some types of exploits could be prevented).

To prevent XSS via a Sandbox, one approach would be to use the Sandbox 
model to clearly define the 'input chokepoints' and force (via CAS 
Demands) that data validation was performed on those requests. This way, 
the developers would have no option but to validate their data. Another 
option would be to encode all inputs and outputs from the untrusted 
sandboxes (i.e. only the 'trusted' sandboxes would have the ability to 
manipulate Html directly.
>> authorization vulnerabilities which allow the editing of files on the
>> server (via for example the CMS (content management system)),
This is the easier one of solve since the current CAS contains ample 
support for File's (code and role based) security decisions
>> manipulating params which control which method is executed (when
>> Reflection is used to perform late binding on method calls based on
>> the commands received) 
Again, using CAS (Code Access Security) you can control what code can be 
executed by each layer of the Sandbox
>> ,Social engineering, etc...
If you do a Thread Model on a multi-layer Sandboxed application, you 
will see that the 'attack surface' for social engineering will be 
dramatically reduced (when compared with a similar non-Sandboxed 
application).
>>
>> Sometimes you will even find CMS (Content Management Systems) that
>> provide power users (or 'area x' admins) with powerful customization
>> features which when exploited (or not, depending if this is a
>> 'feature') allow the injection of code.
Yes, but if these powerful customizations are executed inside a Sandbox 
then its damage potential are dramatically reduced.

Another good example is Cookie's Generation.

Under normal circumstances, malicious .Aspx code could create a 'Cookie 
Generator' for a Forms Authentication website which would allow the 
impersonation of any user in a way which would make its detection almost 
impossible.

I could create a Sandboxed environment which would prevent that  'Cookie 
Generator' from working.
>> Do you really think that it is a good idea to have your entire data
>> center security and CIA (Confidentiality, Integrity and Availability)
>> depended on such extraordinary set of circumstances?
>>
>> So the first main security benefit that we have with using Sandboxes
>> is: Containment, Damage Limitation, and Risk Reduction (you went from
>> full data center compromise to a local and limited problem)
>
> This only applies to environment where the value (to an attacker) of 
> compromising the data centre and web server is more than the value of 
> compromising the application itself.  In the majority of web 
> applications, the data stored by the app itself is the nazi gold - not 
> the webserver or surrounding infrastructure.  So sandboxing the app 
> will not add any protection to the stuff I care about most: my data.
It will, the problem here is that we are looking at this issue from 
different points of view. You are thinking that the sandbox will go 
between the Operating System and the Application (where ALL assets are), 
and I am thinking that the Sandbox(es) will be placed between the Assets 
and the potential malicious code/activities.

But your comment "... This only applies to environment where the value 
(to an attacker) of compromising the data center and web server is more 
that the value of compromising the application itself..." is spot on!

And in fact it shows how ineffective (from a security point of view) is 
the current focus on Non-Administrator environments, since they are only 
protecting the hardware and not the assets.
>> <snip>
>>
>> So let's look at another application (App B) which has the same
>> functionality but, is executed in three Sandboxes:
>>
>>  - Sandbox A) 450,000 lines of code executed in very restricted
>> Sandbox (let's say Asp.Net Low Trust)
>>
>>   - Sandbox B) 48,000 lines of code executed in secure Sandbox (let's
>> say customized version of Asp.Net Medium Trust)
>>
>>   - Sandbox C) 2,000 lines of code executed in a Sandbox which allows
>> calls to unmanaged code.
>>
>> Given the same 1 week, you (as the security consultant auditing this
>> application) will spend most of your time in Sandbox C) code, less on
>> Sandbox B) code and even less on Sandbox A) code. Why? because only a
>> vulnerability in Sandbox C) would allow the compromise of the entire
>> App / Server / Datacenter.
>
> I disagree.  Any one of those 450,000 lines of perfectly sandboxed and 
> verifiable code could contain an SQL injection attack that would 
> compromise my entire database.
That depends on the run-time environment of those 450,000 lines of code.

On a proper Sandboxed environment, those 450,000 of code would be inside 
a Sandbox which would not allow direct database query manipulation 
(which cause SQL Injection), direct HTML manipulation (which cause XSS), 
Cookie Generation (which cause Session Hijacking), direct access to 
admin interfaces (which could cause Authorization issues), etc, etc, etc...

The idea is to protect with a strong Sandbox (or series of Sandboxes) 
the assets that those 450,000 of code can 'touch'
>   They could also contain access control flaws that let 
> unauthenticated users access private information.  Or allow an 
> attacker to use an XSS flaw to steal a session cookie.  Running in a 
> sandbox would not prevent _any_ of these serious security issues, all 
> of which could compromise the security of my data.
It could prevent those attacks if the the Sandbox was designed to do so.

Of course that somewhere, in one of those Sandboxes, there will be code 
that will be able to access the database directly. But if we are able to 
limit the amount of code that needs these privileges (Sandboxes B and C 
in the example above), then the amount of code that needs to be audited 
(and for example certified by a third party security-audit-company) will 
be smaller and manageable.
> To summarise, sandboxing an app is useful in preventing specific 
> attacks such as executing OS commands, making unauthorized connections 
> and accessing arbitrary system resources but it will not do anything 
> to prevent the vast majority of serious security issues affecting web 
> apps, because the valuable stuff is inside the sandbox.
After my explanations in this email do you still think that this is 
correct? Or can you accept now that it is possible to build a Sandboxed 
environment that is able to protect against the majority of the serious 
security issues that affect web apps today?

If you do accept that it is possible to build such sandboxes, then we 
need to move to the next interesting discussion, which is the 'HOW'

Namely, HOW can an environment be created where the development and 
deployment of such Sandboxes makes business sense.

Dinis Cruz
Owasp .Net Project
wiki.owasp.net




From leichter_jerrold at emc.com  Wed May 24 15:14:04 2006
From: leichter_jerrold at emc.com (leichter_jerrold at emc.com)
Date: Wed, 24 May 2006 15:14:04 -0400
Subject: [SC-L] Re: [WEB SECURITY] On sandboxes, and why you should ca re
Message-ID: <Pine.SOL.4.61.0605241500210.14726@mental>

| Stephen de Vries wrote:
| > Hi Dinis,
| > 
| > I think you're overestimating the effectiveness of a sandbox in
preventing
| > common web app vulnerabilities, and you're instead focussing on the tiny
| > fraction of specific attacks that can be stopped with sandboxes.
| Well Stephen, I would argue that you are underestimating that
effectiveness :)
| 
| I also don't think that I am focusing on a tiny fraction of specific
attacks.
| Sandboxes have the capability to resolve most of the current types of
attacks
| we have today. And the ones that it is not able solve, it will make them
easy
| to detect.
| 
| In fact, I would argue that Sandboxing could actually make the 'Sandboxed
| Application' more simple, effective, cheaper to develop and easier to
audit.
| > The fundamental point of departure between our points of view is that I
| > would argue that, the crown jewels are already inside the sandbox!
| I think that you are thinking of a unidimensional Sandbox model similar to
| the one created by the Operating system between user-land process and
| kernel, or the one implemented by .Net / Java for mobile code executed on
a
| web browser.
| 
| In the solution that I am envisioning, you will have multiple Sandboxes,
one
| inside the other, separated by very clearly defined layers (the input
choke
| points / attack surface) where each sandbox is allocated privileges
| accordingly to what it needs to get the job done (principle of least
| privilege),  the amount of trust that we have in that code (Code Access
| Security) and the identity used to executed it (Role Based Security).
Other than the nesting of the sandboxes - which can't possibly last, since
trust isn't uni-dimensional; I don't always trust code A "more" or "less"
than
code B, I may trust them to do different things - what you're proposing is
capabilities under a different name.  "Running in sandbox X" is the same
thing
as "running with capability set X".

On the one hand, there's 30 years of history that says capabilities do
indeed
give you a very powerful and effective way to define and enforce security
models.  On the other ... there's little in the way of fielded systems.
Capabilities have proven to be expensive to implement and, more to the
point,
difficult to understand and manage, once you get beyond the easiest
examples.
You can't just ignore this history - you have to show that you can do enough
better that your proposal won't be marginalized or forgotten the way most
capability-based systems have.

The big advantage of sandboxes as they are usually understood is their
simplicity.  They may not be able to model everything - in fact, they model
very few things - but those few things, they can model very simply and
manage
very effectively.  In their domain, they have no real competitors.

							-- Jerry


From crispin at novell.com  Thu May 25 00:33:33 2006
From: crispin at novell.com (Crispin Cowan)
Date: Wed, 24 May 2006 21:33:33 -0700
Subject: [SC-L] Ajax one panel
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEAE5@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEAE5@va-mail.cigital.com>
Message-ID: <4475339D.9040605@novell.com>

Gary McGraw wrote:
> Btw, bill also said they tried twice to build an OS on java and failed both times.  We both agree that a type safe OS will happen one day.
>   
Did he ever articulate what happened to these OS's? I recall a
presentation at OSDI 1996 by a Sun executive talking about JavaOS and
the spiffy new thin clients that Sun was going to introduce. He talked
about implementing the TCP/IP stack in pure Java, even with the problems
of type safety in marshalling raw data.

I had the impression that JavaOS failed for marketing reasons, not
technical. But that impression was formed from hearing the OSDI
presentation that described implementing JavaOS in the past tense.

So what was the real reason?

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com



From vanderaj at greebo.net  Wed May 24 23:03:16 2006
From: vanderaj at greebo.net (Andrew van der Stock)
Date: Thu, 25 May 2006 13:03:16 +1000
Subject: [SC-L] Re: [WEB SECURITY] On sandboxes, and why you should care
In-Reply-To: <44738DD8.1070803@ddplus.net>
References: <442BA1C2.3080008@ddplus.net>
	<AEF0C4CD-70B7-4178-BAA5-58CC1BE5C938@corsaire.com>
	<44738DD8.1070803@ddplus.net>
Message-ID: <061206CB-4943-4954-8EDE-B8EAADBD52EB@greebo.net>

Dinis,

Sandboxing prevents a machine from having bad system() and buffer  
overflows causing system compromise. Sure that's bad enough. However,  
sandboxing does not prevent:

* all types of cross-site scripting
* SQL injection
* Command injection via SQL injection (xp_cmdshell and similar Oracle  
library calls)
* Command injection as the limited capabilities allowed by the  
sandbox ... until the attacker can work out how to get out of the  
sandbox, say via a friendly unpatched service or tunnelling terminal  
services outbound, or similar
* LDAP injection
* XML injection
* authentication attacks, such as brute forcing etc
* failure of authorization code to protect controlled resources,  
operations or transactions
* file operations on the files the app is authorized to touch, often  
quite sensitive in themselves
* second order injections (ie batch integrity issues)
* middleware attacks
* web service attacks
* SMTP attacks - ie formmail.pl - if it's badly written, there's no  
way a sandbox will help

* or the usual sorts of transactions which can lose a business money,  
like ship X widgets to Y (phishing).

Sandboxing reduces but does not eliminate the risk that the app  
server process can go ahead and destroy the rest of the box, which is  
important in a shared environment. But if the attacker can run  
arbitrary code on your host, it's just a matter of time before they  
work out how to go from loading netcat to 0wning you. That's why  
PHP's "safe" mode is not really all that safe and in fact, is more  
than occasionally easier to 0wn than the normal way.

For example, look at the code that Microsoft suggests for users of  
the SQL Server Reporting Services add-on:

http://support.microsoft.com/?kbid=842419

They recommend giving any SQL-calling code  
PermissionState.Unrestricted access to the SQL server. Guess what?  
The permission flood gates are now opened, and SQL injections are all  
back if there's dynamically constructed queries in the code.

Plus, those instructions are so long winded, if that's what is  
required for every assembly which asserts CAS permissions, there is  
the reason it's not done. Developers are under the pump, and unless  
it's easy, trivial and automatic, it will not be done.

Sandboxing and partial trust is a defense in depth mechanism that  
solves a small subset of issues and has the potential to reduce  
damage from other types of attack as long as keys to the kingdom are  
not granted by the asserted permissions.

It would be nice if it was on by default and programmers used it, but  
I'm not losing sleep over it. If I come across code which needs help  
with cross-site scripting or injections or worse, a process which is  
easy to conduct fraud with, I will fix that before telling them to  
turn the verifier on or insert code to demand permissions from the  
underlying CLR or VM.

thanks,
Andrew


On 24/05/2006, at 8:34 AM, Dinis Cruz wrote:

> (sorry for the long time that it took for this response, see  
> comments inline)
>
> Stephen de Vries wrote:
>> Hi Dinis,
>>
>> I think you're overestimating the effectiveness of a sandbox in  
>> preventing common web app vulnerabilities, and you're instead  
>> focussing on the tiny fraction of specific attacks that can be  
>> stopped with sandboxes.
> Well Stephen, I would argue that you are underestimating that  
> effectiveness :)
>
> I also don't think that I am focusing on a tiny fraction of  
> specific attacks. Sandboxes have the capability to resolve most of  
> the current types of attacks we have today. And the ones that it is  
> not able solve, it will make them easy to detect.
>
> In fact, I would argue that Sandboxing could actually make the  
> 'Sandboxed Application' more simple, effective, cheaper to develop  
> and easier to audit.
>> The fundamental point of departure between our points of view is  
>> that I would argue that, the crown jewels are already inside the  
>> sandbox!
> I think that you are thinking of a unidimensional Sandbox model  
> similar to the one created by the Operating system between user- 
> land process and kernel, or the one implemented by .Net / Java for  
> mobile code executed on a web browser.
>
> In the solution that I am envisioning, you will have multiple  
> Sandboxes, one inside the other, separated by very clearly defined  
> layers (the input choke points / attack surface) where each sandbox  
> is allocated privileges accordingly to what it needs to get the job  
> done (principle of least privilege),  the amount of trust that we  
> have in that code (Code Access Security) and the identity used to  
> executed it (Role Based Security).
>
> Unfortunately the Partial Trust Sandboxes that currently exist on  
> the .Net Framework (namely Medium Trust) are not good examples of  
> Sandboxes since they still allow the creation of easy exploitable  
> Asp.Net code (i.e. the security vulnerabilities that you mention  
> below would still occur on a web application executed under Medium  
> Trust).
>> So spending time and effort to strengthen the walls isn't going to  
>> do any real good in preventing an attacker from getting hold of them.
> The plan is to put has many walls as possible between the attacker  
> and the assets.
>>> <snip>
>>>
>>> Also remember that more and more we will have to deal with malicious
>>> developers, or with malicious attackers that are able to inject
>>> malicious code into a website via:
>>>     - a library used by a developer
>>>     - a compromised developer account details (which tend to be  
>>> sent by
>>> email)
>>>     - a compromised developer computer (infected via Spyware) which
>>> allows the malicious attacker to control remotely that computer and
>>> (for example) Eclipse or Visual Studio in memory so that every
>>> time a piece of code its submitted (checked-in) , the malicious
>>> payloads are inserted.
>>
>> I don't follow your argument here.  You're saying that by running  
>> in a sandbox we would prevent a developer with malicious intent  
>> from executing evil code(?).  Granted that a sandbox may limit  
>> specific operations such as writing or reading from the OS or  
>> making network connections, but that doesn't mean you would  
>> prevent them from accessing all the private data in the database  
>> or from allowing one user to view another's data.
> Of course you can.
>
> I can create a .Net environment which prevents those developers  
> from accessing directly the database (in the case where malicious  
> code was uploaded to the server).
>
> CAS allows the creation of custom permissions which could be used  
> to implement 'Data-Sandboxed environments' which enforce  
> application-logic to the sandboxed code (for example not-allowing  
> access to private data stored within the database or other user's  
> data)
>> Sandboxing is not going to make any difference here, but external  
>> controls such as vetting your developers and auditing the code  
>> would make a very real contribution to improving the security.
> Although this is important, and will have to be done for certain  
> types of code (namely the ones we will place more trust (and will  
> pay more for)), this will not scale up (i.e. work for ALL software  
> that is executed in your computer).
>
> Just do this simple test: analyze your computer and list every  
> single application that you have installed (if you have time, try  
> also listing the writers of the individual components (dlls, static  
> libraries, etc...) used by those applications), once you have that  
> list of applications which will have access to ALL your user-land  
> assets (let's ignore for now the ones that also have (or had)  
> administrative privileges to your box), ask yourself  the question:  
> "Do I really trust every single developer that worked on this  
> applications/modules?".
>
> And even if somebody had vetted their developers and audited their  
> code, how would you know?
>
> Another thing that I like about the Sandboxed model is the fact  
> that it would also allow the pragmatic analysis of different  
> applications security (i.e. metrics)
>> If you add up the number of people that have the capability to put  
>> one
>>> line of malicious code on a web server, you will see that this is a
>>> very large number indeed.
>>
>> And that one line of malicious code can do a lot of damage _even  
>> in a sandboxed environment_.
>>
> That depends on the Sandboxed environment :)
>
> If that Sandboxed environment is properly enforced, then the amount  
> of damage created by this one line of could be controlled, limited  
> and (if anybody was looking) detected
>>> <snip>
>>> A couple more examples of ways malicious code can be uploaded to the
>>> server: SQL Injection,
> if the code 'injected' by an SQL Injection is executed in a  
> Sandboxed environment, then the damage potential for that SQL  
> Injection is very limited.
>>> XSS (payload deployed to the admin section),
> XSS (since being a client-side exploit) is one where the Sandbox  
> approach would be harder to implement (unless the affected user is  
> also using a Sandboxed browser where some types of exploits could  
> be prevented).
>
> To prevent XSS via a Sandbox, one approach would be to use the  
> Sandbox model to clearly define the 'input chokepoints' and force  
> (via CAS Demands) that data validation was performed on those  
> requests. This way, the developers would have no option but to  
> validate their data. Another option would be to encode all inputs  
> and outputs from the untrusted sandboxes (i.e. only the 'trusted'  
> sandboxes would have the ability to manipulate Html directly.
>>> authorization vulnerabilities which allow the editing of files on  
>>> the
>>> server (via for example the CMS (content management system)),
> This is the easier one of solve since the current CAS contains  
> ample support for File's (code and role based) security decisions
>>> manipulating params which control which method is executed (when
>>> Reflection is used to perform late binding on method calls based on
>>> the commands received)
> Again, using CAS (Code Access Security) you can control what code  
> can be executed by each layer of the Sandbox
>>> ,Social engineering, etc...
> If you do a Thread Model on a multi-layer Sandboxed application,  
> you will see that the 'attack surface' for social engineering will  
> be dramatically reduced (when compared with a similar non-Sandboxed  
> application).
>>>
>>> Sometimes you will even find CMS (Content Management Systems) that
>>> provide power users (or 'area x' admins) with powerful customization
>>> features which when exploited (or not, depending if this is a
>>> 'feature') allow the injection of code.
> Yes, but if these powerful customizations are executed inside a  
> Sandbox then its damage potential are dramatically reduced.
>
> Another good example is Cookie's Generation.
>
> Under normal circumstances, malicious .Aspx code could create a  
> 'Cookie Generator' for a Forms Authentication website which would  
> allow the impersonation of any user in a way which would make its  
> detection almost impossible.
>
> I could create a Sandboxed environment which would prevent that   
> 'Cookie Generator' from working.
>>> Do you really think that it is a good idea to have your entire data
>>> center security and CIA (Confidentiality, Integrity and  
>>> Availability)
>>> depended on such extraordinary set of circumstances?
>>>
>>> So the first main security benefit that we have with using Sandboxes
>>> is: Containment, Damage Limitation, and Risk Reduction (you went  
>>> from
>>> full data center compromise to a local and limited problem)
>>
>> This only applies to environment where the value (to an attacker)  
>> of compromising the data centre and web server is more than the  
>> value of compromising the application itself.  In the majority of  
>> web applications, the data stored by the app itself is the nazi  
>> gold - not the webserver or surrounding infrastructure.  So  
>> sandboxing the app will not add any protection to the stuff I care  
>> about most: my data.
> It will, the problem here is that we are looking at this issue from  
> different points of view. You are thinking that the sandbox will go  
> between the Operating System and the Application (where ALL assets  
> are), and I am thinking that the Sandbox(es) will be placed between  
> the Assets and the potential malicious code/activities.
>
> But your comment "... This only applies to environment where the  
> value (to an attacker) of compromising the data center and web  
> server is more that the value of compromising the application  
> itself..." is spot on!
>
> And in fact it shows how ineffective (from a security point of  
> view) is the current focus on Non-Administrator environments, since  
> they are only protecting the hardware and not the assets.
>>> <snip>
>>>
>>> So let's look at another application (App B) which has the same
>>> functionality but, is executed in three Sandboxes:
>>>
>>>  - Sandbox A) 450,000 lines of code executed in very restricted
>>> Sandbox (let's say Asp.Net Low Trust)
>>>
>>>   - Sandbox B) 48,000 lines of code executed in secure Sandbox  
>>> (let's
>>> say customized version of Asp.Net Medium Trust)
>>>
>>>   - Sandbox C) 2,000 lines of code executed in a Sandbox which  
>>> allows
>>> calls to unmanaged code.
>>>
>>> Given the same 1 week, you (as the security consultant auditing this
>>> application) will spend most of your time in Sandbox C) code,  
>>> less on
>>> Sandbox B) code and even less on Sandbox A) code. Why? because  
>>> only a
>>> vulnerability in Sandbox C) would allow the compromise of the entire
>>> App / Server / Datacenter.
>>
>> I disagree.  Any one of those 450,000 lines of perfectly sandboxed  
>> and verifiable code could contain an SQL injection attack that  
>> would compromise my entire database.
> That depends on the run-time environment of those 450,000 lines of  
> code.
>
> On a proper Sandboxed environment, those 450,000 of code would be  
> inside a Sandbox which would not allow direct database query  
> manipulation (which cause SQL Injection), direct HTML manipulation  
> (which cause XSS), Cookie Generation (which cause Session  
> Hijacking), direct access to admin interfaces (which could cause  
> Authorization issues), etc, etc, etc...
>
> The idea is to protect with a strong Sandbox (or series of  
> Sandboxes) the assets that those 450,000 of code can 'touch'
>>   They could also contain access control flaws that let  
>> unauthenticated users access private information.  Or allow an  
>> attacker to use an XSS flaw to steal a session cookie.  Running in  
>> a sandbox would not prevent _any_ of these serious security  
>> issues, all of which could compromise the security of my data.
> It could prevent those attacks if the the Sandbox was designed to  
> do so.
>
> Of course that somewhere, in one of those Sandboxes, there will be  
> code that will be able to access the database directly. But if we  
> are able to limit the amount of code that needs these privileges  
> (Sandboxes B and C in the example above), then the amount of code  
> that needs to be audited (and for example certified by a third  
> party security-audit-company) will be smaller and manageable.
>> To summarise, sandboxing an app is useful in preventing specific  
>> attacks such as executing OS commands, making unauthorized  
>> connections and accessing arbitrary system resources but it will  
>> not do anything to prevent the vast majority of serious security  
>> issues affecting web apps, because the valuable stuff is inside  
>> the sandbox.
> After my explanations in this email do you still think that this is  
> correct? Or can you accept now that it is possible to build a  
> Sandboxed environment that is able to protect against the majority  
> of the serious security issues that affect web apps today?
>
> If you do accept that it is possible to build such sandboxes, then  
> we need to move to the next interesting discussion, which is the 'HOW'
>
> Namely, HOW can an environment be created where the development and  
> deployment of such Sandboxes makes business sense.
>
> Dinis Cruz
> Owasp .Net Project
> wiki.owasp.net
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/ 
> listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/ 
> charter.php
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2234 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060525/751de65e/attachment.bin 

From rcs at cert.org  Thu May 25 07:57:40 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Thu, 25 May 2006 07:57:40 -0400
Subject: [SC-L] STL iterator vulnerabilities
Message-ID: <44759BB4.6070007@cert.org>


Does anyone have any experience of specific examples of vulnerabilities
resulting from the use of uninitialized or invalidated STL iterators or
other STL related vulnerabilities?  I'm doing some research for a new
project (which I hope to announce here shortly).

Thanks,
rCs



From gwc at acm.org  Thu May 25 22:08:01 2006
From: gwc at acm.org (George Capehart)
Date: Thu, 25 May 2006 22:08:01 -0400
Subject: [SC-L] Re: [WEB SECURITY] On sandboxes, and why you should care
In-Reply-To: <44738DD8.1070803@ddplus.net>
References: <442BA1C2.3080008@ddplus.net>
	<AEF0C4CD-70B7-4178-BAA5-58CC1BE5C938@corsaire.com>
	<44738DD8.1070803@ddplus.net>
Message-ID: <44766301.7060108@acm.org>

Dinis Cruz wrote:

<snip>

> After my explanations in this email do you still think that this is
> correct? Or can you accept now that it is possible to build a Sandboxed
> environment that is able to protect against the majority of the serious
> security issues that affect web apps today?
> 
> If you do accept that it is possible to build such sandboxes, then we
> need to move to the next interesting discussion, which is the 'HOW'
> 
> Namely, HOW can an environment be created where the development and
> deployment of such Sandboxes makes business sense.
> 

Hola Dinis,

The <snip>ped part of your message was one of the best, most concise
discussions of sandboxes and their potential I have ever seen.  It has
stimulated a lot of thinking on my part . . . sandboxes and their role
in systems architecture just haven't been on my radar screen.  It is
obvious that you have spent serious time and thought on the subject.
I'm thinking that I could count on my two hands the number of people who
have given sandboxing the amount of thought and effort you have.  If,
along the way, you have made any notes or captured your thoughts in any
way, it would be of great benefit to the community if you were to share
them with us.  I say this because I'm not a dumb guy, and, after
spending a /*lot*/ of time thinking about what you're saying, I can
begin to appreciate your approach.  There are many people (especially
pointy-haired managers) who are not going to sit up until midnight with
a glass of wine reading and rereading your comments until they kinda,
sorta, get an idea of your vision.  I think that it is important that
the community understand your framework and think about it when they're
coding.  If you were to write a "Sandboxes for Dummies," I would make it
required reading for all Java and .Net (and for that matter, all other)
programmers.

You're /*way*/ ahead of the crowd here.

My $0.02.

Best regards,

George Capehart


From jeff.williams at aspectsecurity.com  Fri May 26 08:53:47 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Fri, 26 May 2006 08:53:47 -0400
Subject: [SC-L] Re: [WEB SECURITY] On sandboxes, and why you should care
In-Reply-To: <44738DD8.1070803@ddplus.net>
Message-ID: <022b01c680c3$6e1250f0$a604a8c0@intranet.aspectsecurity.com>


Dinis Cruz wrote:
> If you do accept that it is possible to build such sandboxes, then we
> need to move to the next interesting discussion, which is the 'HOW'
> 
> Namely, HOW can an environment be created where the development and
> deployment of such Sandboxes makes business sense.

It's the "business sense" part of this that's really difficult.  It wouldn't
be *that* hard to put sandbox enforcement into all libraries.  If you want
to protect against XSS, put a validation and encoding sandbox into
HttpServletRequest.  If you want to stop SQL injection, get rid of
non-PreparedStatement and build in some control for direct references.  As
long as there are no unmanaged calls (and assuming type-safety, etc...) then
all calls can be mediated by a sandbox.

But the complexity of configuring the sandbox is the hard part.  You're
trying to move the security enforcement out of the code and into something
else. So you need a language that allows the developer to specify all those
rules.  And if the sandbox is powerful enough to only allow exactly what the
developer specifically wants to allow (positive security model), the
language will have to be just as complex as the code it's sandboxing. 

The Java sandbox is already too complex for most developers to use. I've
tangled with it several times and come away only partially accomplishing
what I wanted.  (And uncovering a massive flaw in one vendor's custom
sandbox implementation). 

This complexity is a general sandbox problem, not specific to Java or .NET
or anything else.  The most hopeless I've worked with is the Compartmented
Mode Workstation (CMW) label encodings and permissions scheme.  The web
application firewall products also have this problem.  Even .htaccess files
are generally a mess.  It's just a TON of work to move security rules out of
the code and into something else.  And developers don't want to learn some
new language to do it.

So while it might be possible to create sandboxes that are far more
powerful, the complexity goes through the roof.  And we can't even get
developers to use the relatively simple policy file for the Java sandbox.
If anything, I think we should focus on the big easy wins, like Microsoft
did by adding (some) XSS protection for .NET apps.  But the configuration
has to be really easy -- like ON/OFF.

--Jeff





From jeff.williams at aspectsecurity.com  Fri May 26 12:29:30 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Fri, 26 May 2006 12:29:30 -0400
Subject: [SC-L] Re: On sandboxes, and why you should care
In-Reply-To: <242a0a8f0605260753q515a91ffra872da95cd982cb1@mail.gmail.com>
Message-ID: <027f01c680e1$907e6fc0$a604a8c0@intranet.aspectsecurity.com>

I don't really see this as two approaches.  At one end of the spectrum, you
can do security inside your code. But there are many underlying "sandboxes"
that restrict what your code is able to do. Each of these may be
configurable to be 'semi-permeable' for your app.

My opinion is people should locate the security where it's most effective
and easiest to build, configure, maintain, and operate. For example, you
could enforce access to local files in your code, in the VM, or in the OS.
Where is best?  Depends on what you're doing and your environment.  The
important point is that everyone involved understands the approach and that
it's simple to verify.

I'm confused about how your "fix the tools" approach is any different from a
sandbox. Building APIs that prevent developers from making security mistakes
is just the same.

And there's another important use of sandboxes that I think you're ignoring.
When you have to run code that you didn't develop, the end-user can use the
sandbox to protect their underlying platform. It's a question of control.

--Jeff

> -----Original Message-----
> From: Brian Eaton [mailto:eaton.lists at gmail.com]
> Sent: Friday, May 26, 2006 10:54 AM
> To: jeff.williams at aspectsecurity.com
> Cc: Dinis Cruz; Stephen de Vries; Secure Coding Mailing List; owasp-
> dotnet at lists.sourceforge.net; websecurity at webappsec.org
> Subject: Re: [WEB SECURITY] RE: [SC-L] Re: [WEB SECURITY] On sandboxes,
> and why you should care
> 
> On 5/26/06, Jeff Williams <jeff.williams at aspectsecurity.com> wrote:
> >
> > Dinis Cruz wrote:
> > > If you do accept that it is possible to build such sandboxes, then we
> > > need to move to the next interesting discussion, which is the 'HOW'
> > >
> > > Namely, HOW can an environment be created where the development and
> > > deployment of such Sandboxes makes business sense.
> >
> > It's the "business sense" part of this that's really difficult.  It
wouldn't
> > be *that* hard to put sandbox enforcement into all libraries.  If you
want
> > to protect against XSS, put a validation and encoding sandbox into
> > HttpServletRequest.  If you want to stop SQL injection, get rid of
> > non-PreparedStatement and build in some control for direct references.
> 
> Two distinct approaches to fixing software are described here.
> 
> With one method, sandboxes, developers need to do a bunch of extra
> work to define sandbox policies for their applications.  Sandboxes
> don't have a great track record because it is too much work to do them
> properly.
> 
> With the other method, better tools and APIs, developers do less work
> and get better results.  The reason buffer overflows are relatively
> rare in web applications is because web applications aren't usually
> written in C.  They are written in high level languages that do bounds
> checking automatically.  XSS is endemic in web applications because
> the tool sets encourage people to generate HTML on the fly.  The
> evidence is clear: fix the tools and you'll end up with more secure
> apps.
> 
> Sandboxes are best understood as band-aids on buggy, broken
> applications.  Band-aids have a place, but avoiding the errors in the
> first place is more effective.
> 
> Regards,
> Brian



From stephen at corsaire.com  Fri May 26 01:43:33 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Fri, 26 May 2006 12:43:33 +0700
Subject: [SC-L] Re: [WEB SECURITY] On sandboxes, and why you should care
In-Reply-To: <44738DD8.1070803@ddplus.net>
References: <442BA1C2.3080008@ddplus.net>
	<AEF0C4CD-70B7-4178-BAA5-58CC1BE5C938@corsaire.com>
	<44738DD8.1070803@ddplus.net>
Message-ID: <0C0A4875-A705-4DA0-BDCD-A94660E7BC1C@corsaire.com>


Hi Dinis,

On 24 May 2006, at 05:34, Dinis Cruz wrote:
<snip>
>
> In the solution that I am envisioning, you will have multiple  
> Sandboxes, one inside the other, separated by very clearly defined  
> layers (the input choke points / attack surface) where each sandbox  
> is allocated privileges accordingly to what it needs to get the job  
> done (principle of least privilege),  the amount of trust that we  
> have in that code (Code Access Security) and the identity used to  
> executed it (Role Based Security).

If I understand this correctly, then this implies a _huge_  
architecture change for developers.  It's already a difficult task  
for developers to map a problem domain onto an Object Oriented  
language, what you're suggesting is to throw another constraint in  
the mix which may break a lot of the design.  A very simple MVC  
pattern for the web tier could become quite complex with multiple  
nested sandboxes.  This could mean that the sandboxing could become  
central to the design of the app.  Of course, this may be required in  
certain high risk high value environments, but the additional cost of  
implementing this for your average web app would be too high IMO.
>
> Unfortunately the Partial Trust Sandboxes that currently exist on  
> the .Net Framework (namely Medium Trust) are not good examples of  
> Sandboxes since they still allow the creation of easy exploitable  
> Asp.Net code (i.e. the security vulnerabilities that you mention  
> below would still occur on a web application executed under Medium  
> Trust).

I can't speak for .NET, but the Java security manager can be defined  
purely as a configuration item.  There doesn't need to be anything  
special in the code to take advantage of the security manager.  This  
means the sandbox doesn't intrude on the code at all, it merely sets  
runtime restrictions.

>> So spending time and effort to strengthen the walls isn't going to  
>> do any real good in preventing an attacker from getting hold of them.
> The plan is to put has many walls as possible between the attacker  
> and the assets.

This is a good analogy, and I agree with you that sandboxes will  
limit the kind of attacks that move from one layer to the next.  But  
they won't be able to stop attacks that don't traverse the walls,  
such as SQL injection and XSS.
>
> I can create a .Net environment which prevents those developers  
> from accessing directly the database (in the case where malicious  
> code was uploaded to the server).
>
> CAS allows the creation of custom permissions which could be used  
> to implement 'Data-Sandboxed environments' which enforce  
> application-logic to the sandboxed code (for example not-allowing  
> access to private data stored within the database or other user's  
> data)

Not allowing access to certain database tables, fine.  And preventing  
access to stored procedures, also fine.  But what about the tables  
that _have_ to be accessed as part of the requirements?  Example:  
SELECT * FROM USERS WHERE USERID=10
How would a sandbox prevent a simple parameter manipulation attack to  
gain access to someone elses data?  So even though you may prevent  
attackers from running xp_cmdshell or reading system tables, you  
can't prevent them from accessing the USERS table.

>> Sandboxing is not going to make any difference here, but external  
>> controls such as vetting your developers and auditing the code  
>> would make a very real contribution to improving the security.
> Although this is important, and will have to be done for certain  
> types of code (namely the ones we will place more trust (and will  
> pay more for)), this will not scale up (i.e. work for ALL software  
> that is executed in your computer).
>
> Just do this simple test: analyze your computer and list every  
> single application that you have installed (if you have time, try  
> also listing the writers of the individual components (dlls, static  
> libraries, etc...) used by those applications), once you have that  
> list of applications which will have access to ALL your user-land  
> assets (let's ignore for now the ones that also have (or had)  
> administrative privileges to your box), ask yourself  the question:  
> "Do I really trust every single developer that worked on this  
> applications/modules?".

It's a matter of degree of trust.  I store all my sensitive data in a  
Mac OS X keychain, and I trust that that data isn't worth someone  
subverting a developer at Apple (and his colleagues who would have  
spotted the malicious code) and the QA team and the code auditors  
etc.  BUT I would _not_ trust this process if I stored nuclear launch  
codes in the app!
>
>>> A couple more examples of ways malicious code can be uploaded to the
>>> server: SQL Injection,
> if the code 'injected' by an SQL Injection is executed in a  
> Sandboxed environment, then the damage potential for that SQL  
> Injection is very limited.

Limited yes, mitigated no.  See my example above.

>>> XSS (payload deployed to the admin section),
> XSS (since being a client-side exploit) is one where the Sandbox  
> approach would be harder to implement (unless the affected user is  
> also using a Sandboxed browser where some types of exploits could  
> be prevented).
>
> To prevent XSS via a Sandbox, one approach would be to use the  
> Sandbox model to clearly define the 'input chokepoints' and force  
> (via CAS Demands) that data validation was performed on those  
> requests. This way, the developers would have no option but to  
> validate their data. Another option would be to encode all inputs  
> and outputs from the untrusted sandboxes (i.e. only the 'trusted'  
> sandboxes would have the ability to manipulate Html directly.

Again, this makes the sandboxes central to the application design.   
And for applications where security is a primary driver this is  
appropriate.  But this is not the case for the vast majority of apps.
>
> Of course that somewhere, in one of those Sandboxes, there will be  
> code that will be able to access the database directly. But if we  
> are able to limit the amount of code that needs these privileges  
> (Sandboxes B and C in the example above), then the amount of code  
> that needs to be audited (and for example certified by a third  
> party security-audit-company) will be smaller and manageable.

Good point, and definitely a benefit of using sandboxes.

>> To summarise, sandboxing an app is useful in preventing specific  
>> attacks such as executing OS commands, making unauthorized  
>> connections and accessing arbitrary system resources but it will  
>> not do anything to prevent the vast majority of serious security  
>> issues affecting web apps, because the valuable stuff is inside  
>> the sandbox.
> After my explanations in this email do you still think that this is  
> correct? Or can you accept now that it is possible to build a  
> Sandboxed environment that is able to protect against the majority  
> of the serious security issues that affect web apps today?

I still don't see sandboxes addressing all the issues as explained  
above. Another important disadvantage is the cost and impact of  
implementing sandboxes in the first place.  Creating multiple layered  
sandboxes in the code is much more of an obstacle to their  
implementation than simply defining constraints at runtime through a  
configuration change, because it would make security _the central_  
design constraint of the application (it may also break OO  
patterns).  And while this is fine for some high risk apps, this is  
not the case for the majority of organisations who have other  
functional concerns as the reasons they built the app.
Consider the JVM that provides a full sandbox model that's reasonable  
easy to implement for almost any Java app, and then consider the 1%  
(using your metrics) of java applications that enable this  
sandboxing.  If a simple configuration change is too much for  
projects to manage, how much less so an entire new sandbox  
development framework!
Saying that, I don't want to cast too much negativity on the idea -  
it's a good idea, but for niche markets.

>
> If you do accept that it is possible to build such sandboxes, then  
> we need to move to the next interesting discussion, which is the 'HOW'

The 'How' would also give us an idea of how difficult it would be to  
implement these sandboxes and shed some light on exactly which  
security issues they would prevent and which they would not.

regards,

-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com





From James.McGovern at thehartford.com  Fri Jun  2 10:38:11 2006
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Fri, 2 Jun 2006 10:38:11 -0400
Subject: [SC-L] Hiring folks that are familar with SC practices
Message-ID: <3D427B563FFFC947A412CDF5FDE991B201D817EE@AD1HFDEXC308.ad1.prod>

Figured I would ask the list a question that I haven't figured out the answer to. How have other enterprises that seek architects and developers knowleedgable in secure coding software development practices articulated it to their internal HR recruiting arm? We have been seeking candidates with this background but haven't ran across much on our side of town.

James McGovern
Chief Security Architect
The Hartford
email: james.mcgovern at thehartford.com



*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060602/15b4fcb6/attachment.html 

From ljknews at mac.com  Sun Jun  4 11:29:39 2006
From: ljknews at mac.com (ljknews)
Date: Sun, 4 Jun 2006 11:29:39 -0400
Subject: [SC-L] Hiring folks that are familar with SC practices
In-Reply-To: <3D427B563FFFC947A412CDF5FDE991B201D817EE@AD1HFDEXC308.ad1.prod>
References: <3D427B563FFFC947A412CDF5FDE991B201D817EE@AD1HFDEXC308.ad1.prod>
Message-ID: <p05200f11c0a8ac9a461a@[192.168.1.254]>

At 10:38 AM -0400 6/2/06, McGovern, James F (HTSC, IT) wrote:

> Figured I would ask the list a question that I haven't figured out the
>answer to. How have other enterprises that seek architects and developers
>knowleedgable in secure coding software development practices articulated
>it to their internal HR recruiting arm? We have been seeking candidates
>with this background but haven't ran across much on our side of town.

Are you bringing something to the table to attract such people ?

Or have you preconstrained the programming languages and techniques
to be used ?
-- 
Larry Kilgallen


From gunnar at arctecgroup.net  Sun Jun  4 18:24:01 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Sun, 04 Jun 2006 17:24:01 -0500
Subject: [SC-L] Hiring folks that are familar with SC practices
In-Reply-To: <p05200f11c0a8ac9a461a@[192.168.1.254]>
Message-ID: <C0A8C7B1.7F3%gunnar@arctecgroup.net>

One of my colleagues referred to the current hiring situation for app sec
folks as being analogous to looking for Apache webmasters in 1994.

In his movie "He Got Game", Spike Lee cast NBA player Ray Allen in the lead
role because he said that it was easier to teach basketball players to act
than to teach actors to be realistic in basketball scenes.

In my experience, I have seen companies generally have more success training
architects and developers in security rather than teaching security people
(e.g. Network security and auditors) about software and development. Partly,
developers have more street cred with the end audience/consumer which is
developers. Software security is really a set of software design patterns so
the development background helps to know when and where to apply the
security mechanisms - is this a design thing, a process thing, a component
thing, and how do I engineer it, etc... Whatever the person's background the
effort level and interest is the key to success, cf. Robert Deniro in Raging
Bull.

-gp

On 6/4/06 10:29 AM, "ljknews" <ljknews at mac.com> wrote:

> At 10:38 AM -0400 6/2/06, McGovern, James F (HTSC, IT) wrote:
> 
>> Figured I would ask the list a question that I haven't figured out the
>> answer to. How have other enterprises that seek architects and developers
>> knowleedgable in secure coding software development practices articulated
>> it to their internal HR recruiting arm? We have been seeking candidates
>> with this background but haven't ran across much on our side of town.
> 
> Are you bringing something to the table to attract such people ?
> 
> Or have you preconstrained the programming languages and techniques
> to be used ?




From gwc at acm.org  Mon Jun  5 00:15:27 2006
From: gwc at acm.org (George Capehart)
Date: Mon, 05 Jun 2006 00:15:27 -0400
Subject: [SC-L] Hiring folks that are familar with SC practices
In-Reply-To: <3D427B563FFFC947A412CDF5FDE991B201D817EE@AD1HFDEXC308.ad1.prod>
References: <3D427B563FFFC947A412CDF5FDE991B201D817EE@AD1HFDEXC308.ad1.prod>
Message-ID: <4483AFDF.6000400@acm.org>

McGovern, James F (HTSC, IT) wrote:
> Figured I would ask the list a question that I haven't figured out the answer to. How have other enterprises that seek architects and developers knowleedgable in secure coding software development practices articulated it to their internal HR recruiting arm? We have been seeking candidates with this background but haven't ran across much on our side of town.
> 

James,

Believe me when I say this . . . I'm not trying to be a wiseass, but it
takes one to know one.  My experience with recruiters and HR types is
that the ones who are best able to identify suitable candidates are
those who once were themselves.  There are a blue million "Monster.com
droids" who can download a bazillion resumes and grep for a particular
word or phrase.  Those folks are less than worthless.  A good recruiter
or HR person has spent some time in the discipline for which they are
recruiting.  I have had the pleasure of working with them.  They are
knowledgable of the subject matter and the players in the discipline.
They can tell after one phone call whether a candidate is a good fit or
not.  But the interviewer /*must*/ have had some experience in the
discipline.  Otherwise they are clueless.  They have no basis on which
to make discriminations and can't tell from reading a resume whether the
candidate is a good fit or not.

Now, I'm going to put the shoe on the other foot and say that the
individual who is searching for talent must know enough about the skills
the candidate needs in order to clearly articulate them to the
recruiter.  If the individual who is trying to fill a job really doesn't
know what skills and background the candidate needs to have, it's going
to be the luck of the draw if a hiree does actually fill the bill.  So,
in the end, the person who is doing the hiring must be knowledgeable and
able to articulate precise requirements and the HR person/recruiter must
have enough of a background in the discipline for which s/he is
recruiting that s/he can actually read a resume and conduct a phone
interview with a candidate and know whether the candidate fits the
requirements.  Having some drone in HR grep through a bunch of resumes
for two or three key words is /*not*/ the way to winnow candidates.

FWIW,

/g



From dwheeler at ida.org  Mon Jun  5 11:27:40 2006
From: dwheeler at ida.org (David A. Wheeler)
Date: Mon, 05 Jun 2006 11:27:40 -0400
Subject: [SC-L] Where are developers who know how to develop secure software?
References: <200606041600.k54G03GR041821@ratsass.krvw.com>
Message-ID: <44844D6C.6050603@ida.org>

James McGovern asked:

> Figured I would ask the list a question that I haven't figured out the
 > answer to. How have other enterprises that seek architects
 > and developers knowleedgable in secure coding software development
 > practices articulated it to their internal HR recruiting arm?
 > We have been seeking candidates with this background but haven't
 > ran across much on our side of town.

It's not quite the answer you were looking for, but you may find
it necessary to get otherwise knowledgeable people and train them.
I'm saying this is ideal - it is not.  But so few people have this
knowledge that it is often necessary.

One reason is that people can get degrees in
Computer Security or Software Engineering without knowing how to
develop software that receives hostile data.  Even the
"Software Engineering Body of Knowledge" essentially
omits security issues (a supplement is being developed,
thankfully, though it's not REQUIRED).  Since most
programs is connected to the Internet or receives data
from strangers sent over it, this means that most are unqualified
to develop today's software (!).   Most software developers
don't have those degrees, last I checked, but that only makes
the lack of knowledge worse.  I think this is bordering on
criminal.  There are some good partial steps; I know that
George Mason University has an optional Master's level course
on secure programming, for example, but the basics of this information
should be MANDATORY at the UNDERGRAD level.

If you have connections with your local university, try to talk
them into increasing the amount of education they provide in
developing secure software (where software development is done).
I give away a book on this topic, as part of my effort to get the
information disseminated.

I've seriously talked with a U.S. Senatorial staffer about
the possibility of MANDATING the teaching of secure
progrmaming technniques in universities
that receive federal funding (for programming-related degrees).
I'd HATE to go down that road; universities and acceditation bodies
should normally be free to make such determinations.
But I think nobody in power wants to see people die because
cyberattacks were too darn easy.  Hopefully the
universities will see the light before this has to get forced.
Civil engineers don't graduate until they understand the
basics of bridge-building, including how to compute and handle
loads.  Software developers shouldn't graduate until they
are able to identify and handle security attacks in software,
at least the basics.

--- David A. Wheeler





From neumann at csl.sri.com  Mon Jun  5 12:50:27 2006
From: neumann at csl.sri.com (Peter G. Neumann)
Date: Mon, 5 Jun 2006 9:50:27 PDT
Subject: [SC-L] Hiring folks that are familar with SC practices
In-Reply-To: Your message of Mon, 05 Jun 2006 00:15:27 -0400
Message-ID: <CMM.0.90.4.1149526227.neumann@chiron.csl.sri.com>

Nice discussion.
It arose years ago when software development managers typically had
NO experience in software development, but were thought to be good
managers.  Many disasters ensued.  The other side of the coin is that
good developers are often TERRIBLE managers.  I once wrote 
  Psychosocial Implications of Computer Software Development and Use:
  Zen and the Art of Computing
    in Theory and Practice of Software Technolgoy
    D. Ferrari, M. Bolognani, and J. Goguen (editors),
    North-Holland, 1983, pages 221-232.
An earlier version appeared in Software Engineering Notes, and Will
Tracz may even have that online by now.

The bottom line is that you need people with well developed and 
coordinated LEFT- and RIGHT-brained abilities innately.  Interviewing
someone to be a system-oriented developer is very difficult unless
the interviewer has deep knowledge of system-oriented development.

Read my DARPA CHATS report on Principled Assuredly Trustworthy
Composable Architectures.  Your interviewers should have read and
understood the essence of that report before being trusted to select
good applicants.
  http://www.csl.sri.com/neumann/chats4.html or pdf or ps

Good luck!  P


From gem at cigital.com  Mon Jun  5 16:34:19 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 5 Jun 2006 16:34:19 -0400
Subject: [SC-L] SD Times
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BEEE6@va-mail.cigital.com>

Hi all,

I wrote an article for the SD Times about the state of the practice in
software security.  It was published Friday, just in time for the
"Software Security Summit East" in Baltimore that starts tomorrow.  You
might ponder where your organization fits in the maturity levels
mentioned at the end of the article: lone wolf, fire department, SDLC
touchpoint integration.

http://www.sdtimes.com/article/column-20060601-01.html

Comments and feedback always welcome.

gem
www.cigital.com
www.swsec.com


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From neumann at csl.sri.com  Mon Jun  5 12:55:10 2006
From: neumann at csl.sri.com (Peter G. Neumann)
Date: Mon, 5 Jun 2006 9:55:10 PDT
Subject: [SC-L] Where are developers who know how to develop secure
	software?
In-Reply-To: Your message of Mon, 05 Jun 2006 11:27:40 -0400
Message-ID: <CMM.0.90.4.1149526510.neumann@chiron.csl.sri.com>

I'll echo that from David.

Most of you by now must have heard my experience interviewing
a PhD from one of the supposedly TOP U.S. CS departments (albeit
perhaps 12 years ago, before the department made a radical step
forward).

PGN:  What does software engineering mean to you?

ANS:  [after long headscratching pause:]
      Oh, that's putting comments in the code, isn't it?



From James.McGovern at thehartford.com  Mon Jun  5 14:20:33 2006
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 5 Jun 2006 14:20:33 -0400
Subject: [SC-L] Secure Application Protocol Design
Message-ID: <3D427B563FFFC947A412CDF5FDE991B201D81823@AD1HFDEXC308.ad1.prod>

Would love to see Gary address a couple of behaviors I have seen in my travel amongst architect types in corporate America especially the practice of secure application protocol design that isn't so secure. Is anyone writing/blogging deeply on this aspect?

Likewise, there are many folks in corporate America that have not yet acknowledged that they shouldn't be playing part-time cryptographer and don't have the competency to design cryptographic primitives such as hash functions and algorithms to protect data. Does anyone know of any "friendly" articles that speak to this problem space?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************




From James.McGovern at thehartford.com  Mon Jun  5 16:50:17 2006
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Mon, 5 Jun 2006 16:50:17 -0400
Subject: [SC-L] Comparing Scanning Tools
Message-ID: <3D427B563FFFC947A412CDF5FDE991B201D8182C@AD1HFDEXC308.ad1.prod>

The industry analyst take on tools tends to be slightly different than software practitioners at times. Curious if anyone has looked at Fortify and has formed any positive / negative / neutral opinions on this tool and others...


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************




From gunnar at arctecgroup.net  Tue Jun  6 10:12:28 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue, 06 Jun 2006 09:12:28 -0500
Subject: [SC-L] Secure Application Protocol Design
In-Reply-To: <3D427B563FFFC947A412CDF5FDE991B201D81823@AD1HFDEXC308.ad1.prod>
Message-ID: <C0AAF77C.8C1%gunnar@arctecgroup.net>

"There is a well understood best practice in software development that
developers should not attempt to write their own cryptographic algorithms
because of the complexity, lack of peer review, and value of that which the
cryptographic functions are protecting. Developers, in contrast, routinely
write one-off identity solutions that are never peer reviewed by a wider
audience. This identity information is propagated and integrated throughout
software systems and used as a basis for making security decisions about
access control to critical resources and the confidentiality of personal and
business data."
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/assemb
ly/207.html?branch=1&language=1

Even if the crypto is implemented correctly, there are usually problems in
the identity implementation which is the basis for access control decisions,
anyhow. So developers should not write that either.

-gp


On 6/5/06 1:20 PM, "McGovern, James F (HTSC, IT)"
<James.McGovern at thehartford.com> wrote:

> Would love to see Gary address a couple of behaviors I have seen in my travel
> amongst architect types in corporate America especially the practice of secure
> application protocol design that isn't so secure. Is anyone writing/blogging
> deeply on this aspect?
> 
> Likewise, there are many folks in corporate America that have not yet
> acknowledged that they shouldn't be playing part-time cryptographer and don't
> have the competency to design cryptographic primitives such as hash functions
> and algorithms to protect data. Does anyone know of any "friendly" articles
> that speak to this problem space?
> 
> 
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php




From joe at joeteff.com  Tue Jun  6 19:15:41 2006
From: joe at joeteff.com (Joe Teff)
Date: Tue, 06 Jun 2006 18:15:41 -0500
Subject: [SC-L] Comparing Scanning Tools
In-Reply-To: <3D427B563FFFC947A412CDF5FDE991B201D8182C@AD1HFDEXC308.ad1.prod>
References: <3D427B563FFFC947A412CDF5FDE991B201D8182C@AD1HFDEXC308.ad1.prod>
Message-ID: <WorldClient-F200606061815.AA15410070@joeteff.com>

Fortify is a company with several products. Which product are you 
referring to? I've used some of thier products (and think highly of 
them), but I have not used all of them. What I like most about thier 
approach is they are trying to address all parts of the life cycle. The 
IDE plug-in enforces secure development at the point that code is 
written/changed. The scanner/workbench supports the build and audit 
processes. Other components work at runtime. Are they perfect? Honestly, 
I've not seen anything that is ever perfect. Are they good and getting 
better? I belive so.

jt
-----Original Message-----
From: "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com>
To: <sc-l at securecoding.org>
Date: Mon, 5 Jun 2006 16:50:17 -0400
Subject: [SC-L] Comparing Scanning Tools

> The industry analyst take on tools tends to be slightly different than
> software practitioners at times. Curious if anyone has looked at
> Fortify and has formed any positive / negative / neutral opinions on
> this tool and others...
> 
> 
> ***********************************************************************
> **
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the
> intended
> recipient, any use, copying, disclosure, dissemination or distribution
> is
> strictly prohibited.  If you are not the intended recipient, please
> notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> ***********************************************************************
> **
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at -
> http://www.securecoding.org/list/charter.php



From stephen at corsaire.com  Wed Jun  7 10:38:50 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Wed, 7 Jun 2006 15:38:50 +0100
Subject: [SC-L] Reusable Security for Segmented Data Domains
Message-ID: <18041661-E333-4E5C-B6F4-87AD5919C9F2@corsaire.com>


Article which may be of interest to the J2EE crowd:
http://www.growingbusinesssolutions.com/Reusable-Security-for- 
Segmented-Data-Domains.pdf

"According to John C. Dale, MS MIS, president of Growing Business  
Solutions, for firms providing software development outsourcing  
services, the practice of software reuse can reduce overhead and  
increase margins.
Currently, an alarming number of enterprise software development  
projects are over budget, delivered late, or both. As software  
development organizations mature, so too should their ability to  
deliver increasingly complex software solutions on time and on  
budget. One strategy for achieving this is to identify opportunities  
for software reuse. In traditional manufacturing nomenclature, this  
process would be expressed as "manufacturing efficiency" or "economy  
of scale."

In this article, Dale discusses one way in which open source J2EE  
Security Realms can be used to facilitate code reuse - and thus  
manufacturing efficiency - into the enterprise software manufacturing  
process.

Subsequently, enterprise software development firms who employ this  
methodology should expect to deliver software with greater efficiency  
and predictability at a lower cost."



-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com





From leichter_jerrold at emc.com  Wed Jun  7 15:33:27 2006
From: leichter_jerrold at emc.com (leichter_jerrold at emc.com)
Date: Wed, 7 Jun 2006 15:33:27 -0400 
Subject: [SC-L] Where are developers who know how to develop secure so
	ftware?
Message-ID: <Pine.SOL.4.61.0606071513540.5029@mental>

On Mon, 5 Jun 2006, David A. Wheeler wrote:
| ... One reason is that people can get degrees in
| Computer Security or Software Engineering without knowing how to
| develop software that receives hostile data.  Even the
| "Software Engineering Body of Knowledge" essentially
| omits security issues (a supplement is being developed,
| thankfully, though it's not REQUIRED)....
| 
| If you have connections with your local university, try to talk
| them into increasing the amount of education they provide in
| developing secure software (where software development is done).
| I give away a book on this topic, as part of my effort to get the
| information disseminated....
Keep in mind that you can run into a fundamental conflict about what
a university education is supposed to be about.

At least where computer science departments are part of the liberal
arts school, their fundamental view is that they are there to teach
concepts, not to train people for work.  The view is that, if you want
someone who knows the basics of today's technologies, hire a graduate
of a vocational school.  Universities produce people who know how to
think about technology and can learn the details of any particular
technology when they need to.  University programming assignments
focus on the ideas, not on the "trivial minutia" of validating input,
for example.  A university cryptography course will likely be heavy
on theory, light on how to safely apply cryptographic primitives.  Any
"secure computing" courses at universities are likely to focus on what
someone identifies as broad principles, not on how to avoid buffer
overflows in C - much less on how to restructure existing horrible
C code so that you can eliminate its buffer overflows.  (When I ask
the typical university-trained CS major "How do you recognize that a
class has been designed well?" about the only answer I am likely to
get is that the member fields are all private and accessed through
getters and setters.  Sigh.)

I don't want to get into a debate about the validity of this approach,
but recognize that it's there and it's not going away.  I would also
be very careful about any sentence that starts "you can get a degree
without knowing X", because you'll be astounded to learn just what
you can substitute for X.  For example, very few CS graduates have
any understanding of even the most fundamental facts about floating
point arithmetic.  (Ask them how many times a loop that starts an FP
value at 0.0 and adds 0.1 to it until the result equal 1.0 will execute.)

When I interview new college graduates, on almost all subjects, I assume
that, if they got a good college education, they understand basic
principles and will be able to use them to learn specifics.  But on the
real practice of software development, what they haven't learned through
co-op programs or other work experience, I'll have to train them on.
(It's also my view that design, architecture, non-trivial secure coding,
and so on cannot be taught in the way that sciences are taught, by
someone lecturing from the front of the room.  They need to be taught as
art or writing is taught - by example and by practice and critique.
This is something university CS departments are rarely set up to do.)

							-- Jerry


From leichter_jerrold at emc.com  Wed Jun  7 16:34:17 2006
From: leichter_jerrold at emc.com (leichter_jerrold at emc.com)
Date: Wed, 7 Jun 2006 16:34:17 -0400 
Subject: [SC-L] Comparing Scanning Tools
Message-ID: <Pine.SOL.4.61.0606071608350.5029@mental>

| Date: Mon, 5 Jun 2006 16:50:17 -0400
| From: "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com>
| To: sc-l at securecoding.org
| Subject: [SC-L] Comparing Scanning Tools
| 
| The industry analyst take on tools tends to be slightly different than
| software practitioners at times. Curious if anyone has looked at Fortify
and
| has formed any positive / negative / neutral opinions on this tool and
| others...
We evaluated a couple of static code scanning tools internally.  The
following is an extract from an analysis I did.  I've deliberately
omitted comparisons - you want to know about Fortify, not how it
compares to other products (which raises a whole bunch of other
issues), and included the text below.  Standard disclaimers:  This
is not EMC's position, it's my personal take.

Caveats:  This analysis is based on a 3-hour vendor presentation.  The
presenter may have made mistakes, and I certainly don't claim that my
recall of what he said is error-free.  A later discussion with others
familiar with Fortify indicated that the experience we had is typical,
but is not necessarily the right way to evaluate the tool.  Effective
use of Fortify requires building a set of rules appropriate to a
particular environment, method of working, constraints, etc., etc. 
This takes significant time (6 months to a year) and effort, but
it was claimed that once you've put in the effort, Fortify is a
very good security scanner.  I am not in a position to evaluate that
claim myself.

BTW, one thing not called out below is that Fortify can be quite slow.
Our experience in testing was that a Fortify scan took about twice as
long as a C++ compile/link cycle, unless you add "data flow" analysis -
in which case the time is much, much larger.

The brief summary:  In my personal view, Fortify is a worthwhile tool,
but it would not be my first choice.  (Given the opportunity to choose
two tools, it would probably be my second.)  Others involved in the
evaluation reached the opposite conclusion, and rated Fortify first.

							-- Jerry

Fortify

Fortify is aimed as a tool for use in a security audit.  It is
deliberately biased in the direction of flagging all potential
security issues.  It provides two kinds of analysis - what they call
"semantic" and "data flow".  Neither use of terminology is consistent
with industry practice.  Their "semantic" analysis is better described
as a "syntactic" analysis:  It looks at surface features of the
program (use of certain calls, for example).  It mainly ignores
context.  Fortify's own representative describe this analysis as a
"super grep".  This analysis is driven by a large database of rules,
which can be extended.  (In industry practice, a semantic analysis
would look deeply at the meaning of the program.)

"Data flow" analysis is better called "taint analysis".  It traces all
data from external sources to find code that might incorrectly rely on
it.

When run on our code, semantic analysis reports about 3000 problems.
We looked closely at quite a number of them, and with a single
exception (where the code was so complex that no one could be sure),
they were false positives.  For a security audit, that's probably OK.
The problem is: What does one do with the false positives?  If this is
an isolated audit, the answer is - ignore them.  But in practice code
is always changing, so you'll have to audit it again.  How do you
avoid dealing with the same false positives every time?

A look at the problems showed that in many if not most of the cases we
looked at, there was no practical way to change the code to stop the
complaints.  You can permanently suppress individual complaints, but
doing so appears to be very hazardous:  The suppression is based on
the line on which the problem was found.  It could well be that this
is a false positive because of the surrounding context - and that
context might change.  For example, if a line has an array reference
a[i] that is safe because we can prove based on a test 10 lines
earlier that i is in range - something that Fortify itself cannot do,
since it does no value flow analysis - then we might suppress the
warning.  But a later revision to the code could eliminate the test,
and we apparently would not receive a warning.

The "data flow" analysis gives more useful results.  While the vendor
was here, we only had data flow analysis for a very small subset of
the code:  Producing this is an extremely long process (days of CPU
time).  Again, there were many false positives, though I would
consider almost all of them to be "legitimate", in the sense that the
program could not possibly have known certain things about our
environment that would be needed to eliminate the warning.  However,
in some cases, the messages were hard to understand:  There was
insufficient information in the result to figure out just why the
program had reached the conclusion it had.  Based on what the vendor
told us, effective use of the "data flow" analysis requires writing
rules that tell the product when "tainted" data becomes "cleansed".
This is a questionable procedure:  I recall a time I spent weeks
tracking down a bug that overwrote memory because of incorrect SNMP
data.  The bug was triggered way after the point any reasonable
security analyst would have considered the data "cleansed".  (The
issue was not with the data as such, but with its interaction with
deep, incorrect assumptions about its semantics.)

We found two bugs in the Fortify code's understanding of C++
constructs.  These lead to false positives that it would be impossible
to suppress except on a line-by-line basis.  The vendor didn't seem
particularly aggressive about noting these for fixing.  (He may have
noted it down or may just have a good memory.)  In general, I get the
feeling that Fortify is much more comfortable with C than with C++.
For example: Suppose a class has some public member functions, each of
which validate their arguments; and some private member functions,
which assume that they are passed valid data (e.g., that indexes are
in bounds).  Suppose that the public functions do actually ensure
valid data.  Fortify will complain that the private functions *might*
be security risks.  The only way around this - and it might not be
enough to shut Fortify up - is to add validation in all the private
functions as well.  This is not a style of programming that really
makes much sense.  The alternative of suppressing the warnings is
dangerous because someone could add a public function that does *not*
check its inputs correctly.

Summary

Fortify and XXX, despite being in what is nominally the same
market, are very different products.  Fortify has broader (but
shallower) coverage of known security problems.  Its tainted data
analysis could be very helpful in programs that take data from users
on the net and deal with it in fairly simple ways.  (For example, if
the only possible datatypes are things like strings and integers, with
the complexity all held elsewhere, you are probably OK marking the
function that converts to integer, or that copies the string to an
internal form, as "cleansers".)  It could be a useful "code auditors
workbench".  But as currently implemented, I don't see it as suitable
for maintaining correctness as code changes.


From James.McGovern at thehartford.com  Wed Jun  7 17:08:26 2006
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Wed, 7 Jun 2006 17:08:26 -0400
Subject: [SC-L] Comparing Scanning Tools
Message-ID: <3D427B563FFFC947A412CDF5FDE991B201D8184B@AD1HFDEXC308.ad1.prod>

Thanks for the response. One of the things that I have been struggling to understand is not the importance of using such a tool as I believe they provide value but more of the fact that these tools may not be financial sustainable.

Many large enterprises nowadays outsource development to third parties. Likewise, the mindset in terms of budgeting tends to eschew "per developer seat" tool purchases. Nowadays, it is rare to find an enterprise not using free tools such as Eclipse and not paying for IDEs

I have yet to find a large enterprise that has made a significant investment in such tools. I wonder if budgets and the tools themselves are really causing more harm than helping in that enterprises will now think about trading off such tools vs the expense they cost.

-----Original Message-----
From: leichter_jerrold at emc.com [mailto:leichter_jerrold at emc.com]
Sent: Wednesday, June 07, 2006 4:34 PM
To: McGovern, James F (HTSC, IT)
Cc: sc-l at securecoding.org
Subject: Re: [SC-L] Comparing Scanning Tools


| Date: Mon, 5 Jun 2006 16:50:17 -0400
| From: "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com>
| To: sc-l at securecoding.org
| Subject: [SC-L] Comparing Scanning Tools
| 
| The industry analyst take on tools tends to be slightly different than
| software practitioners at times. Curious if anyone has looked at Fortify
and
| has formed any positive / negative / neutral opinions on this tool and
| others...
We evaluated a couple of static code scanning tools internally.  The
following is an extract from an analysis I did.  I've deliberately
omitted comparisons - you want to know about Fortify, not how it
compares to other products (which raises a whole bunch of other
issues), and included the text below.  Standard disclaimers:  This
is not EMC's position, it's my personal take.

Caveats:  This analysis is based on a 3-hour vendor presentation.  The
presenter may have made mistakes, and I certainly don't claim that my
recall of what he said is error-free.  A later discussion with others
familiar with Fortify indicated that the experience we had is typical,
but is not necessarily the right way to evaluate the tool.  Effective
use of Fortify requires building a set of rules appropriate to a
particular environment, method of working, constraints, etc., etc. 
This takes significant time (6 months to a year) and effort, but
it was claimed that once you've put in the effort, Fortify is a
very good security scanner.  I am not in a position to evaluate that
claim myself.

BTW, one thing not called out below is that Fortify can be quite slow.
Our experience in testing was that a Fortify scan took about twice as
long as a C++ compile/link cycle, unless you add "data flow" analysis -
in which case the time is much, much larger.

The brief summary:  In my personal view, Fortify is a worthwhile tool,
but it would not be my first choice.  (Given the opportunity to choose
two tools, it would probably be my second.)  Others involved in the
evaluation reached the opposite conclusion, and rated Fortify first.

							-- Jerry

Fortify


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************




From goertzel_karen at bah.com  Wed Jun  7 20:11:03 2006
From: goertzel_karen at bah.com (Goertzel Karen)
Date: Wed, 7 Jun 2006 20:11:03 -0400
Subject: [SC-L] Samsung "gets it"!
References: <a06230900c0ad1b1f624f@[68.98.145.216]>
Message-ID: <184D5FFC5203644FB4F8864B0EE445B4E7373C@MCLNEXVS06.resource.ds.bah.com>

Anyone looking to move to Austin, TX?

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703-902-6981
goertzel_karen at bah.com


-----Original Message-----
[snip]

>1. US: Austin, Texas: Senior Security Systems Analyst
>     Posted by: "Andrew Cardwell" andrew at cardwell.co.uk acardwelluk
>     Date: Tue Jun 6, 2006 12:19 pm (PDT)
>
>This position has been posted using http://www.security-jobs.info
>
>Job Title: Senior Security Systems Analyst
>Location: Austin, Texas, US
>
>The salary for this jobs is $competitive per Year and the role is a
>Full-Time position.
>
>Additional benefits: Quarterly Bonus, Excellent Employee Benefits
>
>Job Description: The Senior Security Systems Analyst will implement
>and support application level software security. Responsibilities
>include reviewing all software currently in use at Samsung Austin and
>recommending appropriate software security measures. Will also be
>involved with development of security code to support developers in
>implementation of their software as well as training developers on ISO
>security requirements. Maintenance of software security policies also
>required.
>
>Successful candidates must possess extensive knowledge of software
>security concepts. 10+ years of development experience (Web and Visual
>Basic) and understanding of Microsoft and Unix security capabilities,
>including Active Directory. Experience working in an ISO certified IT
>department required. Bachelor's Degree in related field or equivalent
>experience required.
>
>
>Additional Information: The Senior Security Systems Analyst will
>implement and support application level software security.
>Responsibilities include reviewing all software currently in use at
>Samsung Austin and recommending appropriate software security
>measures. Will also be involved with development of security code to
>support developers in implementation of their software as well as
>training developers on ISO security requirements. Maintenance of
>software security policies also required.
>
>Successful candidates must possess extensive knowledge of software
>security concepts. 10+ years of development experience (Web and Visual
>Basic) and understanding of Microsoft and Unix security capabilities,
>including Active Directory. Experience working in an ISO certified IT
>department required. Bachelor's Degree in related field or equivalent
>experience required.
>
>Visa Requirements: Resident Only
>
>If you are interested in this role then please contact:
>Carolyn Vernick
>Samsung Semiconductor
>512-672-1294
>cvernick at sas.samsung.com
>
>Please mention http://www.security-jobs.info when applying for this
>position.
>Please do not apply for this position unless you meet the visa
>requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060607/2d3d87bc/attachment.html 

From gunnar at arctecgroup.net  Thu Jun  8 09:27:57 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Thu, 08 Jun 2006 08:27:57 -0500
Subject: [SC-L] Comparing Scanning Tools
In-Reply-To: <3D427B563FFFC947A412CDF5FDE991B201D8184B@AD1HFDEXC308.ad1.prod>
Message-ID: <C0AD900D.9E3%gunnar@arctecgroup.net>

Hi James,

I think you are right to look at it as economic issue, but the other factor
to add into your model is not just the short term impact to developer
productivity (which is non-trivial), but also the long term effects of
making decisions *not* to deal with finding bugs.

"Cleaning up data breach costs more than encryption

Protecting customer records is a much less expensive than paying for
cleanup after a data breach or massive records loss, research company
Gartner said. Gartner analyst Avivah Litan testified on identity theft
at a Senate hearing held after the Department of Veterans Affairs lost
26.5 million vet identities. "A company with at least 10,000 accounts to
protect can spend, in the first year, as little as $6 per customer
account for just data encryption, or as much as $16 per customer account
for data encryption, host-based intrusion prevention, and strong
security audits combined," Litan said. "Compare [that] with an
expenditure of at least $90 per customer account when data is
compromised or exposed during a breach," she added. Litan recommended
encryption as the first step enterprises and government agencies should
take to protect customer/citizen data. If that's not feasible,
organizations should deploy host-based intrusion prevention systems, she
said, and/or conduct security audits to validate that the company or
agency has satisfactory controls in place."
http://www.techweb.com/wire/security/188702019

Or, Brian Chess once pointed out:
" My favorite historical analogy this month is from medicine: it took
*decades* between the time that researchers knew that fewer people died if
surgeons washed their hands and the time that antisepsis was common in the
medical community.  That lag was entirely due to social factors: if it's
1840 you've been successfully practicing medicine for decades, why would you
want to change your routine?  And yet imagine a modern day surgeon who says
"I'm really busy today, so I'm going to save time by not scrubbing in before
I start the operation."  It's simply unthinkable.  Hopefully software
development is headed in the same direction, but on an accelerated
timetable."

-gp

On 6/7/06 4:08 PM, "McGovern, James F (HTSC, IT)"
<James.McGovern at thehartford.com> wrote:

> Thanks for the response. One of the things that I have been struggling to
> understand is not the importance of using such a tool as I believe they
> provide value but more of the fact that these tools may not be financial
> sustainable.
> 
> Many large enterprises nowadays outsource development to third parties.
> Likewise, the mindset in terms of budgeting tends to eschew "per developer
> seat" tool purchases. Nowadays, it is rare to find an enterprise not using
> free tools such as Eclipse and not paying for IDEs
> 
> I have yet to find a large enterprise that has made a significant investment
> in such tools. I wonder if budgets and the tools themselves are really causing
> more harm than helping in that enterprises will now think about trading off
> such tools vs the expense they cost.
> 
> -----Original Message-----
> From: leichter_jerrold at emc.com [mailto:leichter_jerrold at emc.com]
> Sent: Wednesday, June 07, 2006 4:34 PM
> To: McGovern, James F (HTSC, IT)
> Cc: sc-l at securecoding.org
> Subject: Re: [SC-L] Comparing Scanning Tools
> 
> 
> | Date: Mon, 5 Jun 2006 16:50:17 -0400
> | From: "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com>
> | To: sc-l at securecoding.org
> | Subject: [SC-L] Comparing Scanning Tools
> | 
> | The industry analyst take on tools tends to be slightly different than
> | software practitioners at times. Curious if anyone has looked at Fortify
> and
> | has formed any positive / negative / neutral opinions on this tool and
> | others...
> We evaluated a couple of static code scanning tools internally.  The
> following is an extract from an analysis I did.  I've deliberately
> omitted comparisons - you want to know about Fortify, not how it
> compares to other products (which raises a whole bunch of other
> issues), and included the text below.  Standard disclaimers:  This
> is not EMC's position, it's my personal take.
> 
> Caveats:  This analysis is based on a 3-hour vendor presentation.  The
> presenter may have made mistakes, and I certainly don't claim that my
> recall of what he said is error-free.  A later discussion with others
> familiar with Fortify indicated that the experience we had is typical,
> but is not necessarily the right way to evaluate the tool.  Effective
> use of Fortify requires building a set of rules appropriate to a
> particular environment, method of working, constraints, etc., etc.
> This takes significant time (6 months to a year) and effort, but
> it was claimed that once you've put in the effort, Fortify is a
> very good security scanner.  I am not in a position to evaluate that
> claim myself.
> 
> BTW, one thing not called out below is that Fortify can be quite slow.
> Our experience in testing was that a Fortify scan took about twice as
> long as a C++ compile/link cycle, unless you add "data flow" analysis -
> in which case the time is much, much larger.
> 
> The brief summary:  In my personal view, Fortify is a worthwhile tool,
> but it would not be my first choice.  (Given the opportunity to choose
> two tools, it would probably be my second.)  Others involved in the
> evaluation reached the opposite conclusion, and rated Fortify first.
> 
> -- Jerry
> 
> Fortify
> 
> 
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php




From James.McGovern at thehartford.com  Thu Jun  8 10:15:52 2006
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 8 Jun 2006 10:15:52 -0400
Subject: [SC-L] Comparing Scanning Tools
Message-ID: <3D427B563FFFC947A412CDF5FDE991B201D81853@AD1HFDEXC308.ad1.prod>

Several thoughts:

1. I love it when industry analysts are perceived as being credible by throwing out financial costs for things they really don't have visibility into.

2. The VA lost data not do secure coding techniques but an employee not following the rules on what data to take out of the building.

3. No industry analyst has ever attempted to quantify cost vs benefit of secure coding when compared to other constraints. The quantification to date has only been the cliche: it is cheaper to fix X earlier in the lifecycle rather than later in which X could be pretty much any system quality. 



-----Original Message-----
From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
Sent: Thursday, June 08, 2006 9:28 AM
To: McGovern, James F (HTSC, IT)
Cc: Secure Mailing List
Subject: Re: [SC-L] Comparing Scanning Tools


Hi James,

I think you are right to look at it as economic issue, but the other factor
to add into your model is not just the short term impact to developer
productivity (which is non-trivial), but also the long term effects of
making decisions *not* to deal with finding bugs.

"Cleaning up data breach costs more than encryption

Protecting customer records is a much less expensive than paying for
cleanup after a data breach or massive records loss, research company
Gartner said. Gartner analyst Avivah Litan testified on identity theft
at a Senate hearing held after the Department of Veterans Affairs lost
26.5 million vet identities. "A company with at least 10,000 accounts to
protect can spend, in the first year, as little as $6 per customer
account for just data encryption, or as much as $16 per customer account
for data encryption, host-based intrusion prevention, and strong
security audits combined," Litan said. "Compare [that] with an
expenditure of at least $90 per customer account when data is
compromised or exposed during a breach," she added. Litan recommended
encryption as the first step enterprises and government agencies should
take to protect customer/citizen data. If that's not feasible,
organizations should deploy host-based intrusion prevention systems, she
said, and/or conduct security audits to validate that the company or
agency has satisfactory controls in place."
http://www.techweb.com/wire/security/188702019

Or, Brian Chess once pointed out:
" My favorite historical analogy this month is from medicine: it took
*decades* between the time that researchers knew that fewer people died if
surgeons washed their hands and the time that antisepsis was common in the
medical community.  That lag was entirely due to social factors: if it's
1840 you've been successfully practicing medicine for decades, why would you
want to change your routine?  And yet imagine a modern day surgeon who says
"I'm really busy today, so I'm going to save time by not scrubbing in before
I start the operation."  It's simply unthinkable.  Hopefully software
development is headed in the same direction, but on an accelerated
timetable."

-gp


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************




From gem at cigital.com  Thu Jun  8 10:02:33 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 8 Jun 2006 10:02:33 -0400
Subject: [SC-L] Comparing Scanning Tools
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB421388@va-mail.cigital.com>

Hi All,
 
Just a quick reminder that there is a chapter on code scanning technology and its application in "Software Security" (www.swsec.com).  Don't forget that these tools are best used as aids to make a smart human more efficient.  They do not replace the human, nor are they of much use among the clueless.  Every commercial tool has its issues, but the free tools ITS4, RATS, and flawfinder are not worth using at all anymore given tool evolution of late.  The chapter in "Software Security" discusses the history of these tools, how they actually work, and points to research in academia so you know where they're headed.  There are also pointers to most of the commercial tools.
 
We have found in our practice at Cigital that the most powerful applications of these tools involves developing specific and tailored coding guidelines for a given platform (say J2EE), building those guidelines to just so happen to cohere with security policy (shhh, tell no one), and then enforcing the guidelines by adding rules to a static analysis tool.  
 
Another tip: don't use the tools with all of the default rules all at once.  Carefully turn rules on and off and feed the results into dev along with training.  Use the tools as part of awareness and enforcement activities.
 
gem
Cigital www.cigital.com
Software Security www.swsec.com
Silver Bullet www.cigital.com/silverbullet 
 

	-----Original Message----- 
	From: sc-l-bounces at securecoding.org on behalf of leichter_jerrold at emc.com 
	Sent: Wed 6/7/2006 4:34 PM 
	To: James.McGovern at thehartford.com 
	Cc: sc-l at securecoding.org 
	Subject: Re: [SC-L] Comparing Scanning Tools
	
	

	| Date: Mon, 5 Jun 2006 16:50:17 -0400
	| From: "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com>
	| To: sc-l at securecoding.org
	| Subject: [SC-L] Comparing Scanning Tools
	|
	| The industry analyst take on tools tends to be slightly different than
	| software practitioners at times. Curious if anyone has looked at Fortify
	and
	| has formed any positive / negative / neutral opinions on this tool and
	| others...
	We evaluated a couple of static code scanning tools internally.  The
	following is an extract from an analysis I did.  I've deliberately
	omitted comparisons - you want to know about Fortify, not how it
	compares to other products (which raises a whole bunch of other
	issues), and included the text below.  Standard disclaimers:  This
	is not EMC's position, it's my personal take.
	
	Caveats:  This analysis is based on a 3-hour vendor presentation.  The
	presenter may have made mistakes, and I certainly don't claim that my
	recall of what he said is error-free.  A later discussion with others
	familiar with Fortify indicated that the experience we had is typical,
	but is not necessarily the right way to evaluate the tool.  Effective
	use of Fortify requires building a set of rules appropriate to a
	particular environment, method of working, constraints, etc., etc.
	This takes significant time (6 months to a year) and effort, but
	it was claimed that once you've put in the effort, Fortify is a
	very good security scanner.  I am not in a position to evaluate that
	claim myself.
	
	BTW, one thing not called out below is that Fortify can be quite slow.
	Our experience in testing was that a Fortify scan took about twice as
	long as a C++ compile/link cycle, unless you add "data flow" analysis -
	in which case the time is much, much larger.
	
	The brief summary:  In my personal view, Fortify is a worthwhile tool,
	but it would not be my first choice.  (Given the opportunity to choose
	two tools, it would probably be my second.)  Others involved in the
	evaluation reached the opposite conclusion, and rated Fortify first.
	
	                                                        -- Jerry
	
	Fortify
	
	Fortify is aimed as a tool for use in a security audit.  It is
	deliberately biased in the direction of flagging all potential
	security issues.  It provides two kinds of analysis - what they call
	"semantic" and "data flow".  Neither use of terminology is consistent
	with industry practice.  Their "semantic" analysis is better described
	as a "syntactic" analysis:  It looks at surface features of the
	program (use of certain calls, for example).  It mainly ignores
	context.  Fortify's own representative describe this analysis as a
	"super grep".  This analysis is driven by a large database of rules,
	which can be extended.  (In industry practice, a semantic analysis
	would look deeply at the meaning of the program.)
	
	"Data flow" analysis is better called "taint analysis".  It traces all
	data from external sources to find code that might incorrectly rely on
	it.
	
	When run on our code, semantic analysis reports about 3000 problems.
	We looked closely at quite a number of them, and with a single
	exception (where the code was so complex that no one could be sure),
	they were false positives.  For a security audit, that's probably OK.
	The problem is: What does one do with the false positives?  If this is
	an isolated audit, the answer is - ignore them.  But in practice code
	is always changing, so you'll have to audit it again.  How do you
	avoid dealing with the same false positives every time?
	
	A look at the problems showed that in many if not most of the cases we
	looked at, there was no practical way to change the code to stop the
	complaints.  You can permanently suppress individual complaints, but
	doing so appears to be very hazardous:  The suppression is based on
	the line on which the problem was found.  It could well be that this
	is a false positive because of the surrounding context - and that
	context might change.  For example, if a line has an array reference
	a[i] that is safe because we can prove based on a test 10 lines
	earlier that i is in range - something that Fortify itself cannot do,
	since it does no value flow analysis - then we might suppress the
	warning.  But a later revision to the code could eliminate the test,
	and we apparently would not receive a warning.
	
	The "data flow" analysis gives more useful results.  While the vendor
	was here, we only had data flow analysis for a very small subset of
	the code:  Producing this is an extremely long process (days of CPU
	time).  Again, there were many false positives, though I would
	consider almost all of them to be "legitimate", in the sense that the
	program could not possibly have known certain things about our
	environment that would be needed to eliminate the warning.  However,
	in some cases, the messages were hard to understand:  There was
	insufficient information in the result to figure out just why the
	program had reached the conclusion it had.  Based on what the vendor
	told us, effective use of the "data flow" analysis requires writing
	rules that tell the product when "tainted" data becomes "cleansed".
	This is a questionable procedure:  I recall a time I spent weeks
	tracking down a bug that overwrote memory because of incorrect SNMP
	data.  The bug was triggered way after the point any reasonable
	security analyst would have considered the data "cleansed".  (The
	issue was not with the data as such, but with its interaction with
	deep, incorrect assumptions about its semantics.)
	
	We found two bugs in the Fortify code's understanding of C++
	constructs.  These lead to false positives that it would be impossible
	to suppress except on a line-by-line basis.  The vendor didn't seem
	particularly aggressive about noting these for fixing.  (He may have
	noted it down or may just have a good memory.)  In general, I get the
	feeling that Fortify is much more comfortable with C than with C++.
	For example: Suppose a class has some public member functions, each of
	which validate their arguments; and some private member functions,
	which assume that they are passed valid data (e.g., that indexes are
	in bounds).  Suppose that the public functions do actually ensure
	valid data.  Fortify will complain that the private functions *might*
	be security risks.  The only way around this - and it might not be
	enough to shut Fortify up - is to add validation in all the private
	functions as well.  This is not a style of programming that really
	makes much sense.  The alternative of suppressing the warnings is
	dangerous because someone could add a public function that does *not*
	check its inputs correctly.
	
	Summary
	
	Fortify and XXX, despite being in what is nominally the same
	market, are very different products.  Fortify has broader (but
	shallower) coverage of known security problems.  Its tainted data
	analysis could be very helpful in programs that take data from users
	on the net and deal with it in fairly simple ways.  (For example, if
	the only possible datatypes are things like strings and integers, with
	the complexity all held elsewhere, you are probably OK marking the
	function that converts to integer, or that copies the string to an
	internal form, as "cleansers".)  It could be a useful "code auditors
	workbench".  But as currently implemented, I don't see it as suitable
	for maintaining correctness as code changes.
	_______________________________________________
	Secure Coding mailing list (SC-L)
	SC-L at securecoding.org
	List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
	List charter available at - http://www.securecoding.org/list/charter.php
	



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Thu Jun  8 12:57:33 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 8 Jun 2006 12:57:33 -0400
Subject: [SC-L] SOA and security
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB421393@va-mail.cigital.com>

Hi all,
 
You may recall the article that I wrote with Scott Matsumoto and Jeremy Epstein about SOA security for IEEE S&P magazine.  I recently did an interview with a SOA guy that stemmed from that article.  It's available here:
 
http://soasecurityarchitect.com/2006/06/08/interview-with-gary-mcgraw-cto-of-cigital-inc.aspx
 
gem
 
Cigital www.cigital.com 
Software Security www.swsec.com 
Silver Bullet Podcast www.cigital.com/silverbullet 
 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gunnar at arctecgroup.net  Thu Jun  8 18:57:49 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Thu, 08 Jun 2006 17:57:49 -0500
Subject: [SC-L] Comparing Scanning Tools
In-Reply-To: <3D427B563FFFC947A412CDF5FDE991B201D81853@AD1HFDEXC308.ad1.prod>
Message-ID: <C0AE159D.A17%gunnar@arctecgroup.net>

Hi James,

The point is going back to your original question --  "I wonder if budgets
and the tools themselves are really causing more harm than helping in that
enterprises will now think about trading off such tools vs the expense they
cost." -- the economic comparison needs to take into account the tradeoff
not just the expense of the tool, developer productivity, and bug
remediation early v. late, but also the breach itself has a cost when those
bugs that are not dealt are eventually exercised. So I don't care if you
don't like the Gartner numbers, you can use others to weigh the cost of the
breach (Ponemon's are higher actually), but whatever number you choose to
use should be factored in to your model to account for this. It may not be
helpful if not scrubbing in allows your surgeons to operate on more patients
if they are killing them faster due to infections they cause.

-gp


On 6/8/06 9:15 AM, "McGovern, James F (HTSC, IT)"
<James.McGovern at thehartford.com> wrote:

> Several thoughts:
> 
> 1. I love it when industry analysts are perceived as being credible by
> throwing out financial costs for things they really don't have visibility
> into.
> 
> 2. The VA lost data not do secure coding techniques but an employee not
> following the rules on what data to take out of the building.
> 
> 3. No industry analyst has ever attempted to quantify cost vs benefit of
> secure coding when compared to other constraints. The quantification to date
> has only been the cliche: it is cheaper to fix X earlier in the lifecycle
> rather than later in which X could be pretty much any system quality.
> 
> 
> 
> -----Original Message-----
> From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
> Sent: Thursday, June 08, 2006 9:28 AM
> To: McGovern, James F (HTSC, IT)
> Cc: Secure Mailing List
> Subject: Re: [SC-L] Comparing Scanning Tools
> 
> 
> Hi James,
> 
> I think you are right to look at it as economic issue, but the other factor
> to add into your model is not just the short term impact to developer
> productivity (which is non-trivial), but also the long term effects of
> making decisions *not* to deal with finding bugs.
> 
> "Cleaning up data breach costs more than encryption
> 
> Protecting customer records is a much less expensive than paying for
> cleanup after a data breach or massive records loss, research company
> Gartner said. Gartner analyst Avivah Litan testified on identity theft
> at a Senate hearing held after the Department of Veterans Affairs lost
> 26.5 million vet identities. "A company with at least 10,000 accounts to
> protect can spend, in the first year, as little as $6 per customer
> account for just data encryption, or as much as $16 per customer account
> for data encryption, host-based intrusion prevention, and strong
> security audits combined," Litan said. "Compare [that] with an
> expenditure of at least $90 per customer account when data is
> compromised or exposed during a breach," she added. Litan recommended
> encryption as the first step enterprises and government agencies should
> take to protect customer/citizen data. If that's not feasible,
> organizations should deploy host-based intrusion prevention systems, she
> said, and/or conduct security audits to validate that the company or
> agency has satisfactory controls in place."
> http://www.techweb.com/wire/security/188702019
> 
> Or, Brian Chess once pointed out:
> " My favorite historical analogy this month is from medicine: it took
> *decades* between the time that researchers knew that fewer people died if
> surgeons washed their hands and the time that antisepsis was common in the
> medical community.  That lag was entirely due to social factors: if it's
> 1840 you've been successfully practicing medicine for decades, why would you
> want to change your routine?  And yet imagine a modern day surgeon who says
> "I'm really busy today, so I'm going to save time by not scrubbing in before
> I start the operation."  It's simply unthinkable.  Hopefully software
> development is headed in the same direction, but on an accelerated
> timetable."
> 
> -gp
> 
> 
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php




From brian at fortifysoftware.com  Fri Jun  9 02:28:50 2006
From: brian at fortifysoftware.com (Brian Chess)
Date: Thu, 08 Jun 2006 23:28:50 -0700
Subject: [SC-L] Re: Comparing Scanning Tools
Message-ID: <C0AE6332.15AA1%brian@fortifysoftware.com>

Hi Jerry, as one of the creators of the tool you evaluated, I have to admit
I have the urge to comment on your message one line at a time and explain
each way in which the presentation you attended did not adequately explain
what Fortify does or how we do it.  But I don't think the rest of the people
on this list would find that to be a very interesting posting, so instead
I'm going to try to stick to general comments about a few of the subjects
you brought up.


False positives:
Nobody likes dealing with a pile of false positives, and we work hard to
reduce false positives without giving up potentially exploitable
vulnerabilities.

In some sense, this is where security tools get the raw end of the deal.  If
you're performing static analysis in order to find general quality problems,
you can get away with dropping a potential issue on the floor as soon as you
get a hint that your analysis might be off.  You can't do that if you are
really focused on security.  To make matters worse for security tools, when
a quality-focused tool can detect just some small subset of some security
issue, the create labels it a "quality and security" tool.  Ugh.  This
rarely flies with a security team, but sometimes it works on non-security
folks.
 
Compounding the problem is that, when the static analysis tool does point
you at an exploitable vulnerability, it's often not a very memorable
occasion.  It's just a little goof-up in the code, and often the problem is
obvious once the tool points it out.  So you fix it, and life goes on.  If
you aren't acutely aware of how problematic those little goof-ups can be
once some "researcher" announces one of them, it can almost seem like a
non-event.  All of this can make the hour you spent going through reams of
uninteresting results seem more important than the 5 minutes you spent
solving what could have become a major problem, even though exactly the
opposite is true.


Suppression:
A suppression system that relies on line numbers wouldn't work very well.
When it comes to suppression, the biggest choice you've got to make is
whether or not you're going to rely on code annotation.  Code annotation can
work well if you're reviewing your own code, but if you're reviewing someone
else's code and you can't just go adding annotation goo wherever you like,
you can't use it, at least not exclusively.

Instead, the suppression system needs to be able to match up the salient
features of the suppressed issue against the code it is now evaluating.
Salient features should include factors like the names of variables and
functions, the path or paths required to activate the problem, etc.


Customization:
Of course the more knowledge you provide the tool, the better a job it can
do at telling you things you'd like to know.  But in the great majority of
cases that I've seen, little or no customization is required in order to
derive benefit from any of the commercial static analysis tools I've seen.

In the most successful static analysis deployments, the customization
process never ends--people keep coming up with additional properties they'd
like to check.  The static analysis tool becomes a way to share standards
and best practices.

Regards,
Brian




From brian at fortifysoftware.com  Fri Jun  9 02:45:33 2006
From: brian at fortifysoftware.com (Brian Chess)
Date: Thu, 08 Jun 2006 23:45:33 -0700
Subject: [SC-L] RE: Comparing Scanning Tools
In-Reply-To: <200606080204.k5824YJr069776@ratsass.krvw.com>
Message-ID: <C0AE671D.15AA6%brian@fortifysoftware.com>

McGovern, James F wrote:

> I have yet to find a large enterprise that has made a significant investment
in such tools. 

I?ll give you pointers to two.  They?re two of the three largest software
companies in the world.

http://news.com.com/2100-1002_3-5220488.html
http://news.zdnet.com/2100-3513_22-6002747.html

Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060608/97f2c677/attachment.html 

From gunnar at arctecgroup.net  Fri Jun  9 08:48:25 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Fri, 09 Jun 2006 07:48:25 -0500
Subject: [SC-L] RE: Comparing Scanning Tools
In-Reply-To: <C0AE671D.15AA6%brian@fortifysoftware.com>
Message-ID: <C0AED849.A62%gunnar@arctecgroup.net>

Right, because their customers (are starting to) demand more secure code
from their technology. In the enterprise space the financial, insurance,
healthcare companies who routinely lose their customer?s data and provide
their customers with vulnerability-laden apps have not yet seen the same
amount of customer demand for this, but 84 million public lost records later
( http://www.privacyrights.org/ar/ChronDataBreaches.htm) this may begin to
change.

-gp


On 6/9/06 1:45 AM, "Brian Chess" <brian at fortifysoftware.com> wrote:

> McGovern, James F wrote:
> 
>> > I have yet to find a large enterprise that has made a significant
>> investment in such tools.
> 
> I?ll give you pointers to two.  They?re two of the three largest software
> companies in the world.
> 
> http://news.com.com/2100-1002_3-5220488.html
> http://news.zdnet.com/2100-3513_22-6002747.html
> 
> Brian
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060609/01e2c860/attachment.html 

From James.McGovern at thehartford.com  Fri Jun  9 12:10:19 2006
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Fri, 9 Jun 2006 12:10:19 -0400
Subject: [SC-L] RE: Comparing Scanning Tools
Message-ID: <3D427B563FFFC947A412CDF5FDE991B201D81861@AD1HFDEXC308.ad1.prod>

I think I should have been more specific in my first post. I should have phrased it as I have yet to find a large enterprise whose primary business isn't software or technology that has made a significant investment in such tools.
 
Likewise, a lot of large enteprrises are shifting away from building inhouse to either outsourcing and/or buying which means that secure coding practices should also be enforced via procurement agreements. Has anyone here ran across contract clauses that assist in this regard?

-----Original Message-----
From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
Sent: Friday, June 09, 2006 8:48 AM
To: Brian Chess; Secure Mailing List; McGovern, James F (HTSC, IT)
Subject: Re: [SC-L] RE: Comparing Scanning Tools


Right, because their customers (are starting to) demand more secure code from their technology. In the enterprise space the financial, insurance, healthcare companies who routinely lose their customer's data and provide their customers with vulnerability-laden apps have not yet seen the same amount of customer demand for this, but 84 million public lost records later ( http://www.privacyrights.org/ar/ChronDataBreaches.htm) this may begin to change.

-gp


On 6/9/06 1:45 AM, "Brian Chess" <brian at fortifysoftware.com> wrote:



McGovern, James F wrote:

> I have yet to find a large enterprise that has made a significant investment in such tools. 

I'll give you pointers to two.  They're two of the three largest software companies in the world.

http://news.com.com/2100-1002_3-5220488.html
http://news.zdnet.com/2100-3513_22-6002747.html

Brian


  _____  

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php







*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060609/1f72b341/attachment.html 

From dave.wichers at aspectsecurity.com  Fri Jun  9 13:41:26 2006
From: dave.wichers at aspectsecurity.com (Dave Wichers)
Date: Fri, 9 Jun 2006 13:41:26 -0400
Subject: [SC-L] RE: Comparing Scanning Tools
In-Reply-To: <3D427B563FFFC947A412CDF5FDE991B201D81861@AD1HFDEXC308.ad1.prod>
Message-ID: <000501c68beb$eeb347e0$a204a8c0@intranet.aspectsecurity.com>

The OWASP Legal project took a crack at this:
http://www.owasp.org/index.php/Category:OWASP_Legal_Project

 

This project developed a strawman Secure Software Development Contract annex
which is available at:
http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex

 

This project is led by Jeff Williams of Aspect Security.

 

-Dave

 

Dave Wichers

COO, Aspect Security

 

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of McGovern, James F (HTSC, IT)
Sent: Friday, June 09, 2006 12:10 PM
To: Secure Mailing List
Subject: RE: [SC-L] RE: Comparing Scanning Tools

 

I think I should have been more specific in my first post. I should have
phrased it as I have yet to find a large enterprise whose primary business
isn't software or technology that has made a significant investment in such
tools.

 

Likewise, a lot of large enteprrises are shifting away from building inhouse
to either outsourcing and/or buying which means that secure coding practices
should also be enforced via procurement agreements. Has anyone here ran
across contract clauses that assist in this regard?

-----Original Message-----
From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
Sent: Friday, June 09, 2006 8:48 AM
To: Brian Chess; Secure Mailing List; McGovern, James F (HTSC, IT)
Subject: Re: [SC-L] RE: Comparing Scanning Tools

Right, because their customers (are starting to) demand more secure code
from their technology. In the enterprise space the financial, insurance,
healthcare companies who routinely lose their customer's data and provide
their customers with vulnerability-laden apps have not yet seen the same
amount of customer demand for this, but 84 million public lost records later
( http://www.privacyrights.org/ar/ChronDataBreaches.htm) this may begin to
change.

-gp


On 6/9/06 1:45 AM, "Brian Chess" <brian at fortifysoftware.com> wrote:

McGovern, James F wrote:

> I have yet to find a large enterprise that has made a significant
investment in such tools. 

I'll give you pointers to two.  They're two of the three largest software
companies in the world.

http://news.com.com/2100-1002_3-5220488.html
http://news.zdnet.com/2100-3513_22-6002747.html

Brian


  _____  


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

 



*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060609/06fb53f3/attachment.html 

From jeremy.epstein at webmethods.com  Fri Jun  9 14:32:16 2006
From: jeremy.epstein at webmethods.com (Jeremy Epstein)
Date: Fri, 9 Jun 2006 14:32:16 -0400 
Subject: [SC-L] RE: Comparing Scanning Tools
Message-ID: <C4B880098AA68B4CB4A0B82B1419A460B6CD6E@mailva>

At the RSA Conference in February, I went to a reception hosted by a group
called "Secure Software Forum" (not to be confused with the company Secure
Software Inc, which offers a product competitive to Fortify).  They had a
panel session where representatives from a couple of companies not in the
software/technology business claimed that they're making contractual
requirements in this area (i.e., that vendors are required to assert as part
of the contract what measures they use to assure their code).  So I guess
there's proof by construction that companies other than Microsoft & Oracle
care.
 
Having said that, it's completely at odds compared to what I see working for
an ISV of a non-security product.  That is, I almost never have
prospects/customers ask me what we do to assure our software. If it happened
more often, I'd be able to get more budget to do the analysis that I think
all vendors should do :-(
 
--Jeremy
 
P.S. Since Brian provided a link to a press release about Oracle using
Fortify, I'll offer a link about a financial services company using Secure
Software: http://www.securesoftware.com/news/releases/20050725.html
<http://www.securesoftware.com/news/releases/20050725.html> 


  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of McGovern, James F (HTSC, IT)
Sent: Friday, June 09, 2006 12:10 PM
To: Secure Mailing List
Subject: RE: [SC-L] RE: Comparing Scanning Tools


I think I should have been more specific in my first post. I should have
phrased it as I have yet to find a large enterprise whose primary business
isn't software or technology that has made a significant investment in such
tools.
 
Likewise, a lot of large enteprrises are shifting away from building inhouse
to either outsourcing and/or buying which means that secure coding practices
should also be enforced via procurement agreements. Has anyone here ran
across contract clauses that assist in this regard?

-----Original Message-----
From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
Sent: Friday, June 09, 2006 8:48 AM
To: Brian Chess; Secure Mailing List; McGovern, James F (HTSC, IT)
Subject: Re: [SC-L] RE: Comparing Scanning Tools


Right, because their customers (are starting to) demand more secure code
from their technology. In the enterprise space the financial, insurance,
healthcare companies who routinely lose their customer's data and provide
their customers with vulnerability-laden apps have not yet seen the same
amount of customer demand for this, but 84 million public lost records later
( http://www.privacyrights.org/ar/ChronDataBreaches.htm)
<http://www.privacyrights.org/ar/ChronDataBreaches.htm)>  this may begin to
change.

-gp


On 6/9/06 1:45 AM, "Brian Chess" <brian at fortifysoftware.com> wrote:



McGovern, James F wrote:

> I have yet to find a large enterprise that has made a significant
investment in such tools. 

I'll give you pointers to two.  They're two of the three largest software
companies in the world.

http://news.com.com/2100-1002_3-5220488.html
<http://news.com.com/2100-1002_3-5220488.html> 
http://news.zdnet.com/2100-3513_22-6002747.html
<http://news.zdnet.com/2100-3513_22-6002747.html> 

Brian


  _____  

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
<http://krvw.com/mailman/listinfo/sc-l> 
List charter available at - http://www.securecoding.org/list/charter.php
<http://www.securecoding.org/list/charter.php> 







*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060609/91c111fd/attachment.html 

From ljknews at mac.com  Fri Jun  9 19:57:10 2006
From: ljknews at mac.com (ljknews)
Date: Fri, 9 Jun 2006 19:57:10 -0400
Subject: [SC-L] RE: Comparing Scanning Tools
In-Reply-To: <C4B880098AA68B4CB4A0B82B1419A460B6CD6E@mailva>
References: <C4B880098AA68B4CB4A0B82B1419A460B6CD6E@mailva>
Message-ID: <p05200f21c0afbb20d663@[192.168.1.254]>

At 2:32 PM -0400 6/9/06, Jeremy Epstein wrote:

> Having said that, it's completely at odds compared to what I see working
>for an ISV of a non-security product.  That is, I almost never have
>prospects/customers ask me what we do to assure our software.

I don't even get those questions for our security product !
-- 
Larry Kilgallen
LJK Software


From gem at cigital.com  Mon Jun 12 13:35:29 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 12 Jun 2006 13:35:29 -0400
Subject: [SC-L] Silver Bullet: Dan Geer
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4213C8@va-mail.cigital.com>

Hi all,

The second edition of the Silver Bullet Security Podcast with Gary
McGraw (hey, that's me) went up just a few seconds ago:
http://www.cigital.com/silverbullet/

The first show (with Avi Rubin) proved to be pretty popular.  Hope you
all like this one too!  Feedback welcome through the website.  

Marcus Ranum is on deck and Dana Epp is on the list.  Who else do you
want to hear from in Silver Bullet?

gem
www.cigital.com
www.swsec.com 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From rcs at cert.org  Mon Jun 12 18:07:59 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Mon, 12 Jun 2006 18:07:59 -0400
Subject: [SC-L] managed string library
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4213C8@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4213C8@va-mail.cigital.com>
Message-ID: <448DE5BF.9050306@cert.org>


The SEI has published CMU/SEI-2006-TR-006 "Specifications for Managed
Strings" and released a "proof-of-concept" implementation of the managed
string library.

The specification, source code for the library, and other resources
related to managed strings are available for download from the CERT web
site at:

http://www.cert.org/secure-coding/managedstring.html

The following is a brief summary of the managed string library:

The managed string library was developed in response to the need for a
string library that can improve the quality and security of newly
developed C-language programs while eliminating obstacles to widespread
adoption and possible standardization. As the name implies, the managed
string library is based on a dynamic approach; memory is allocated and
reallocated as required. This approach eliminates the possibility of
unbounded copies, null-termination errors, and truncation by ensuring
that there is always adequate space available for the resulting string
(including the terminating null character). The one exception is if
memory is exhausted; that is treated as an error condition. In this way,
the managed string library accomplishes the goal of indicating either
success or failure. The managed string library also protects against
improper data sanitization by (optionally) ensuring that all characters
in a string belong to a predefined set of "safe" characters.

rCs

-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC

Work: 412-268-7608
FAX: 412-268-6989


From dwheeler at ida.org  Mon Jun 12 18:45:50 2006
From: dwheeler at ida.org (David A. Wheeler)
Date: Mon, 12 Jun 2006 18:45:50 -0400
Subject: [SC-L] Re: Comparing Scanning Tools (false positives)
References: <200606091601.k59G030M016896@ratsass.krvw.com>
Message-ID: <448DEE9E.3050705@ida.org>

I'd like to follow up on Brian Chess' comments...


Brian Chess (brian at fortifysoftware dot com) said:
> False positives:
> Nobody likes dealing with a pile of false positives, and we work hard to
> reduce false positives without giving up potentially exploitable
> vulnerabilities.

I think everyone agrees that there are "way too many false positives"
in the sense that "there are so many it's annoying and it costs money
to check them out" in most of today's tools.

But before you say "tools are useless" you have to ask, "compared to what?"
Manual review can find all sorts of things, but manual review is likely
to miss many serious problems too.  ESPECIALLY if there are only a
few manual reviewers for a large codebase, an all-too-common situation.

Today's tools have a very large set of problems.  But if you look
at the trendlines of the amount of software that people are using,
you'll notice that it is increasing exponentially.   That is unsustainable
for purely manual review approaches, at least as the ONLY approach.
We can either drastically cut the amount of software
(easing review) or use tools -- those are really our only choices.
Reducing the amount of software that needs review is MUCH better
security-wise; if you can do that, DO THAT.  But I think that's
unlikely to occur (or be enough) in many circumstances,
so we need an alternative than crossing our fingers.

I think a sense of perspective is important.  Yes, tools aren't perfect,
but are they better than your alternatives?  Also, tools will
get better as they are used.  I expect that tools will be
refined as they are used in the field (or lose out to better tools).

> In some sense, this is where security tools get the raw end of the deal.  If
> you're performing static analysis in order to find general quality problems,
> you can get away with dropping a potential issue on the floor as soon as you
> get a hint that your analysis might be off.  You can't do that if you are
> really focused on security....

To compensate, many tools use "risk levels" to try to give an
approximate sense of what to look at first.  But the problem is still
the same, tools often cannot be CERTAIN that a construct is a vulnerability,
yet if you throw it away, you might have thrown away reporting on
the most important vulnerability.

> Compounding the problem is that, when the static analysis tool does point
> you at an exploitable vulnerability, it's often not a very memorable
> occasion.  It's just a little goof-up in the code...


Yes. I'll add that often people aren't even certain it IS a
security vulnerability; the analysis to determine if something is a
vulnerability or not may take longer than simply "cleaning up" the code.

Although it's old, the paper on ITS4 is still interesting
(it won the "best paper" award at the time):
  http://www.acsac.org/2000/papers/78.pdf
ITS4 is about as simple/naive a tool as it's possible to usefully implement
(the same is true for RATS and flawfinder, which use the same technique).
But I think the following statements about tools are still true, even
for the more sophisticated tools:
* it still takes time to do analysis (though tools reduce it)
* tools still require expertise to use (particularly in understanding
   the answers and determining if it indicates a real problem)
* tools CAN be helpful in finding real security vulnerabilities.

IIRC, ITS4 once found a vulnerability, the researchers said
"that can't happen" and later they discovered it COULD happen.
I don't remember where I saw that.  The OpenBSD folks have this right,
I think: it is often better to change code to be CERTAIN that it
doesn't have a vulnerability, instead of wasting lengthy efforts
to determine if there's a code path that can be exploited.
It's easy to miss a suprising code path, and even if it's impossible
today, a "trivial" maintenance change might open it up.

So EVEN IF a tool reports on a false positive, sometimes it's because
there's so much excess cleverness that a later maintainance change
would turn it into a serious problem.  In those cases, it's better
to fix it now, so that the software is more resilient to maintenance changes.

Also, a student and I did some measurements and found an unsurprising
trend: software that had a high density of potential vulnerabilities
was more likely to HAVE more vulnerabilities.  We looked at several
source-available programs, and ran several vulnerability analysis
tools on them. The trend was fairly obvious in our limited sample, and
it also wasn't very sensitive to WHICH tool was used.
We expected this, actually.  After all, if a programmer
tends to play with fire, sooner or later they
will get burned.   So if you're getting THAT many false positives,
that may indicate that maybe you should change your approach to
be "safer".  Also, I speculate that this would be true of modules
INSIDE a software system.  If one module has an unusually large
density of vulnerability reports, even if they're all false positives
I would start looking at that module more closely.

--- David A. Wheeler




From gem at cigital.com  Mon Jun 12 20:04:24 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 12 Jun 2006 20:04:24 -0400
Subject: [SC-L] Re: Comparing Scanning Tools (false positives)
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF0E7@va-mail.cigital.com>

Hi all (especially david),

The story you repeated about ITS4 finding a vulnerability "that can't happen" is wrong.  

The tool FIST (a fault injection tool for security) which we decribed in an Oakland paper from 1998 was what you were thinking of.  (FIST was also produced at cigital...the paper was by anup ghosh, tom o'connor, and myself.). FIST found a vulnerbility that we could not figure out how to exploit.  Some 6 months later, a security researcher figured out how and published the sploit.

So david's point stands...but FIST was way less stupid that ITS4.

In my opinion, the first generation tools ITS4, RATS, and flawfinder should all be abandonned immediately for the new generation of commercial tools.

Not using tools today borders on negligence...and I will be happy to say that in court when the time comes.  As I have said before...the lawyers are on the beach.

gem
www.cigital.com
www.swsec.com

 -----Original Message-----
From: 	David A. Wheeler [mailto:dwheeler at ida.org]
Sent:	Mon Jun 12 19:33:52 2006
To:	sc-l at securecoding.org
Subject:	[SC-L] Re: Comparing Scanning Tools (false positives)

I'd like to follow up on Brian Chess' comments...


Brian Chess (brian at fortifysoftware dot com) said:
> False positives:
> Nobody likes dealing with a pile of false positives, and we work hard to
> reduce false positives without giving up potentially exploitable
> vulnerabilities.

I think everyone agrees that there are "way too many false positives"
in the sense that "there are so many it's annoying and it costs money
to check them out" in most of today's tools.

But before you say "tools are useless" you have to ask, "compared to what?"
Manual review can find all sorts of things, but manual review is likely
to miss many serious problems too.  ESPECIALLY if there are only a
few manual reviewers for a large codebase, an all-too-common situation.

Today's tools have a very large set of problems.  But if you look
at the trendlines of the amount of software that people are using,
you'll notice that it is increasing exponentially.   That is unsustainable
for purely manual review approaches, at least as the ONLY approach.
We can either drastically cut the amount of software
(easing review) or use tools -- those are really our only choices.
Reducing the amount of software that needs review is MUCH better
security-wise; if you can do that, DO THAT.  But I think that's
unlikely to occur (or be enough) in many circumstances,
so we need an alternative than crossing our fingers.

I think a sense of perspective is important.  Yes, tools aren't perfect,
but are they better than your alternatives?  Also, tools will
get better as they are used.  I expect that tools will be
refined as they are used in the field (or lose out to better tools).

> In some sense, this is where security tools get the raw end of the deal.  If
> you're performing static analysis in order to find general quality problems,
> you can get away with dropping a potential issue on the floor as soon as you
> get a hint that your analysis might be off.  You can't do that if you are
> really focused on security....

To compensate, many tools use "risk levels" to try to give an
approximate sense of what to look at first.  But the problem is still
the same, tools often cannot be CERTAIN that a construct is a vulnerability,
yet if you throw it away, you might have thrown away reporting on
the most important vulnerability.

> Compounding the problem is that, when the static analysis tool does point
> you at an exploitable vulnerability, it's often not a very memorable
> occasion.  It's just a little goof-up in the code...


Yes. I'll add that often people aren't even certain it IS a
security vulnerability; the analysis to determine if something is a
vulnerability or not may take longer than simply "cleaning up" the code.

Although it's old, the paper on ITS4 is still interesting
(it won the "best paper" award at the time):
  http://www.acsac.org/2000/papers/78.pdf
ITS4 is about as simple/naive a tool as it's possible to usefully implement
(the same is true for RATS and flawfinder, which use the same technique).
But I think the following statements about tools are still true, even
for the more sophisticated tools:
* it still takes time to do analysis (though tools reduce it)
* tools still require expertise to use (particularly in understanding
   the answers and determining if it indicates a real problem)
* tools CAN be helpful in finding real security vulnerabilities.

IIRC, ITS4 once found a vulnerability, the researchers said
"that can't happen" and later they discovered it COULD happen.
I don't remember where I saw that.  The OpenBSD folks have this right,
I think: it is often better to change code to be CERTAIN that it
doesn't have a vulnerability, instead of wasting lengthy efforts
to determine if there's a code path that can be exploited.
It's easy to miss a suprising code path, and even if it's impossible
today, a "trivial" maintenance change might open it up.

So EVEN IF a tool reports on a false positive, sometimes it's because
there's so much excess cleverness that a later maintainance change
would turn it into a serious problem.  In those cases, it's better
to fix it now, so that the software is more resilient to maintenance changes.

Also, a student and I did some measurements and found an unsurprising
trend: software that had a high density of potential vulnerabilities
was more likely to HAVE more vulnerabilities.  We looked at several
source-available programs, and ran several vulnerability analysis
tools on them. The trend was fairly obvious in our limited sample, and
it also wasn't very sensitive to WHICH tool was used.
We expected this, actually.  After all, if a programmer
tends to play with fire, sooner or later they
will get burned.   So if you're getting THAT many false positives,
that may indicate that maybe you should change your approach to
be "safer".  Also, I speculate that this would be true of modules
INSIDE a software system.  If one module has an unusually large
density of vulnerability reports, even if they're all false positives
I would start looking at that module more closely.

--- David A. Wheeler


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From mgmlist at arpawocky.net  Mon Jun 12 20:48:37 2006
From: mgmlist at arpawocky.net (Michael Mucha)
Date: Mon, 12 Jun 2006 17:48:37 -0700
Subject: [SC-L] RE: Comparing Scanning Tools
In-Reply-To: <C4B880098AA68B4CB4A0B82B1419A460B6CD6E@mailva>
References: <C4B880098AA68B4CB4A0B82B1419A460B6CD6E@mailva>
Message-ID: <20060613004837.GB19010@localhost.localdomain>


I've been pushing contractual requirements for ISVs at work (academic medical center with a $1B+ revenue hospital), particularly in the lengthy negotiations last winter with our new clinical information system vendor (the software license alone will cost us about $100M).  

In a nutshell:
- <me> "What secure coding practices do you use in your development process, e.g. source control, code reviews, use of static analysis tools, preferred libraries, training, a/v scanning on the gold master, etc?"
- <vendor> "huh?"
- After about 5 hours of this spread over 3 negotiating sessions, as part of months of overall negotiations, I eventually had to give up on the issue because the $100M train was leaving the barn with or without my requirements, and the vendor wasn't willing to concede more than "our software is compatible with your Symantec A/V". 
	
The good news is that coworkers now regularly come to me during vendor selection to ask about security requirements for contract negotiations, and we've succeeded in getting security provisions added to more recent contracts, but they haven't been in the code assurance area ( e.g. "vendor agrees to add AD auth support" and "vendor agrees their software meets HIPAA regulations regarding electronic signatures" ). Next time I'll start beating the drum earlier with my coworkers so that the issue can be placed at a higher priority, with more people pushing on the vendor. Things creep forward...

I see from the previously-posted http://news.com.com/2100-1002_3-5220488.html that Ounce Labs is trying to push it along:
"announced on Tuesday that it had created a boilerplate contract addendum that holds software makers responsible for guaranteeing the security of their software." 


On Fri, Jun 09, 2006 at 02:32:16PM -0400, Jeremy Epstein wrote:
> panel session where representatives from a couple of companies not in the
> software/technology business claimed that they're making contractual
> requirements in this area (i.e., that vendors are required to assert as part
> of the contract what measures they use to assure their code).  So I guess
> there's proof by construction that companies other than Microsoft & Oracle
> care.
>  


From crispin at novell.com  Tue Jun 13 00:38:57 2006
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 12 Jun 2006 21:38:57 -0700
Subject: [SC-L] Re: Comparing Scanning Tools (false positives)
In-Reply-To: <448DEE9E.3050705@ida.org>
References: <200606091601.k59G030M016896@ratsass.krvw.com>
	<448DEE9E.3050705@ida.org>
Message-ID: <448E4161.4070102@novell.com>

David A. Wheeler wrote:
> Brian Chess (brian at fortifysoftware dot com) said:
>> False positives:
>> Nobody likes dealing with a pile of false positives, and we work hard to
>> reduce false positives without giving up potentially exploitable
>> vulnerabilities.
> I think everyone agrees that there are "way too many false positives"
> in the sense that "there are so many it's annoying and it costs money
> to check them out" in most of today's tools.
>
> But before you say "tools are useless" you have to ask, "compared to
> what?"
> Manual review can find all sorts of things, but manual review is likely
> to miss many serious problems too.  ESPECIALLY if there are only a
> few manual reviewers for a large codebase, an all-too-common situation.
I would like to introduce you to my new kick-ass scanning tool. You run
it over your source code, and it only produces a single false-positive
for you to check out. That false positive just happens to be the
complete source code listing for your entire program :)

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com




From dwheeler at ida.org  Tue Jun 13 10:49:58 2006
From: dwheeler at ida.org (David A. Wheeler)
Date: Tue, 13 Jun 2006 10:49:58 -0400
Subject: [SC-L] Re: Comparing Scanning Tools (false positives)
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF0E7@va-mail.cigital.com>
Message-ID: <448ED096.6060505@ida.org>

Gary McGraw wrote:
> Hi all (especially david),
> 
> The story you repeated about ITS4 finding a vulnerability
 > "that can't happen" is wrong.
> 
> The tool FIST (a fault injection tool for security) which we decribed
 > in an Oakland paper from 1998 was what you were thinking of.
 > (FIST was also produced at cigital...the paper was by anup ghosh,
 > tom o'connor, and myself.). FIST found a vulnerbility that we could not
 > figure out how to exploit.  Some 6 months later, a security researcher
 > figured out how and published the sploit.

Ah! That explains why I couldn't find it.  Right basic story, and right
company... but wrong tool.  Thanks for the correction.

I think it's a very good cautionary tale, and not everyone's
heard it.  Could you post a little more information about that
here, with citations (URLs where possible)?  I believe a preprint
of the FIST paper you mean is here, correct?:
  http://www.cigital.com/papers/download/ieees_p98_2col.pdf


--- David A. Wheeler




From info at secappdev.org  Tue Jun 13 17:38:05 2006
From: info at secappdev.org (Johan Peeters)
Date: Tue, 13 Jun 2006 23:38:05 +0200
Subject: [SC-L] Re: Comparing Scanning Tools (false positives)
In-Reply-To: <448E4161.4070102@novell.com>
References: <200606091601.k59G030M016896@ratsass.krvw.com>	<448DEE9E.3050705@ida.org>
	<448E4161.4070102@novell.com>
Message-ID: <448F303D.4050206@secappdev.org>



Crispin Cowan wrote:
> David A. Wheeler wrote:
> 
>>Brian Chess (brian at fortifysoftware dot com) said:
>>
>>>False positives:
>>>Nobody likes dealing with a pile of false positives, and we work hard to
>>>reduce false positives without giving up potentially exploitable
>>>vulnerabilities.
>>
>>I think everyone agrees that there are "way too many false positives"
>>in the sense that "there are so many it's annoying and it costs money
>>to check them out" in most of today's tools.
>>
>>But before you say "tools are useless" you have to ask, "compared to
>>what?"
>>Manual review can find all sorts of things, but manual review is likely
>>to miss many serious problems too.  ESPECIALLY if there are only a
>>few manual reviewers for a large codebase, an all-too-common situation.
> 
> I would like to introduce you to my new kick-ass scanning tool. You run
> it over your source code, and it only produces a single false-positive
> for you to check out. That false positive just happens to be the
> complete source code listing for your entire program :)

If you can guarantee it is a false positive, this is a very useful tool 
indeed :-)

kr,

Yo

-- 
Johan Peeters
program director
http://www.secappdev.org
+32 16 649000


From dwheeler at ida.org  Tue Jun 13 17:36:28 2006
From: dwheeler at ida.org (David A. Wheeler)
Date: Tue, 13 Jun 2006 17:36:28 -0400
Subject: [SC-L] Re: Comparing Scanning Tools (false positives)
References: <200606091601.k59G030M016896@ratsass.krvw.com>	<448DEE9E.3050705@ida.org>
	<448E4161.4070102@novell.com> <448F303D.4050206@secappdev.org>
Message-ID: <448F2FDC.5040606@ida.org>

> Crispin Cowan wrote:
>> I would like to introduce you to my new kick-ass scanning tool. You run
>> it over your source code, and it only produces a single false-positive
>> for you to check out. That false positive just happens to be the
>> complete source code listing for your entire program :)
> 
> 
> If you can guarantee it is a false positive, this is a very useful tool 
> indeed :-)

Indeed.  Unfortunately, there seems to be a distinct shortage of software
that will trigger the false positive :-) :-).

--- David A. Wheeler






From Ken at krvw.com  Wed Jun 14 09:29:25 2006
From: Ken at krvw.com (Kenneth R. van Wyk)
Date: Wed, 14 Jun 2006 09:29:25 -0400
Subject: [SC-L] Column -- "New Terrorist Profile: Phone Users"
Message-ID: <200606140929.31459@KRvW>

Greetings,

FYI, Gary McGraw has a column on darkreading this month about eavesdropping on 
telephone conversations -- see the full column at:

http://www.darkreading.com/document.asp?doc_id=96927&WT.svl=column1_1
 
It helps put things into context when considering security features for our 
apps.

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
Ihttp://www.KRvW.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060614/0eb6e7d7/attachment.bin 

From jsteven at cigital.com  Wed Jun 14 12:51:50 2006
From: jsteven at cigital.com (John Steven)
Date: Wed, 14 Jun 2006 12:51:50 -0400
Subject: [SC-L] RE: Comparing Scanning Tools
Message-ID: <01D6B7BC-7339-4A38-802F-0964B938D04F@cigital.com>

All,

Sorry it took so long, but I've finally got the new string of  
Building Security In (BSI) articles up on Cigital's website. Brian  
Chess (of Fortify Software) and Pravir Chandra (of Secure Software)  
and I collaborated on an article regarding adopting code analysis  
tools that might be of interest:

http://www.cigital.com/papers/download/j3bsi.pdf

Check it out. I'd say it's "up and coming" rather than "here", but  
some of my more advanced clients have surprisingly good ideas on how  
to assure outsourced development. As one might imagine, they involve:

* Running code analysis tools, penetration tools
* Defining/running programmatic destructive (what they call UAT,  
though they're much deeper) tests
* Incorporating language (in addition to what's provided by OWASP)  
about SLA, QoS, and vulnerability remediation during maintenance
* and other controls

I've seen/helped in rare cases with conducting software architectural  
analyses to determine if the vendor's solution introduced security  
flaws in pursuit of the contracted requirements.

Of course, hard problems still exist... not the least of which being  
the pragmatics of allowing off-shore vendors to promote into  
production, hold staging or production secrets, access to production  
data stores, and so forth.

It's no shock that an organization must have a handle on how much  
software development and maintenance really costs before it allows  
these budgetary 'hits' explicitly. In the end though, they'll get  
paid out anyways on the backend.

----
John Steven
Technical Director; Principal, Software Security Group
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F
http://www.cigital.com
Software Confidence. Achieved.


On Jun 9, 2006, at 2:32 PM, Jeremy Epstein wrote:

> --===============1664004964==
> Content-Type: multipart/alternative;
> 	boundary="----_=_NextPart_001_01C68BF3.086B16AC"
>
> This message is in MIME format. Since your mail reader does not  
> understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C68BF3.086B16AC
> Content-Type: text/plain
>
> At the RSA Conference in February, I went to a reception hosted by  
> a group
> called "Secure Software Forum" (not to be confused with the company  
> Secure
> Software Inc, which offers a product competitive to Fortify).  They  
> had a
> panel session where representatives from a couple of companies not  
> in the
> software/technology business claimed that they're making contractual
> requirements in this area (i.e., that vendors are required to  
> assert as part
> of the contract what measures they use to assure their code).  So I  
> guess
> there's proof by construction that companies other than Microsoft &  
> Oracle
> care.
>
> Having said that, it's completely at odds compared to what I see  
> working for
> an ISV of a non-security product.  That is, I almost never have
> prospects/customers ask me what we do to assure our software. If it  
> happened
> more often, I'd be able to get more budget to do the analysis that  
> I think
> all vendors should do :-(
>
> --Jeremy
>
> P.S. Since Brian provided a link to a press release about Oracle using
> Fortify, I'll offer a link about a financial services company using  
> Secure
> Software: http://www.securesoftware.com/news/releases/20050725.html
> <http://www.securesoftware.com/news/releases/20050725.html>
>
>
>   _____
>
> From: sc-l-bounces at securecoding.org [mailto:sc-l- 
> bounces at securecoding.org]
> On Behalf Of McGovern, James F (HTSC, IT)
> Sent: Friday, June 09, 2006 12:10 PM
> To: Secure Mailing List
> Subject: RE: [SC-L] RE: Comparing Scanning Tools
>
>
> I think I should have been more specific in my first post. I should  
> have
> phrased it as I have yet to find a large enterprise whose primary  
> business
> isn't software or technology that has made a significant investment  
> in such
> tools.
>
> Likewise, a lot of large enteprrises are shifting away from  
> building inhouse
> to either outsourcing and/or buying which means that secure coding  
> practices
> should also be enforced via procurement agreements. Has anyone here  
> ran
> across contract clauses that assist in this regard?
>
> -----Original Message-----
> From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
> Sent: Friday, June 09, 2006 8:48 AM
> To: Brian Chess; Secure Mailing List; McGovern, James F (HTSC, IT)
> Subject: Re: [SC-L] RE: Comparing Scanning Tools
>
>
> Right, because their customers (are starting to) demand more secure  
> code
> from their technology. In the enterprise space the financial,  
> insurance,
> healthcare companies who routinely lose their customer's data and  
> provide
> their customers with vulnerability-laden apps have not yet seen the  
> same
> amount of customer demand for this, but 84 million public lost  
> records later
> ( http://www.privacyrights.org/ar/ChronDataBreaches.htm)
> <http://www.privacyrights.org/ar/ChronDataBreaches.htm)>  this may  
> begin to
> change.
>
> -gp
>
>
> On 6/9/06 1:45 AM, "Brian Chess" <brian at fortifysoftware.com> wrote:
>
>
>
> McGovern, James F wrote:
>
>> I have yet to find a large enterprise that has made a significant
> investment in such tools.
>
> I'll give you pointers to two.  They're two of the three largest  
> software
> companies in the world.
>
> http://news.com.com/2100-1002_3-5220488.html
> <http://news.com.com/2100-1002_3-5220488.html>
> http://news.zdnet.com/2100-3513_22-6002747.html
> <http://news.zdnet.com/2100-3513_22-6002747.html>
>
> Brian
>
>
>   _____
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/ 
> listinfo/sc-l
> <http://krvw.com/mailman/listinfo/sc-l>
> List charter available at - http://www.securecoding.org/list/ 
> charter.php
> <http://www.securecoding.org/list/charter.php>
>
>
>
>
>
>
>
> ********************************************************************** 
> ***
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information. If you are not the  
> intended
> recipient, any use, copying, disclosure, dissemination or  
> distribution is
> strictly prohibited. If you are not the intended recipient, please  
> notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> ********************************************************************** 
> ***
>
>
>
> ------_=_NextPart_001_01C68BF3.086B16AC
> Content-Type: text/html
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <TITLE>Re: [SC-L] RE: Comparing Scanning Tools</TITLE>
>
> <META content=3D"MSHTML 6.00.2900.2876" name=3DGENERATOR></HEAD>
> <BODY>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D545111618-09062006><FONT =
> face=3DArial=20
> color=3D#0000ff size=3D2>At the RSA Conference in February, I went  
> to a =
> reception=20
> hosted by a group called "Secure Software Forum"&nbsp;(not to be =
> confused with=20
> the company Secure Software Inc, which offers a product competitive  
> to=20
> Fortify).&nbsp; They had a panel session where representatives from  
> a =
> couple of=20
> companies not in the software/technology business claimed that  
> they're =
> making=20
> contractual requirements in this area (i.e., that vendors are  
> required =
> to assert=20
> as part of the contract what measures they use to assure their =
> code).&nbsp; So I=20
> guess there's proof by construction that companies other than  
> Microsoft =
> &amp;=20
> Oracle care.</FONT></SPAN></DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D545111618-09062006><FONT =
> face=3DArial=20
> color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D545111618-09062006><FONT =
> face=3DArial=20
> color=3D#0000ff size=3D2>Having said that, it's completely at odds =
> compared to what=20
> I see working for an ISV of a non-security product.&nbsp; That is, I =
> almost=20
> never have prospects/customers ask me what we do to assure our =
> software. If it=20
> happened more often, I'd be able to get more budget to do the  
> analysis =
> that I=20
> think all vendors should do&nbsp;:-(</FONT></SPAN></DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D545111618-09062006><FONT =
> face=3DArial=20
> color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D545111618-09062006><FONT =
> face=3DArial=20
> color=3D#0000ff size=3D2>--Jeremy</FONT></SPAN></DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D545111618-09062006><FONT =
> face=3DArial=20
> color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D545111618-09062006><FONT =
> face=3DArial=20
> color=3D#0000ff size=3D2>P.S. Since Brian provided a link to a press =
> release about=20
> Oracle using Fortify, I'll offer a link about a financial services =
> company using=20
> Secure Software: <A=20
> href=3D"http://www.securesoftware.com/news/releases/ 
> 20050725.html">http:=
> //www.securesoftware.com/news/releases/20050725.html</A></FONT></ 
> SPAN></=
> DIV><BR>
> <BLOCKQUOTE=20
> style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff  
> 2px =
> solid; MARGIN-RIGHT: 0px">
>   <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
> align=3Dleft>
>   <HR tabIndex=3D-1>
>   <FONT face=3DTahoma size=3D2><B>From:</B> =
> sc-l-bounces at securecoding.org=20
>   [mailto:sc-l-bounces at securecoding.org] <B>On Behalf Of </ 
> B>McGovern, =
> James F=20
>   (HTSC, IT)<BR><B>Sent:</B> Friday, June 09, 2006 12:10 =
> PM<BR><B>To:</B> Secure=20
>   Mailing List<BR><B>Subject:</B> RE: [SC-L] RE: Comparing Scanning=20
>   Tools<BR></FONT><BR></DIV>
>   <DIV></DIV>
>   <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
> class=3D617262813-09062006>I=20
>   think I should have been more specific in my first post. I should =
> have phrased=20
>   it as I have yet to find a large enterprise whose primary business =
> isn't=20
>   software or technology that has made a significant investment in  
> such =
>
>   tools.</SPAN></FONT></DIV>
>   <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
>   class=3D617262813-09062006></SPAN></FONT>&nbsp;</DIV>
>   <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
>   class=3D617262813-09062006>Likewise, a lot of large enteprrises  
> are =
> shifting=20
>   away from building inhouse to either outsourcing and/or buying  
> which =
> means=20
>   that secure coding practices should also be enforced via  
> procurement=20
>   agreements. Has anyone here ran across contract clauses that  
> assist =
> in this=20
>   regard?</SPAN></FONT></DIV>
>   <BLOCKQUOTE>
>     <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
> face=3DTahoma=20
>     size=3D2>-----Original Message-----<BR><B>From:</B> Gunnar  
> Peterson =
>
>     [mailto:gunnar at arctecgroup.net]<BR><B>Sent:</B> Friday, June 09, =
> 2006 8:48=20
>     AM<BR><B>To:</B> Brian Chess; Secure Mailing List; McGovern,  
> James =
> F (HTSC,=20
>     IT)<BR><B>Subject:</B> Re: [SC-L] RE: Comparing Scanning=20
>     Tools<BR><BR></FONT></DIV><FONT face=3D"Verdana, Helvetica, =
> Arial"><SPAN=20
>     style=3D"FONT-SIZE: 12px">Right, because their customers (are =
> starting to)=20
>     demand more secure code from their technology. In the enterprise =
> space the=20
>     financial, insurance, healthcare companies who routinely lose  
> their =
>
>     customer&#8217;s data and provide their customers with =
> vulnerability-laden apps=20
>     have not yet seen the same amount of customer demand for this,  
> but =
> 84=20
>     million public lost records later ( <A=20
>     =
> href=3D"http://www.privacyrights.org/ar/ 
> ChronDataBreaches.htm)">http://w=
> ww.privacyrights.org/ar/ChronDataBreaches.htm)</A>=20
>     this may begin to change.<BR><BR>-gp<BR><BR><BR>On 6/9/06 1:45  
> AM, =
> "Brian=20
>     Chess" &lt;brian at fortifysoftware.com&gt; =
> wrote:<BR><BR></SPAN></FONT>
>     <BLOCKQUOTE><FONT face=3D"Verdana, Helvetica, Arial"><SPAN=20
>       style=3D"FONT-SIZE: 12px">McGovern, James F  
> wrote:<BR><BR>&gt; I =
> have yet to=20
>       find a large enterprise that has made a significant  
> investment in =
> such=20
>       tools. <BR><BR>I&#8217;ll give you pointers to two. =
> &nbsp;They&#8217;re two of the=20
>       three largest software companies in the world.<BR><BR><A=20
>       =
> href=3D"http://news.com.com/2100-1002_3-5220488.html">http:// 
> news.com.co=
> m/2100-1002_3-5220488.html</A><BR><A=20
>       =
> href=3D"http://news.zdnet.com/2100-3513_22-6002747.html">http:// 
> news.zdn=
> et.com/2100-3513_22-6002747.html</A><BR><BR>Brian<BR><BR>
>       <HR align=3Dcenter width=3D"95%" SIZE=3D3>
>       </SPAN></FONT><FONT size=3D2><FONT face=3D"Monaco, Courier =
> New"><SPAN=20
>       style=3D"FONT-SIZE: =
> 10px">_______________________________________________<BR>Secure=20
>       Coding mailing list (SC-L)<BR>SC-L at securecoding.org<BR>List =
> information,=20
>       subscriptions, etc - <A=20
>       =
> href=3D"http://krvw.com/mailman/listinfo/sc-l">http://krvw.com/ 
> mailman/l=
> istinfo/sc-l</A><BR>List=20
>       charter available at - <A=20
>       =
> href=3D"http://www.securecoding.org/list/charter.php">http:// 
> www.securec=
> oding.org/list/charter.php</A><BR></SPAN></FONT></FONT></ 
> BLOCKQUOTE><FON=
> T=20
>     size=3D2><FONT face=3D"Monaco, Courier New"><SPAN=20
>   style=3D"FONT-SIZE: 10px"><BR></BLOCKQUOTE></SPAN></FONT></ 
> FONT><FONT =
>
>   =
> size=3D3><BR><BR>***************************************************** 
> **=
> ******************<BR>This=20
>   communication, including attachments, is<BR>for the exclusive use  
> of =
> addressee=20
>   and may contain proprietary,<BR>confidential and/or privileged =
> information. If=20
>   you are not the intended<BR>recipient, any use, copying,  
> disclosure,=20
>   dissemination or distribution is<BR>strictly prohibited. If you  
> are =
> not the=20
>   intended recipient, please notify<BR>the sender immediately by  
> return =
> e-mail,=20
>   delete this communication and<BR>destroy all=20
>   =
> copies.<BR>*********************************************************** 
> **=
> ************<BR></BLOCKQUOTE></FONT></BODY></HTML>
>
> ------_=_NextPart_001_01C68BF3.086B16AC--
>
> --===============1664004964==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/ 
> listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/ 
> charter.php
>
> --===============1664004964==--



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From ken at krvw.com  Wed Jun 21 09:28:39 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 21 Jun 2006 09:28:39 -0400
Subject: [SC-L] Ajax security basics
Message-ID: <A7797EA5-8698-435A-8562-1C7C32FECF0B@krvw.com>

FYI, I just found an article on Ajax security out on Security focus.   
The article is here:

http://www.securityfocus.com/infocus/1868

The article touches on several key issues regarding Ajax, including  
the fact that scripting runs client-side and such.  It also discusses  
how Ajax complicates app testing, which I think is worthwhile to  
consider carefully.

Cheers,

Ken van Wyk
KRvW Associates, LLC
http://www.KRvW.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060621/16e85e4a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20060621/16e85e4a/attachment.bin 

From gunnar at arctecgroup.net  Wed Jun 21 10:18:46 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Wed, 21 Jun 2006 09:18:46 -0500
Subject: [SC-L] Ajax security basics
In-Reply-To: <A7797EA5-8698-435A-8562-1C7C32FECF0B@krvw.com>
References: <A7797EA5-8698-435A-8562-1C7C32FECF0B@krvw.com>
Message-ID: <1150899526.4499554655167@my.visi.com>

Also, Andrew van der Stock did a presentation at OWASP Europe on Ajax security

http://www.greebo.net/?p=344

-gp

Quoting Kenneth Van Wyk <ken at krvw.com>:

> FYI, I just found an article on Ajax security out on Security focus.
> The article is here:
>
> http://www.securityfocus.com/infocus/1868
>
> The article touches on several key issues regarding Ajax, including
> the fact that scripting runs client-side and such.  It also discusses
> how Ajax complicates app testing, which I think is worthwhile to
> consider carefully.
>
> Cheers,
>
> Ken van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
>
>



From ken at krvw.com  Thu Jun 22 21:34:33 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 22 Jun 2006 21:34:33 -0400
Subject: [SC-L] Article -- IBM offers developers free security tools
Message-ID: <C46F17E1-748D-4F1A-A12F-7F576BBA4D9D@krvw.com>

FYI, I saw the following story out on ZD Net today regarding IBM  
releasing some free (and some commercial) software security tools.

http://news.zdnet.com/2100-1009_22-6086913.html?tag=zdfd.newsfeed

In particular, "IBM also introduced a tool called Security Workbench  
Development Environment for Java, which is designed to enable  
developers to configure and validate Java applications that support  
both Java and the Open Services Gateway Initiative (OSGI) industry  
security standards."

I haven't looked at these tools yet, but I thought that some of you  
might find this interesting.

Cheers,

Ken van Wyk
KRvW Associates, LLC
http://www.KRvW.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060622/3680b9fb/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20060622/3680b9fb/attachment.bin 

From vanderaj at greebo.net  Mon Jun 26 13:23:52 2006
From: vanderaj at greebo.net (Andrew van der Stock)
Date: Tue, 27 Jun 2006 03:23:52 +1000
Subject: [SC-L] OWASP PHP Top 5 Announcement
Message-ID: <C7CC411A-0ADB-4A70-9E36-49BDAE487E17@greebo.net>

OWASP is pleased to announce the immediate availability of the OWASP  
PHP Top 5. The OWASP Top 5 is an education piece which provides up to  
date advice to PHP developers, hosters, and other PHP users. The PHP  
Top 5 is produced by the OWASP PHP Project.

The PHP Top 5 is based upon attack frequency in 2005 as reported to  
Bugtraq. This information is a valuable insight into the most  
devastating attacks against the world's most popular web application  
framework.

In 2005, OWASP collaborated with SANS to research and write a  
completely new PHP section for their successful SANS Top 20 2005. The  
OWASP PHP Top 5 is the full unabridged text, updated to reflect  
recent XSS attacks and SQL injection vectors.


OWASP PHP Top 5
http://www.owasp.org/index.php/PHP_Top_5


OWASP PHP Project
http://www.owasp.org/index.php/Category:OWASP_PHP_Project
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2234 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060627/2e152846/attachment.bin 

From stephen at corsaire.com  Fri Jun 30 23:52:00 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Sat, 1 Jul 2006 10:52:00 +0700
Subject: [SC-L] OWASP Java Project: Call for volunteers
Message-ID: <7C6B3F0B-7D89-46B2-B3C6-806C845B5ACA@corsaire.com>


The OWASP Java Project needs your help!

The project's goal is to enable Java and J2EE developers to build  
secure applications efficiently. To this end we plan on producing  
materials that show J2EE architects, developers, and deployers how to  
deal with most common application security problems.  The material  
will be produced in wiki form at the OWASP Java Project wiki:
http://www.owasp.org/index.php/Category:OWASP_Java_Project

Joining the project is easy
- Have a look at the Roadmap:
   http://www.owasp.org/index.php/OWASP_Java_Project_Roadmap
- Read the tutorial on submitting to OWASP:
   http://www.owasp.org/index.php/Tutorial
- And join the mailing list:
   http://lists.owasp.org/mailman/listinfo/java-project

Regards,

The OWASP Java Project leads
Rohyt Belani and Stephen de Vries





From gem at cigital.com  Wed Jul  5 11:06:01 2006
From: gem at cigital.com (Gary McGraw)
Date: Wed, 5 Jul 2006 11:06:01 -0400
Subject: [SC-L] SD West Call for proposals
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>

Hi all,

Last year we rebooted the SD West security track and built a world class
software security track.  The CFP for next year just came out.  Please
consider sending in a proposal!  This is a large, important conference
for developers.  Full disclosure: I am on the Advisory Board (an unpaid
position), and I chair the Software Security track.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 

------------------------------------------------------------------------
--------------
SD WEST 2007 CALL FOR PAPERS IS NOW OPEN!

Submissions will be accepted through August 11, 2006

Please use the following link to update your contact information and
submit your proposal(s):

https://www.cmpevents.com/?M=dDvEPIJYiqQl4C9iAyuVo4W8FAXC7STigxTzjA0oxuL
kcQ==

You may want to save this personalized URL to return to this page later.
(This link logs you in automatically, by-passing the password
requirement. If you share this link you may be compromising your
personal data.)

With a 19-year history, Software Development Conference & Expo West is
the place where software development professionals go to learn how to
build better software. No other developer conference matches the
comprehensive mix of training delivered by the industry's most respected
faculty. SD has always been dedicated to highlighting the newest cutting
edge technologies as well as presenting a relevant core curriculum of
development fundamentals.

Conference Details:
March 19-23, 2007
Santa Clara Convention Center
Santa Clara, CA

Sessions must focus on independent education. Sessions containing any
product, tool or service sales pitch will not be accepted.

If you have questions regarding the Call for Papers, please contact me
at tcarter at cmp.com.


Regards,
Tamara Carter, Conference Manager, Dr. Dobb's SD Events


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Wed Jul  5 20:10:43 2006
From: gem at cigital.com (Gary McGraw)
Date: Wed, 5 Jul 2006 20:10:43 -0400
Subject: [SC-L] Sd west
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF4B6@va-mail.cigital.com>


As about 10 of you pointed out to me privately, the url I broadcast today included identity information of mine.  It wasn't supposed to, but it did.  Should have done some testing in my haste!

Anyway, that url is dead now.  Here is a generic url for submissions to sd west.  I do encourage you all to submit something great.  We need to make software security blossom.

https://www.cmpevents.com/SDw7/a.asp?option=N&CPid=152

Sorry for the mistake.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com


Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From ge at linuxbox.org  Fri Jul  7 02:45:20 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Fri, 7 Jul 2006 01:45:20 -0500 (CDT)
Subject: [SC-L] "Baking Security In" - Microsoft dev security training
Message-ID: <Pine.LNX.4.21.0607070144270.2830-100000@linuxbox.org>

http://softwaredev.itbusinessnet.com/articles/viewarticle.jsp?id=47176

	Gadi.



From Ken at KRvW.com  Fri Jul  7 09:05:17 2006
From: Ken at KRvW.com (Kenneth Van Wyk)
Date: Fri, 7 Jul 2006 09:05:17 -0400
Subject: [SC-L] Dr. Dobb's | Quick-Kill Project Management | June 30, 2006
Message-ID: <9F0D8BA4-E32C-480F-9013-9C7146467DC3@KRvW.com>

Greetings SC-L,

I saw an article on Dr. Dobb's (via Slashdot) this morning that made  
me pause a bit.  The article is on "Quick-Kill Project Management" --  
full link is here:

http://www.ddj.com/dept/architect/189401902

The article describes a small project team (say 5 developers) who  
have suddenly had their dev schedule drastically accelerated on them  
by powers outside of their control.  It describes some techniques  
that the dev leader can use to concentrate the team's focus on  
killing (hence the name) the most pressing of issues.  Not  
surprisingly, there's no mention of security in the article, although  
they do talk about conducting code reviews, but only for functional  
defects in the code.

What caught my attention here is that I'll bet that a *lot* of small  
dev teams end up in situations very similar to the one described in  
the article's opening statements.  In that sort of situation (where  
the company VP says "finish this yesterday"), I'd expect that doing  
just about any sort of security review is the first thing to be  
dropped from the dev schedule.  I wonder, though, if teams that have  
already integrated (say) static analysis tools into their build cycle  
might have a fighting chance at *not* dropping those checks during  
this kind of "death march".  Put another way, how does a team hold  
onto its good practices (not just security reviews) when they're in  
crisis mode?  I'm sure that the answer varies a lot by team,  
priorities, etc., but I'd welcome any comments, opinions, etc. from  
any of you who have been in similar situations.

Cheers,

Ken

Kenneth Van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060707/01e2c5f8/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20060707/01e2c5f8/attachment.bin 

From ken at krvw.com  Fri Jul  7 09:09:44 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 7 Jul 2006 09:09:44 -0400
Subject: [SC-L] Dr. Dobb's | Quick-Kill Project Management | June 30, 2006
Message-ID: <D6C3D645-E017-47A5-8931-8798828D297D@krvw.com>

Greetings SC-L,

(Sorry for the previous message; I see that my (new) MacGPG is  
causing grief for Mailman, so I'm re-sending this message unsigned.)

I saw an article on Dr. Dobb's (via Slashdot) this morning that made  
me pause a bit.  The article is on "Quick-Kill Project Management" --  
full link is here:

http://www.ddj.com/dept/architect/189401902

The article describes a small project team (say 5 developers) who  
have suddenly had their dev schedule drastically accelerated on them  
by powers outside of their control.  It describes some techniques  
that the dev leader can use to concentrate the team's focus on  
killing (hence the name) the most pressing of issues.  Not  
surprisingly, there's no mention of security in the article, although  
they do talk about conducting code reviews, but only for functional  
defects in the code.

What caught my attention here is that I'll bet that a *lot* of small  
dev teams end up in situations very similar to the one described in  
the article's opening statements.  In that sort of situation (where  
the company VP says "finish this yesterday"), I'd expect that doing  
just about any sort of security review is the first thing to be  
dropped from the dev schedule.  I wonder, though, if teams that have  
already integrated (say) static analysis tools into their build cycle  
might have a fighting chance at *not* dropping those checks during  
this kind of "death march".  Put another way, how does a team hold  
onto its good practices (not just security reviews) when they're in  
crisis mode?  I'm sure that the answer varies a lot by team,  
priorities, etc., but I'd welcome any comments, opinions, etc. from  
any of you who have been in similar situations.

Cheers,

Ken

Kenneth Van Wyk
KRvW Associates, LLC
http://www.KRvW.com



From Kevin.Wall at qwest.com  Fri Jul  7 12:44:47 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Fri, 7 Jul 2006 11:44:47 -0500
Subject: [SC-L] Dr. Dobb's | Quick-Kill Project Management | June 30, 2006
Message-ID: <CF8B26B8B49184429CB084616B0019300244E663@itomae2km05.AD.QINTRA.COM>

Kenneth Van Wyk writes...

> http://www.ddj.com/dept/architect/189401902
> ...
> Put another way, how does a team hold  onto its good practices (not
> just security reviews) when they're in crisis mode?  I'm sure that
> the answer varies a lot by team,  priorities, etc., but I'd welcome
> any comments, opinions, etc. from  any of you who have been in
> similar situations.

I've been in this situation several times in my 25+ years in software
development (especially with post-divestiture Bell Labs). During the
times that it has been successfully addressed, I've noticed one major
common theme and that is that the development team (and particularly the
team lead) has got to have the "balls" to stand up to management and
tell
them that the dev team is unwilling to compromise on quality / security
/
(fill-in-the-blank-with-whatever-is-important-to-you) and that the
ONLY way that it can be done is to drop certain FUNCTIONALITY
(which usually management is reluctant to do).

How successful this approach is depends on the several things
(not a comprehensive list):

	1) Whether the team has any credibility with management or not.
       (Hint: If you've already slipped your original schedule several
       times, you probably don't have any. :-)
	2) How well the dev team presents its arguments, especially in
       terms of risks of NOT doing testing / security reviews /
       insert-your-favorite-here. (Since security is in a large part
       about _managing_ risks, this fits in nicely.) You need to
remember
       though that ultimately, it is management's discretion whether or
       not to accept the risk(s), not the development team's.
	3) How tactfully you present your case. (I.e., don't be
arrogant; be
       willing to show some flexibility, e.g., working some additional
       hrs of unpaid OT; etc.)
    4) Know your Brooks' _Mythical Man-Month. Management almost
certainly
       will offer to give you more developers/testers/etc. This is
almost
       always a bad ROI since you will spend more time bringing those
       individuals up-to-speed on your project than you will get back
       in productivity. Also, know your Capers Jones'; he has produced
some
       excellent documentation that shows that dropping things like
software
       code inspections actually increases software costs and
       time-to-delivery.

It also greatly helps to have a team with enough spine that they all are
willing to walk and find another job if they feel that they are being
held hostage and being forced to make unnecessary compromises.

I have been fortunate to have worked with many such teams in the past
who consider their craftsmanship and pride in their work more important
than prevalent "finish this yesterday" mentality, including a few
teams that HAVE been willing to walk out in such situations. (Of course,
that was during the dotcom boom, when all you had to do to find an
development job was to know how to spell "www". I'm not sure how
committed
those people would have been during the leaner times.)

BTW, I am proud to say that the application security team that I have
worked with for the past six years or so have had the courage to insist
that best practices such as formal use cases, design reviews, code
inspections, etc. be followed even though the _formal_ IT process had
thrown such practices out the window in favor of so-called XP
development
practices. (When it comes to security, I tell management that XP stands
for "eXpect Problems" rather than "eXtreme Programming".)

Of course, it is best to avoid situation like those described in the
_Dr. Dobb's_ article in the first place. That's where it's useful to
have a skill in estimating development effort, and one unfortunately
where I think we as an industry have a rather poor track record.

But that's another topic entirely.

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit
> I saw an article on Dr. Dobb's (via Slashdot) this morning that made  
> me pause a bit.  The article is on "Quick-Kill Project 
> Management" --  
> full link is here:
> 
> http://www.ddj.com/dept/architect/189401902
> 
> The article describes a small project team (say 5 developers) who  
> have suddenly had their dev schedule drastically accelerated on them  
> by powers outside of their control.  It describes some techniques  
> that the dev leader can use to concentrate the team's focus on  
> killing (hence the name) the most pressing of issues.  Not  
> surprisingly, there's no mention of security in the article, 
> although  
> they do talk about conducting code reviews, but only for functional  
> defects in the code.
> 
> What caught my attention here is that I'll bet that a *lot* of small  
> dev teams end up in situations very similar to the one described in  
> the article's opening statements.  In that sort of situation (where  
> the company VP says "finish this yesterday"), I'd expect that doing  
> just about any sort of security review is the first thing to be  
> dropped from the dev schedule.  I wonder, though, if teams that have  
> already integrated (say) static analysis tools into their 
> build cycle  
> might have a fighting chance at *not* dropping those checks during  
> this kind of "death march".  Put another way, how does a team hold  
> onto its good practices (not just security reviews) when they're in  
> crisis mode?  I'm sure that the answer varies a lot by team,  
> priorities, etc., but I'd welcome any comments, opinions, etc. from  
> any of you who have been in similar situations.
> 
> Cheers,
> 
> Ken
> 
> Kenneth Van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.



From gem at cigital.com  Fri Jul  7 14:34:14 2006
From: gem at cigital.com (Gary McGraw)
Date: Fri, 7 Jul 2006 14:34:14 -0400
Subject: [SC-L] Darkreading: on developer optimism
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB421435@va-mail.cigital.com>

Hi all,
 
My latest darkreading column (up just 5 minutes ago) is entitled "If You Build It, They'll Crash It."  
http://www.darkreading.com/document.asp?doc_id=98702&WT.svl=column1_1
 
It's about what we all need to do to get developers and builder types to think about bad people.  I'm trying to address the "nobody would ever do that" problem.
 
Pass it on...
 
gem
 
company www.cigital.com 
podcast www.cigital.com/silverbullet
book www.swsec.com 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From gem at cigital.com  Fri Jul  7 17:51:21 2006
From: gem at cigital.com (Gary McGraw)
Date: Fri, 7 Jul 2006 17:51:21 -0400
Subject: [SC-L] darkreading covers software security
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB421442@va-mail.cigital.com>

Well, kinda...
http://www.darkreading.com/document.asp?doc_id=98338
 
Time for you to hop on over there and post some noise!  I plan to.
 
gem
 
company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From Ken at krvw.com  Mon Jul 10 09:53:06 2006
From: Ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 10 Jul 2006 09:53:06 -0400
Subject: [SC-L] InformationWeek | IT Security | Built-In Software Security
	Flaws Have Companies Up In Arms | July 10, 2006
Message-ID: <08512D10-1A9C-4785-B6AF-5C115A16EEF5@krvw.com>

Greetings SC-Lers,

Here's an interesting article that I stumbled on in Information Week:

http://www.informationweek.com/story/showArticle.jhtml? 
articleID=190301156&cid=RSSfeed_IWK_Security

The article discusses the results of a security survey, indicating  
that enterprise software users are quite fed up with the state of  
software security these days.  I'm sure that none of us should be  
surprised by that, but maybe, just maybe, it's an indicator that  
software purchasers are going to start demanding more?  Or perhaps  
it's Monday and I'm not (yet) sufficiently pessimistic for the  
week.  :-)

Cheers,

Ken

Kenneth Van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060710/4903bd1a/attachment.html 

From gem at cigital.com  Thu Jul 13 07:56:16 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 13 Jul 2006 07:56:16 -0400
Subject: [SC-L] ddj: beyond the badnessometer
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB74258B@va-mail.cigital.com>

Hi all,

Is penetration testing good or bad?

http://ddj.com/dept/security/189500001

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From ge at linuxbox.org  Thu Jul 13 08:52:18 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Thu, 13 Jul 2006 07:52:18 -0500 (CDT)
Subject: [SC-L] ddj: beyond the badnessometer
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB74258B@va-mail.cigital.com>
Message-ID: <Pine.LNX.4.21.0607130748470.10345-100000@linuxbox.org>

On Thu, 13 Jul 2006, Gary McGraw wrote:
> Hi all,
> 
> Is penetration testing good or bad?
> 
> http://ddj.com/dept/security/189500001

It's great, but "penetration testing" of the network assesment types is
useless as it takes a picture of what the network look slike TODAY, while
tomorrow it's a different network with different vulnerabilities.

Automating the process is the way to go.

As to software testing, it considerably depends on what you use. If you
test with SATAN-comparable tools, well, you won't get far.

> 
> gem
> 
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> book www.swsec.com
> 
> 
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 



From nash at solace.net  Thu Jul 13 10:17:53 2006
From: nash at solace.net (Nash)
Date: Thu, 13 Jul 2006 10:17:53 -0400
Subject: [SC-L] ddj: beyond the badnessometer
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB74258B@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB74258B@va-mail.cigital.com>
Message-ID: <20060713141753.GB9859@quack.solace.net>

On Thu, Jul 13, 2006 at 07:56:16AM -0400, Gary McGraw wrote:
> 
> Is penetration testing good or bad?
> http://ddj.com/dept/security/189500001


Test coverage is an issue that penetration testers have to deal with,
without a doubt. Pen-tests can never test every possible attack
vector, which means that pen-tests can not always falsify a security
assertion.

Ok. But... 

First, pen-testers are highly active. The really good ones spend alot
of time in the hacker community keeping up with the latest attack
types, methods, and tools. Hence, the relevance of the test coverage
you get from a skilled pen-tester is actually quite good. In addition,
the tests run are similar to real attacks you're likely to see in the
wild. Also, pen-testsing is often intelligent, focused, and highly
motivated. After all, how would you like to have to go back to your
customer with a blank report? And, the recommendations you get can be
quite good because pen-testers tend to think about the entire
deployment environment, instead of just the code. So, they can help
you use technologies you already have to fix problems instead of
having to write lots and lots of new code to fix them. All of these
make pen-testing a valuable exercise for software environments to go
through.

Second, every software application in deployment has an associated
level of acceptable risk. In many cases, the level of acceptable risk
is low enough that penetration testing provides all the verificaton
capabilities needed. In some cases, the level of acceptable risk is
really low and even pen-testing is overkill. I do mostly code review
work these days, but I find that pen-testing has more general
applicability to my customers. There are exceptions, but not that
many.

Third, pen-tests also have real business advantages that don't
directly address risk mitigation. Pen-test reports are typically more
"down to earth." That is, they can be read more easily and the attacks
can be demonstrated more easily to business leaders, executives, and
other stakeholders. In my experience, recommendations from both
pen-tests and code reviews are commonly ignored. But, a good pen-test
gets the executive blood flowing in a way that code-oriented security
evaluations just don't.

Fourth, assertion falsification isn't always what you're after. Being
able to falsify the statement, "this app is secure enough," is a
common objective, but it's not really that useful for most businesses.
What exactly is secure enough? How do you define it? How do you
measure it?  How much accuracy do you need? How do you get more
accuracy, if you want it? How much do you trust your expert's opinion?

Sometimes, it's better to simply demonstrate a positive assertion,
such as:

    - This application is not subject to known, automatic attacks.
    - This application demonstrates the same security profile in all
      supported deployment environments.
    - This application demonstrates different security profiles,
      depending upon the deployment environment.
    - The latest MS patch does not affect the testable security
      profile of this application.

These are all assertions that pen-testing is arguably pretty good for
demonstrating. In some cases it might even be better than code
anlaysis--e.g., the effects of new environments or upgrades to
low-level libraries, virtual machines, operating systems.

Finally, my freind Sam pointed out that only during some kind of
pen-testing can you really identify what the actual attack surface of
an application looks like in its final deployment environment. This is
especially relevant in today's world because applications are now made
as much through integration of existing, off-the-shelf components as
through new development. A "new" application might only have a few
thousand lines of original code, but might be resting on top of a
software stack that has millions.  Whether it's J2EE, .NET, or LAMP,
all those environments are only really practical to test using some
form of pen-test.

Every security assessment methodology has its limits. Pen-testing has
limited falsification capabilities.  Code review, various kinds of
code analysis, unit testing, whatever else. These methods can all have
practical financial limitations and information accesibility problems. 

Of course, all these are good approaches and a wise security manager
will employ as wide a variety of assessment methods as he can afford
so that they compliment each other. But, affordability is a real
concern for most busineses and pen-testing is pretty affordable.

In the end, no assessment methodology produces results that are as
good as having a skilled Security Developer on your team during the
application design stage. Getting a security architecture in place
that matches your risk tolerance and functional requirements is the
single best way to prevent intrusions, bar none.


    nash e. foster
    Stratum Security, LLC


-- 

"the lyf so short, the craft so long to lerne."
                    - Geoffrey Chaucer



From gem at cigital.com  Thu Jul 13 11:05:01 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 13 Jul 2006 11:05:01 -0400
Subject: [SC-L] ddj: beyond the badnessometer
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7425A3@va-mail.cigital.com>

Excellent post nash.  Thanks!

I agree with you for the most part.  You have a view of pen testing that
is quite sophisticated (especially compared to the usual drivel).  I
agree with you so much that I included pen testing as the third most
important touchpoint in my new book "Software Security" www.swsec.com.
It is the subject of chapter 6.  All the code review and architectural
risk analysis in the world can still be completely sidestepped by poor
decisions regarding the fielded software.  Pen testing is ideal for
looking into that.

But there are two things I want to reiterate:
1) pen testing is a bad way to *start* working on software
security...you'll get much better traction with code review and
architectural risk assessment.  {Of course, what nash says about the
power of a live sploit is true, and that kind of momentum creation may
be called for in a completely new situation where biz execs need basic
clue.}
2) pen testing can't tell you anything about how good your security is,
only how bad it is.
3) never use the results of a pen test as a "punch list" to attain
security

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com






----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------



From dana at vulscan.com  Thu Jul 13 12:48:55 2006
From: dana at vulscan.com (Dana Epp)
Date: Thu, 13 Jul 2006 09:48:55 -0700
Subject: [SC-L] ddj: beyond the badnessometer
Message-ID: <9AE3FC06F0A89A43A4D6F667955082C402D350@sbsmain.Vulscan.local>

Although pentesting isn't perfect, I think in the right scope it has the
potential of acting in a vital role in the development lifecycle of a
project. 

Building known attack patterns into a library which can be run against a
codebase has some merrit, as long as you understand what the resulting
expectations will be. As an example, I would consider automated
vulnerability assessment tools built to do input validation fuzzing to
be part of pentesting. And most pentesters out there use said tools for
that very reason.

I agree that pentesting at the START of a project is futile. Evaluating
the risks to the software by understanding its architecture, inputs and
flows goes much deeper and allows you to better find design flaws
instead of implementation bugs. But I am not so sure I would dismiss the
act of pentesting because of the badness-ometer factor. If we did, we
would also be dismissing things like static code analysis tools as they
may show similar results to many out there.

On a different tangent to this thread though, I don't think that the
BEST use of pentesting is for determining how secure your code is in the
first place. It is much more suited to allow you to stress test failure
code paths for different implementation configurations. No matter how
safe you write your code, pentesting can ferret out different scenarios
that come from deployment configuration problems. That is, if the
pentest tools and the user(s) of said tools know how to run through this
properly. As you mentioned in your article, too many people pass
themselves off as pentesting experts when they aren't. Just because they
CAN run Nessus doesn't mean they are good pentesters.

Its about using the right tool for the right job. As pentest tools
mature I think we will be able to use the growing attack libraries to
test against known patterns to eliminate the brain dead security bugs,
while allowing the tools to go deeper and ferret out problems as it
reaches more code coverage. The more we can automate that process and
make it part of our daily tests... the quicker it can expose 'known
problems' in a code base.

Can anyone recommend a tool that CAN tell you how good your security is?
I thought not.

Here I go quoting Spaf again.

"When the code is incorrect, you can't really talk about security. When
the code is faulty, it cannot be safe."

Problem is, no tool in the world is going to show green blinky lights to
tell you the code is safe. Human heuristics come into play here, and we
have to leverage what assets we have, both manual and automatic, to find
the faulty code and eliminate it. And pentesting is just another one of
those tools in the arsenal to help.

Regards,
Dana Epp 
[Microsoft Security MVP]
http://silverstr.ufies.org/blog/

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw
Sent: Thursday, July 13, 2006 8:05 AM
To: Nash
Cc: Secure Coding Mailing List
Subject: RE: [SC-L] ddj: beyond the badnessometer

Excellent post nash.  Thanks!

I agree with you for the most part.  You have a view of pen testing that
is quite sophisticated (especially compared to the usual drivel).  I
agree with you so much that I included pen testing as the third most
important touchpoint in my new book "Software Security" www.swsec.com.
It is the subject of chapter 6.  All the code review and architectural
risk analysis in the world can still be completely sidestepped by poor
decisions regarding the fielded software.  Pen testing is ideal for
looking into that.

But there are two things I want to reiterate:
1) pen testing is a bad way to *start* working on software
security...you'll get much better traction with code review and
architectural risk assessment.  {Of course, what nash says about the
power of a live sploit is true, and that kind of momentum creation may
be called for in a completely new situation where biz execs need basic
clue.}
2) pen testing can't tell you anything about how good your security is,
only how bad it is.
3) never use the results of a pen test as a "punch list" to attain
security

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com






------------------------------------------------------------------------
----
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is
intended solely for the recipient and use by any other party is not
authorized.  If you are not the intended recipient (or otherwise
authorized to receive this message by the intended recipient), any
disclosure, copying, distribution or use of the contents of the
information is prohibited.  If you have received this electronic message
transmission in error, please contact the sender by reply email and
delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly
from the use of this email or its contents.
Thank You.
------------------------------------------------------------------------
----

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php



From muscetta at gmail.com  Fri Jul 14 06:33:19 2006
From: muscetta at gmail.com (Daniele Muscetta)
Date: Fri, 14 Jul 2006 12:33:19 +0200
Subject: [SC-L] ddj: beyond the badnessometer
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7425A3@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7425A3@va-mail.cigital.com>
Message-ID: <745d56450607140333l75f2a9f2u6cb5546c0005d10b@mail.gmail.com>

On 7/13/06, Gary McGraw <gem at cigital.com> wrote:
>
> 3) never use the results of a pen test as a "punch list" to attain
> security
>


You are right, but very sadly, that's how it gets used by a lot of
companies....
"hey, the pen testers found problem 1, 2, 3 - we fix those, we are fine". No
way. But still.... I've seen this done in a lot of places....

Best,

Daniele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060714/7d662d11/attachment.html 

From ge at linuxbox.org  Fri Jul 14 08:18:08 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Fri, 14 Jul 2006 07:18:08 -0500 (CDT)
Subject: [SC-L] ddj: beyond the badnessometer
In-Reply-To: <745d56450607140333l75f2a9f2u6cb5546c0005d10b@mail.gmail.com>
Message-ID: <Pine.LNX.4.21.0607140716050.24758-100000@linuxbox.org>

On Fri, 14 Jul 2006, Daniele Muscetta wrote:
> On 7/13/06, Gary McGraw <gem at cigital.com> wrote:
> >
> > 3) never use the results of a pen test as a "punch list" to attain
> > security
> >
> 
> 
> You are right, but very sadly, that's how it gets used by a lot of
> companies....
> "hey, the pen testers found problem 1, 2, 3 - we fix those, we are fine". No
> way. But still.... I've seen this done in a lot of places....

Gary is correct on many issues, except for one:
pen-testing is NOT black-box testing. Black-box testing is comparable to
White-box testing in parameters of quantification.

How the client deals with the results is unrelated to the type of
results. It's directly linked to why they ordered the test and how they
treat security.

	Gadi.

> 
> Best,
> 
> Daniele
> 



From arian.evans at anachronic.com  Fri Jul 14 11:56:30 2006
From: arian.evans at anachronic.com (Arian J. Evans)
Date: Fri, 14 Jul 2006 10:56:30 -0500
Subject: [SC-L] ddj: beyond the badnessometer
In-Reply-To: <20060713141753.GB9859@quack.solace.net>
Message-ID: <001201c6a75e$171c1a80$6400a8c0@mail>

Great stuff Nash. To re-iterate one important statement: Many orgs
today will *only* respond to a working exploit. (I'm not sure what
the sample (%clue) of orgs I see is vs. Cigital's client, but...)

Pen-test vs. code review, black-box, white-box, whatever:

There is absolutely no difference at the end of the day in terms of
*verification* between finding SQL injection or susceptibility to
XSS attacks via black box attacks or fully white human eyeball
source code review.

Commission, Omission, transmission, no difference. It's verification.

The pen test *can* make an acceptable 'punch card'. Depends on how
the punch card results are written:

+ Does the punch card simply list the "top 10 XSS'able parameters"?

+ Or does it provide a finding covering both/either:

- design Omission

*or*

- implementation Commission/failure to

"encode output appropriately for the User Agent(s) specified"?

The rabbit hole can, of course, go far more usefully deeper in
terms of problem resolution with source code review. I think
that's the worst sentence I've ever written. Today, maybe for
the last <= 1.5 years, I get "but what library should I use
to accomplish this with [insert_framework]?" instead of "uh,
what's output encoding?" or "input validation is too hard/slow".

Assertion Falsification can be a tail-chaser. That's why you
add in business context. I think you'll find that many good pen
testers sit down with the business and help them define security
goals for the application, e.g.- "Rob must never get Sally's report"
or "Sally's report must remain sacred at all points, in transit,
storage, access, etc."

Commonly this is achieved through threat modeling, which turns
pen testing into a verification mechanism.

Ultimately the folks on this list are pretty smart and I'd wonder
why/if this dialogue is needed, except that a recent discussion
opened my eyes a bit to approaches I thought were doornail dead.

A fairly large consultancy with a practice focused on "application
security" contacted me earlier this year and in the course of
discussing their approach to appsec I asked, "but when do you
talk to the business and when do you work with the developers?"
and their response was "What?"

After repeating the question I got told "Oh, no, you won't
talk to those folks or get to see their documentation; we're
security professionals, not developers".

So evidently there is still a market for high-dollar, completely
blind pen tests of apps with zero business context and no
understanding of architecture, dev/design goals, etc.

Hmmm.

That's what I'm guessing Gary means, and surely that sun is
slowly setting.

-ae

p.s. - Nash, when I first read your post, I thought p2 started
with "Pen tests are highly addictive". Then I re-read.
 

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Nash
> Sent: Thursday, July 13, 2006 9:18 AM
> To: Gary McGraw
> Cc: Secure Coding Mailing List
> Subject: Re: [SC-L] ddj: beyond the badnessometer
> 
> On Thu, Jul 13, 2006 at 07:56:16AM -0400, Gary McGraw wrote:
> > 
> > Is penetration testing good or bad?
> > http://ddj.com/dept/security/189500001
> 
> 
> Test coverage is an issue that penetration testers have to deal with,
> without a doubt. Pen-tests can never test every possible attack
> vector, which means that pen-tests can not always falsify a security
> assertion.
> 
> Ok. But... 
> 
> First, pen-testers are highly active. The really good ones spend alot
> of time in the hacker community keeping up with the latest attack
> types, methods, and tools. Hence, the relevance of the test coverage
> you get from a skilled pen-tester is actually quite good. In addition,
> the tests run are similar to real attacks you're likely to see in the
> wild. Also, pen-testsing is often intelligent, focused, and highly
> motivated. After all, how would you like to have to go back to your
> customer with a blank report? And, the recommendations you get can be
> quite good because pen-testers tend to think about the entire
> deployment environment, instead of just the code. So, they can help
> you use technologies you already have to fix problems instead of
> having to write lots and lots of new code to fix them. All of these
> make pen-testing a valuable exercise for software environments to go
> through.
> 
> Second, every software application in deployment has an associated
> level of acceptable risk. In many cases, the level of acceptable risk
> is low enough that penetration testing provides all the verificaton
> capabilities needed. In some cases, the level of acceptable risk is
> really low and even pen-testing is overkill. I do mostly code review
> work these days, but I find that pen-testing has more general
> applicability to my customers. There are exceptions, but not that
> many.
> 
> Third, pen-tests also have real business advantages that don't
> directly address risk mitigation. Pen-test reports are typically more
> "down to earth." That is, they can be read more easily and the attacks
> can be demonstrated more easily to business leaders, executives, and
> other stakeholders. In my experience, recommendations from both
> pen-tests and code reviews are commonly ignored. But, a good pen-test
> gets the executive blood flowing in a way that code-oriented security
> evaluations just don't.
> 
> Fourth, assertion falsification isn't always what you're after. Being
> able to falsify the statement, "this app is secure enough," is a
> common objective, but it's not really that useful for most businesses.
> What exactly is secure enough? How do you define it? How do you
> measure it?  How much accuracy do you need? How do you get more
> accuracy, if you want it? How much do you trust your expert's opinion?
> 
> Sometimes, it's better to simply demonstrate a positive assertion,
> such as:
> 
>     - This application is not subject to known, automatic attacks.
>     - This application demonstrates the same security profile in all
>       supported deployment environments.
>     - This application demonstrates different security profiles,
>       depending upon the deployment environment.
>     - The latest MS patch does not affect the testable security
>       profile of this application.
> 
> These are all assertions that pen-testing is arguably pretty good for
> demonstrating. In some cases it might even be better than code
> anlaysis--e.g., the effects of new environments or upgrades to
> low-level libraries, virtual machines, operating systems.
> 
> Finally, my freind Sam pointed out that only during some kind of
> pen-testing can you really identify what the actual attack surface of
> an application looks like in its final deployment environment. This is
> especially relevant in today's world because applications are now made
> as much through integration of existing, off-the-shelf components as
> through new development. A "new" application might only have a few
> thousand lines of original code, but might be resting on top of a
> software stack that has millions.  Whether it's J2EE, .NET, or LAMP,
> all those environments are only really practical to test using some
> form of pen-test.
> 
> Every security assessment methodology has its limits. Pen-testing has
> limited falsification capabilities.  Code review, various kinds of
> code analysis, unit testing, whatever else. These methods can all have
> practical financial limitations and information accesibility 
> problems. 
> 
> Of course, all these are good approaches and a wise security manager
> will employ as wide a variety of assessment methods as he can afford
> so that they compliment each other. But, affordability is a real
> concern for most busineses and pen-testing is pretty affordable.
> 
> In the end, no assessment methodology produces results that are as
> good as having a skilled Security Developer on your team during the
> application design stage. Getting a security architecture in place
> that matches your risk tolerance and functional requirements is the
> single best way to prevent intrusions, bar none.
> 
> 
>     nash e. foster
>     Stratum Security, LLC
> 
> 
> -- 
> 
> "the lyf so short, the craft so long to lerne."
>                     - Geoffrey Chaucer
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php



From crispin at novell.com  Fri Jul 14 21:36:06 2006
From: crispin at novell.com (Crispin Cowan)
Date: Fri, 14 Jul 2006 18:36:06 -0700
Subject: [SC-L] Dr. Dobb's | Quick-Kill Project Management | June 30,
 2006
In-Reply-To: <CF8B26B8B49184429CB084616B0019300244E663@itomae2km05.AD.QINTRA.COM>
References: <CF8B26B8B49184429CB084616B0019300244E663@itomae2km05.AD.QINTRA.COM>
Message-ID: <44B84686.7030704@novell.com>

Wall, Kevin wrote:
>     4) Know your Brooks' _Mythical Man-Month. Management almost
> certainly
>        will offer to give you more developers/testers/etc. This is
> almost
>        always a bad ROI since you will spend more time bringing those
>        individuals up-to-speed on your project than you will get back
>        in productivity.
One of the most interesting aspects of the Open Source phenomena is that
open source projects, esp. the Linux kernel, seem to be able to violate
most of Brooks' laws with impunity. Linus has achieved absurd levels of
software development parallelism, using a very loosely knit team of
people, with different social cultures, languages, social agendas, and
most of them have never met each other. Brooks says this should be an
unmitigated disaster, yet it succeeds. Go figure :)

How Linus does this is open to lively debate. That he achieves it is
pretty hard to dispute.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Necessity is the mother of invention ... except for pure math



From goertzel_karen at bah.com  Sat Jul 15 15:27:15 2006
From: goertzel_karen at bah.com (Goertzel Karen)
Date: Sat, 15 Jul 2006 15:27:15 -0400
Subject: [SC-L] "Bumper sticker" definition of secure software
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>
Message-ID: <184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>

I've been struggling for a while to synthesise a definition of secure software that is short and sweet, yet accurate and comprehensive. Here's what I've come up with:

Secure software is software that remains dependable despite efforts to compromise its dependability.

Agree? Disagree?

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703-902-6981
goertzel_karen at bah.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060715/f582d0c0/attachment.html 

From ljknews at mac.com  Sun Jul 16 08:36:29 2006
From: ljknews at mac.com (ljknews)
Date: Sun, 16 Jul 2006 08:36:29 -0400
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com> 
	<184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
Message-ID: <p05200f2ac0dfe31f2634@[192.168.1.254]>

At 3:27 PM -0400 7/15/06, Goertzel Karen wrote:
> Content-class: urn:content-classes:message
> Content-Type: multipart/alternative;
> 	boundary="----_=_NextPart_001_01C6A844.D6A28B6B"
>
> I've been struggling for a while to synthesise a definition of secure
>software that is short and sweet, yet accurate and comprehensive. Here's
>what I've come up with:
>
> Secure software is software that remains dependable despite efforts to
>compromise its dependability.
>
> Agree? Disagree?

I disagree about that being bumper-sticker size, and I think we really
need bumper stickers.
-- 
Larry Kilgallen

From stephen at corsaire.com  Sun Jul 16 09:26:20 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Sun, 16 Jul 2006 20:26:20 +0700
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>
	<184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
Message-ID: <1DF5DB11-E36A-4C7E-98AD-DA0BD78247F4@corsaire.com>


Not even Chuck Norris can break Secure Software.

;)

-- Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com


On 16 Jul 2006, at 02:27, Goertzel Karen wrote:

> I've been struggling for a while to synthesise a definition of  
> secure software that is short and sweet, yet accurate and  
> comprehensive. Here's what I've come up with:
>
> Secure software is software that remains dependable despite efforts  
> to compromise its dependability.
>
> Agree? Disagree?
>
> --
> Karen Mercedes Goertzel, CISSP
> Booz Allen Hamilton
> 703-902-6981
> goertzel_karen at bah.com
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/ 
> listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/ 
> charter.php






From michaelslists at gmail.com  Sun Jul 16 09:32:07 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Sun, 16 Jul 2006 23:32:07 +1000
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <p05200f2ac0dfe31f2634@192.168.1.254>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>
	<184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
	<p05200f2ac0dfe31f2634@192.168.1.254>
Message-ID: <5e01c29a0607160632n715b9d33sfeaf5dcc6517083d@mail.gmail.com>

On 7/16/06, ljknews <ljknews at mac.com> wrote:
> At 3:27 PM -0400 7/15/06, Goertzel Karen wrote:
> > Content-class: urn:content-classes:message
> > Content-Type: multipart/alternative;
> >       boundary="----_=_NextPart_001_01C6A844.D6A28B6B"
> >
> > I've been struggling for a while to synthesise a definition of secure
> >software that is short and sweet, yet accurate and comprehensive. Here's
> >what I've come up with:
> >
> > Secure software is software that remains dependable despite efforts to
> >compromise its dependability.
> >
> > Agree? Disagree?
>
> I disagree about that being bumper-sticker size, and I think we really
> need bumper stickers.

a better bumper sticker would be something like:

"secure software is what i write. call me now to find out how!"

...

i don't see the point of a short phrase. it's obvious what secure
software is. software that has no bugs and no design faults.

-- mic

From secureCoding2dave at davearonson.com  Sun Jul 16 10:46:55 2006
From: secureCoding2dave at davearonson.com (Dave Aronson)
Date: Sun, 16 Jul 2006 10:46:55 -0400
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>
	<184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
Message-ID: <44BA515F.4040802@davearonson.com>

Goertzel Karen wrote:

> Secure software is software that remains dependable despite efforts
> to compromise its dependability.

If you really want to compress that to bumper-sticker size, how about

  "Secure Software:  Does what it's meant to.  Period."

This encompasses both "can't be forced NOT to do what it's meant to do", 
and "can't be forced to do what it's NOT meant to do".

Also note, however, that "Secure Software" is the name of a company 
(which I used to work for).  Dunno how picky they may get about possible 
trademark (service mark?) infringement, though IMHO they'd probably just 
love the free publicity.  ;-)

-Dave

From jjchryan at gwu.edu  Sun Jul 16 14:05:49 2006
From: jjchryan at gwu.edu (Julie J.C.H. Ryan)
Date: Sun, 16 Jul 2006 14:05:49 -0400
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>
	<184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
Message-ID: <37C561EF-07F1-4117-B8EB-0487FB911378@gwu.edu>

So, if software is dependably bad and can dependably be counted on to  
fail, it's secure?

Especially if it resists attempts to compromise such dependability?


On Jul 15, 2006, at 3:27 PM, Goertzel Karen wrote:

> I've been struggling for a while to synthesise a definition of  
> secure software that is short and sweet, yet accurate and  
> comprehensive. Here's what I've come up with:
>
> Secure software is software that remains dependable despite efforts  
> to compromise its dependability.
>
> Agree? Disagree?
>
> --
> Karen Mercedes Goertzel, CISSP
> Booz Allen Hamilton
> 703-902-6981
> goertzel_karen at bah.com
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/ 
> listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/ 
> charter.php


From gunnar at arctecgroup.net  Sun Jul 16 10:56:23 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Sun, 16 Jul 2006 09:56:23 -0500
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <5e01c29a0607160632n715b9d33sfeaf5dcc6517083d@mail.gmail.com>
Message-ID: <C0DFBDC7.1621%gunnar@arctecgroup.net>

Secure software you're (not) soaking in it.


On 7/16/06 8:32 AM, "mikeiscool" <michaelslists at gmail.com> wrote:

> On 7/16/06, ljknews <ljknews at mac.com> wrote:
>> At 3:27 PM -0400 7/15/06, Goertzel Karen wrote:
>>> Content-class: urn:content-classes:message
>>> Content-Type: multipart/alternative;
>>>       boundary="----_=_NextPart_001_01C6A844.D6A28B6B"
>>> 
>>> I've been struggling for a while to synthesise a definition of secure
>>> software that is short and sweet, yet accurate and comprehensive. Here's
>>> what I've come up with:
>>> 
>>> Secure software is software that remains dependable despite efforts to
>>> compromise its dependability.
>>> 
>>> Agree? Disagree?
>> 
>> I disagree about that being bumper-sticker size, and I think we really
>> need bumper stickers.
> 
> a better bumper sticker would be something like:
> 
> "secure software is what i write. call me now to find out how!"
> 
> ...
> 
> i don't see the point of a short phrase. it's obvious what secure
> software is. software that has no bugs and no design faults.
> 
> -- mic
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php



From ge at linuxbox.org  Sun Jul 16 11:07:05 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Sun, 16 Jul 2006 10:07:05 -0500 (CDT)
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <5e01c29a0607160632n715b9d33sfeaf5dcc6517083d@mail.gmail.com>
Message-ID: <Pine.LNX.4.21.0607161006350.8496-100000@linuxbox.org>

On Sun, 16 Jul 2006, mikeiscool wrote:
> On 7/16/06, ljknews <ljknews at mac.com> wrote:
> > At 3:27 PM -0400 7/15/06, Goertzel Karen wrote:
> > > Content-class: urn:content-classes:message
> > > Content-Type: multipart/alternative;
> > >       boundary="----_=_NextPart_001_01C6A844.D6A28B6B"
> > >
> > > I've been struggling for a while to synthesise a definition of secure
> > >software that is short and sweet, yet accurate and comprehensive. Here's
> > >what I've come up with:
> > >
> > > Secure software is software that remains dependable despite efforts to
> > >compromise its dependability.
> > >
> > > Agree? Disagree?
> >
> > I disagree about that being bumper-sticker size, and I think we really
> > need bumper stickers.
> 
> a better bumper sticker would be something like:
> 
> "secure software is what i write. call me now to find out how!"

"I read your email"

jinx.com


From crispin at novell.com  Sun Jul 16 12:10:16 2006
From: crispin at novell.com (Crispin Cowan)
Date: Sun, 16 Jul 2006 09:10:16 -0700
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>
	<184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
Message-ID: <44BA64E8.1060601@novell.com>

Goertzel Karen wrote:
>
> I've been struggling for a while to synthesise a definition of secure
> software that is short and sweet, yet accurate and comprehensive.
>
My favorite is by Ivan Arce, CTO of Core Software, coming out of a
discussion between him and I on a mailing list about 5 years ago.

    Reliable software does what it is supposed to do. Secure software
    does what it is supposed to do, and /nothing else/.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Necessity is the mother of invention ... except for pure math

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060716/cea0a953/attachment.html 

From crispin at novell.com  Mon Jul 17 03:00:42 2006
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 17 Jul 2006 00:00:42 -0700
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <5e01c29a0607161917m392c98cbn633040541984022c@mail.gmail.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>	
	<184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>	
	<44BA64E8.1060601@novell.com>
	<5e01c29a0607161917m392c98cbn633040541984022c@mail.gmail.com>
Message-ID: <44BB359A.2010001@novell.com>

mikeiscool wrote:
> On 7/17/06, Crispin Cowan <crispin at novell.com> wrote:
>> >  Goertzel Karen wrote:
>> > I've been struggling for a while to synthesise a definition of secure
>> > software that is short and sweet, yet accurate and comprehensive.
>>
>> My favorite is by Ivan Arce, CTO of Core Software, coming out of a
>> discussion between him and I on a mailing list about 5 years ago.
>>
>> Reliable software does what it is supposed to do. Secure software
>> does what
>> it is supposed to do, and nothing else.
> and what if it's "supposed" to take unsanitzed input and send it into
> a sql database using the administrators account?
>
> is that secure?
"supposed to" goes to intent. If it is a bug that allows this, then it
was not intentional. If it was intended, then (from this description) it
was likely a Trojan Horse, and it is secure from the perspective of the
attacker who put it there.

IMHO, bumper sticker slogans are necessarily short and glib. There isn't
room to put in all the qualifications and caveats to make it a perfectly
precise statement. As such, mincing words over it is a futile exercise.

Or you could just print a technical paper on a bumper sticker, in really
small font :)

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Necessity is the mother of invention ... except for pure math


From michaelslists at gmail.com  Mon Jul 17 03:19:09 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Mon, 17 Jul 2006 17:19:09 +1000
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <44BB359A.2010001@novell.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>
	<184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
	<44BA64E8.1060601@novell.com>
	<5e01c29a0607161917m392c98cbn633040541984022c@mail.gmail.com>
	<44BB359A.2010001@novell.com>
Message-ID: <5e01c29a0607170019y7aeb2839l368cbb07332e981b@mail.gmail.com>

On 7/17/06, Crispin Cowan <crispin at novell.com> wrote:
> mikeiscool wrote:
> > On 7/17/06, Crispin Cowan <crispin at novell.com> wrote:
> >> >  Goertzel Karen wrote:
> >> > I've been struggling for a while to synthesise a definition of secure
> >> > software that is short and sweet, yet accurate and comprehensive.
> >>
> >> My favorite is by Ivan Arce, CTO of Core Software, coming out of a
> >> discussion between him and I on a mailing list about 5 years ago.
> >>
> >> Reliable software does what it is supposed to do. Secure software
> >> does what
> >> it is supposed to do, and nothing else.
> > and what if it's "supposed" to take unsanitzed input and send it into
> > a sql database using the administrators account?
> >
> > is that secure?
>
> "supposed to" goes to intent.

I don't know. I think there is a difference between "this does what
it's supposed to do" and "this has no design faults". That's all I was
trying to highlight.

The point remains though: trimming this down into a friendly little
phrase is, IMCO, useless.


> If it is a bug that allows this, then it
> was not intentional. If it was intended, then (from this description) it
> was likely a Trojan Horse, and it is secure from the perspective of the
> attacker who put it there.
>
> IMHO, bumper sticker slogans are necessarily short and glib. There isn't
> room to put in all the qualifications and caveats to make it a perfectly
> precise statement. As such, mincing words over it is a futile exercise.
>
> Or you could just print a technical paper on a bumper sticker, in really
> small font :)
>
> Crispin

-- mic

From crispin at novell.com  Mon Jul 17 03:31:31 2006
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 17 Jul 2006 00:31:31 -0700
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <5e01c29a0607170019y7aeb2839l368cbb07332e981b@mail.gmail.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>	
	<184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>	
	<44BA64E8.1060601@novell.com>	
	<5e01c29a0607161917m392c98cbn633040541984022c@mail.gmail.com>	
	<44BB359A.2010001@novell.com>
	<5e01c29a0607170019y7aeb2839l368cbb07332e981b@mail.gmail.com>
Message-ID: <44BB3CD3.6030200@novell.com>

mikeiscool wrote:
> On 7/17/06, Crispin Cowan <crispin at novell.com> wrote:
>> "supposed to" goes to intent.
> I don't know. I think there is a difference between "this does what
> it's supposed to do" and "this has no design faults". That's all I was
> trying to highlight.
The difference between "supposed to", "design flaw", and "implementation
flaw" is entirely dependent on your level of abstraction:

    * Executive: "build a thingie that lets good guys in and keeps bad
      guys out."
    * Director: "build an authentication engine that uses 2-factor
      tokens to authenticate users and only then lets them in."
    * Manager: "use OpenSSL and this piece of glue to implement that
      2-factor thingie."
    * Coder: "main() { ..." :)

Errors can occur at any level of translation. When it does something
"surprising", then the guy at the top can claim that it wasn't
"supposed" to do that, and if you dig hard enough, you will discover
*some* layer of abstraction where the vulnerability violates the upper
intent, but not the lower intent. Hence the bug.

Some example bugs at each level:

    * Executive: forgot to specify who is a "good guy"
    * Director: Forgot to provide complete mediation, so the attacker
      could bypass the authenticator.
    * Manager: the glue thingie allowed proper authentication tokens,
      but also allowed tokens with a string value of 0.
    * Coder: "gets(token); ..."

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Necessity is the mother of invention ... except for pure math


From Holger.Peine at iese.fraunhofer.de  Mon Jul 17 02:32:40 2006
From: Holger.Peine at iese.fraunhofer.de (Holger.Peine at iese.fraunhofer.de)
Date: Mon, 17 Jul 2006 08:32:40 +0200
Subject: [SC-L] "Bumper sticker" definition of secure software
Message-ID: <687F148231CEBF449E6206E3FA7AAC3F1359DE@hermes.iese.fhg.de>

> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Dave Aronson
> If you really want to compress that to bumper-sticker size, how about
> 
>   "Secure Software:  Does what it's meant to.  Period."
> 
> This encompasses both "can't be forced NOT to do what it's 
> meant to do", 
> and "can't be forced to do what it's NOT meant to do".

While I think this is the most concise formulation so far of what 
most readers on this list would mean and would understand, I think
the non-security public does not think of security breaches in
terms of software doing more than it was supposed to. My suggestion
for a bumper sticker is therefore less conceptually crisp, but perhaps 
more accessible:

"Secure Software: Works even if you try to dupe it"

Nice question, though -
Holger Peine

-- 
Dr. Holger Peine, Security and Safety
Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
Phone +49-631-6800-2134, Fax -1299 (shared)
PGP key via http://pgp.mit.edu ; fingerprint is 1BFA 30CB E3ED BA99 E7AE
2BBB C126 A592 48EA F9F8


From gem at cigital.com  Sun Jul 16 22:17:24 2006
From: gem at cigital.com (Gary McGraw)
Date: Sun, 16 Jul 2006 22:17:24 -0400
Subject: [SC-L] "Bumper sticker" definition of secure software
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB742652@va-mail.cigital.com>

I wrote a book with viega a few years ago called "building secure software"...it was not about that company (at all).

Software security: building security in.

gem

P.s. I actually like ivan's quip as reported by crispy.

 -----Original Message-----
From: 	Dave Aronson [mailto:secureCoding2dave at davearonson.com]
Sent:	Sun Jul 16 15:58:08 2006
To:	SC-L at securecoding.org
Subject:	Re: [SC-L] "Bumper sticker" definition of secure software

Goertzel Karen wrote:

> Secure software is software that remains dependable despite efforts
> to compromise its dependability.

If you really want to compress that to bumper-sticker size, how about

  "Secure Software:  Does what it's meant to.  Period."

This encompasses both "can't be forced NOT to do what it's meant to do", 
and "can't be forced to do what it's NOT meant to do".

Also note, however, that "Secure Software" is the name of a company 
(which I used to work for).  Dunno how picky they may get about possible 
trademark (service mark?) infringement, though IMHO they'd probably just 
love the free publicity.  ;-)

-Dave
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From michaelslists at gmail.com  Sun Jul 16 22:17:01 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Mon, 17 Jul 2006 12:17:01 +1000
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <44BA64E8.1060601@novell.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>
	<184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
	<44BA64E8.1060601@novell.com>
Message-ID: <5e01c29a0607161917m392c98cbn633040541984022c@mail.gmail.com>

On 7/17/06, Crispin Cowan <crispin at novell.com> wrote:
>
> >  Goertzel Karen wrote:
> >
> >
> > I've been struggling for a while to synthesise a definition of secure
> > software that is short and sweet, yet accurate and comprehensive.
>
> My favorite is by Ivan Arce, CTO of Core Software, coming out of a
> discussion between him and I on a mailing list about 5 years ago.
>
> Reliable software does what it is supposed to do. Secure software does what
> it is supposed to do, and nothing else.

and what if it's "supposed" to take unsanitzed input and send it into
a sql database using the administrators account?

is that secure?


>  Crispin

-- mic

From secureCoding2dave at davearonson.com  Mon Jul 17 08:48:03 2006
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Mon, 17 Jul 2006 12:48:03 +0000
Subject: [SC-L] (no subject)
Message-ID: <W40253349078701153140483@webmail2>

Gary McGraw [mailto:gem at cigital.com] wrote:

 > I wrote a book with viega a few years ago called "building secure
 > software"...

Yes, John gave us all copies.  Didn't bother to get it autographed though.  :-)

 > it was not about that company (at all).

It certainly was not about the horribly broken software I spent months banging my head against a wall trying to fix....  :-(

 > P.s. I actually like ivan's quip as reported by crispy.

Me too.  It contains the ideas I was trying to convey, more clearly, but it's still too long to fit on a bumper sticker.  :-)

-Dave




From gem at cigital.com  Mon Jul 17 08:59:16 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 17 Jul 2006 08:59:16 -0400
Subject: [SC-L] silver bullet: mjr
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB421462@va-mail.cigital.com>

Hi all,

The silver bullet episode featuring Marcus Ranum went live recently:
http://www.cigital.com/silverbullet/

In the interview, we discuss software security progress briefly. 

BTW, I did an interview with the mysterious Dana Epp (silverstr) last
week that is in the production pipeline.  I'll let you all know when
that goes live too.

gem

company www.cigital.com
book www.swsec.com


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From secureCoding2dave at davearonson.com  Mon Jul 17 09:07:35 2006
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Mon, 17 Jul 2006 13:07:35 +0000
Subject: [SC-L] bumper sticker slogan for secure software
Message-ID: <W41365597693261153141655@webmail2>

mikeiscool [mailto:michaelslists at gmail.com] writes:

 > The point remains though: trimming this down into a friendly little
 > phrase is, IMCO, useless.

One of the common problems in trying to persuade the masses of ANYTHING, be it the importance of secure software, the factual or moral correctness of your political stances, etc., is how to communicate it so that they will understand and receive the message.  You can easily confuse them, bore them, or turn them against yourself.  Truly putting it on bumper stickers is likely to be useless, but this is a useful exercise in thinking how we could express the concept briefly and simply.

Another useful thing would be if all engineers would enroll in Toastmasters, but that's another story.  ;-)

-Dave, Governor of Toastmasters Area 63 (District 27)




From Kevin.Wall at qwest.com  Mon Jul 17 09:16:46 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Mon, 17 Jul 2006 08:16:46 -0500
Subject: [SC-L] "Bumper sticker" definition of secure software
Message-ID: <CF8B26B8B49184429CB084616B0019300244E6D4@itomae2km05.AD.QINTRA.COM>

Crispin Cowan writes...

> IMHO, bumper sticker slogans are necessarily short and glib. 
> There isn't room to put in all the qualifications and caveats
> to make it a perfectly precise statement. As such, mincing
> words over it is a futile exercise.
> 
> Or you could just print a technical paper on a bumper 
> sticker, in really small font :)

Actually, I like that I idea. And it could end with the cliche:
	"If you can read this, you are too close."

Seriously, while I understand that there may be a reason to have
a bumper-sticker-like catch phrase for the definition of "secure",
I think that in the long run, it is more likely to backfire.

I have already reviewed an untold number of security "requirements"
that said "The system shall be secure". Having some bumper-sticker
slogan that we all use would only allow those yo-yos to justify
their "requirements", at least if it reflects  anything regarding
an actual definition of security such as Ivan's comment that Crispan
posted.

With that in mind, maybe it would be less "dangerous" to use something
more pithy or sardonic, but less to the point of an actual definition.

    Security: Pay me now, or I'll pay myself later.

Of course that would only be appropriate for black or grey hats. ;-)

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.


From jeremy.epstein at webmethods.com  Mon Jul 17 11:45:45 2006
From: jeremy.epstein at webmethods.com (Jeremy Epstein)
Date: Mon, 17 Jul 2006 11:45:45 -0400
Subject: [SC-L] "Bumper sticker" definition of secure software
Message-ID: <C4B880098AA68B4CB4A0B82B1419A460011E103A@mailva>

I like the idea of a bumper sticker slogan for the same reason as "elevator
pitches" are useful - they don't cover everything, and they don't try to be
precise - just give enough information to whet the reader's/listener's
appetite.

And with that, I offer the following:

"Software Security Keeps the Bad Guys Out"

No, it's not precise - it doesn't define bad guys, doesn't say anything
about intent, etc.  But it's something people (even CEOs) can understand,
and it provides the motivation for a potential purchaser of software
security technology.

--Jeremy

From Brian.A.Shea at bankofamerica.com  Mon Jul 17 11:57:55 2006
From: Brian.A.Shea at bankofamerica.com (Shea, Brian A)
Date: Mon, 17 Jul 2006 08:57:55 -0700
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <C4B880098AA68B4CB4A0B82B1419A460011E103A@mailva>
Message-ID: <17EF6F3064F79040A085A09975A8595305B7F5CC@ex2k.bankofamerica.com>

My slogan:

Unsecured Applications = Unsecured Business

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Jeremy Epstein
Sent: Monday, July 17, 2006 8:46 AM
To: Secure Coding Mailing List
Subject: Re: [SC-L] "Bumper sticker" definition of secure software

I like the idea of a bumper sticker slogan for the same reason as
"elevator
pitches" are useful - they don't cover everything, and they don't try to
be
precise - just give enough information to whet the reader's/listener's
appetite.

And with that, I offer the following:

"Software Security Keeps the Bad Guys Out"

No, it's not precise - it doesn't define bad guys, doesn't say anything
about intent, etc.  But it's something people (even CEOs) can
understand,
and it provides the motivation for a potential purchaser of software
security technology.

--Jeremy
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

From goertzel_karen at bah.com  Mon Jul 17 12:17:42 2006
From: goertzel_karen at bah.com (Goertzel Karen)
Date: Mon, 17 Jul 2006 12:17:42 -0400
Subject: [SC-L] bumper sticker slogan for secure software
Message-ID: <184D5FFC5203644FB4F8864B0EE445B40111D176@MCLNEXVS06.resource.ds.bah.com>

Or if not Toastmasters, Actors' Studio. :)

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.902.6981
goertzel_karen at bah.com  

> -----Original Message-----
> Another useful thing would be if all engineers would enroll 
> in Toastmasters, but that's another story.  ;-)
> 
> -Dave, Governor of Toastmasters Area 63 (District 27)


From goertzel_karen at bah.com  Mon Jul 17 12:23:17 2006
From: goertzel_karen at bah.com (Goertzel Karen)
Date: Mon, 17 Jul 2006 12:23:17 -0400
Subject: [SC-L] "Bumper sticker" definition of secure software
Message-ID: <184D5FFC5203644FB4F8864B0EE445B40111D17A@MCLNEXVS06.resource.ds.bah.com>

Another possibility:

Secure software can't be subverted.

--
Karen Mercedes Goertzel, CISSP
Booz Allen Hamilton
703.902.6981
goertzel_karen at bah.com  


From secureCoding2dave at davearonson.com  Mon Jul 17 12:29:40 2006
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Mon, 17 Jul 2006 16:29:40 +0000
Subject: [SC-L] (no subject)
Message-ID: <W5363114940325861153153780@webmail4>

Jeremy Epstein [mailto:jeremy.epstein at webmethods.com] writes:

 > "Software Security Keeps the Bad Guys Out"

That's certainly one important aspect, but this slogan doesn't address issues such as staying up, producing correct output, etc.  It also can blur the already much too fuzzy (in the public mind) line between "software security" and "security software".

-Dave




From ge at linuxbox.org  Mon Jul 17 12:37:12 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Mon, 17 Jul 2006 11:37:12 -0500 (CDT)
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B40111D17A@MCLNEXVS06.resource.ds.bah.com>
Message-ID: <Pine.LNX.4.21.0607171135200.6672-100000@linuxbox.org>

On Mon, 17 Jul 2006, Goertzel Karen wrote:
> Another possibility:
> 
> Secure software can't be subverted.

We Read Your Email
Your Program == Swiss Cheese

 
> 
> --
> Karen Mercedes Goertzel, CISSP
> Booz Allen Hamilton
> 703.902.6981
> goertzel_karen at bah.com  
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 


From michaelslists at gmail.com  Mon Jul 17 13:12:50 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Tue, 18 Jul 2006 03:12:50 +1000
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B40111D17A@MCLNEXVS06.resource.ds.bah.com>
References: <184D5FFC5203644FB4F8864B0EE445B40111D17A@MCLNEXVS06.resource.ds.bah.com>
Message-ID: <5e01c29a0607171012i43be2a61k2daec2dcd401fca5@mail.gmail.com>

On 7/18/06, Goertzel Karen <goertzel_karen at bah.com> wrote:
> Another possibility:
>
> Secure software can't be subverted.

Again you are all missing that point that design faults are a major
*major* problem. Cannot be "subvered"; well fine. But what if the main
function of the app itself is wrong. It is not a secure program in
this case.

-- mic

From mark at markgraff.com  Mon Jul 17 13:56:09 2006
From: mark at markgraff.com (mark at markgraff.com)
Date: Mon, 17 Jul 2006 10:56:09 -0700 (PDT)
Subject: [SC-L] "Bumper sticker" definition of secure software
Message-ID: <4983.128.115.27.10.1153158969.squirrel@webmail.coastside.net>

It's my view, as Ken and I have said in a couple of publications, that
secure code "lets you say yes with confidence, and no with certainty".

-mg-





From neumann at csl.sri.com  Mon Jul 17 14:16:40 2006
From: neumann at csl.sri.com (Peter G. Neumann)
Date: Mon, 17 Jul 2006 11:16:40 PDT
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: Your message of Sat, 15 Jul 2006 15:27:15 -0400
Message-ID: <CMM.0.90.4.1153160200.neumann@chiron.csl.sri.com>

You suggest: 

  Secure software is software that remains dependable despite efforts to
  compromise its dependability.

You need a bigger-picture view that encompasses trustworthiness
and assurance.

"Dependable systems are systems that remain dependable despite 
would-be compromises to their dependability."

"Trustworthy systems are systems that are worthy of being trusted
to satisfy their requirements (for security, reliability, survivability,
safety, or whatever)."

Security is generally too narrow by itself, because a system that is
not reliable is not likely to be secure, especially when in 
unreliability mode!

The principle of Keep It Simple is inherently unworkable with respect to
security.  Security is inherently complex.  Trustworthiness is broader and
even more complex.  But if you don't think about trustworthiness more
broadly, what you get is not likely to be very secure.

Forget the bumper sticker approach.


From leichter_jerrold at emc.com  Mon Jul 17 15:24:39 2006
From: leichter_jerrold at emc.com (leichter_jerrold at emc.com)
Date: Mon, 17 Jul 2006 15:24:39 -0400
Subject: [SC-L] "Bumper sticker" definition of secure software
Message-ID: <Pine.SOL.4.61.0607171523160.15505@mental>


		Secure Software:  Safe Ex
		ecution

(No, I'm not serious.)
							-- Jerry


From ge at linuxbox.org  Mon Jul 17 16:32:12 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Mon, 17 Jul 2006 15:32:12 -0500 (CDT)
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <CMM.0.90.4.1153160200.neumann@chiron.csl.sri.com>
Message-ID: <Pine.LNX.4.21.0607171530150.13721-100000@linuxbox.org>

On Mon, 17 Jul 2006, Peter G. Neumann wrote:
> Forget the bumper sticker approach.

Hey Peter. :)

Well, one should forget the bumper-sticker approach if all us broing dry
guys keep try to explain to people how math works.

Instead, teling them:
1+1=?
Didn't learn math, eh?

Is bumper-sticker worthy, if pointless as an example.

In other words:
"I read your email! When have you last audited your code?"


From leichter_jerrold at emc.com  Mon Jul 17 17:48:59 2006
From: leichter_jerrold at emc.com (leichter_jerrold at emc.com)
Date: Mon, 17 Jul 2006 17:48:59 -0400
Subject: [SC-L] Resource limitation
Message-ID: <Pine.SOL.4.61.0607171149510.15505@mental>

I was recently looking at some code to do regular expression matching,
when it occurred to me that one can produce fairly small regular
expressions that require huge amounts of space and time.  There's
nothing in the slightest bit illegal about such regexp's - it's just
inherent in regular expressions that such things exist.

Or consider file compression formats.  Someone out there has a hand-
constructed zip file that corresponds to a file with more bytes than
there are particles in the universe.  Again, perfectly legal as it
stands.

Back in the old days, when users ran programs in their own processes and
operating systems actually bothered to have a model of resource usage
that they enforced, you could at least ensure that the user could only
hurt himself if handed such an object.  These days, OS's tend to ignore
resource issues - memory and time are, for most legitimate purposes,
"too cheap to meter" - and in any case this has long moved outside of
their visibility:  Clients are attaching to multi-thread servers, and
all the OS sees is the aggregate demand.

Allocating huge amounts of memory in almost any multi-threaded app is
likely to cause problems.  Yes, the thread asking for the memory will
die - but unless the code is written very defensively, it stands a
good chance of bring down other threads, or the whole application,
along with it:  Memory is a global resource.

We recently hardened a network protocol against this kind of problem.
You could transfer arbitrary-sized strings over the link.  A string
was sent as a 4-byte length in bytes, followed by the actual data.
A request for 4 GB would fail quickly, breaking the connection.  But
a request for 2 GB might well succeed, starving the rest of the
application.  Worse, the API supports groups of requests - e.g.,
arguments to a function.  Even though the individual requests might
look reasonable, the sum of them could crash the application.  This
makes the hardened code more complex:  You can't just limit the
size of an individual request, you have to limit the total amount
of memory allocated in multiple requests.  Also, because in general
you don't know what the total will be ahead of time, you end up
having to be conservative, so that if a request gets right up close
to the limit, you won't cause the application problems.  (This, of
course, could cause the application *other* problems.)

Is anyone aware of any efforts to control these kinds of vulnerabili-
ties?  It's something that cries out for automation:  Getting it right
by hand is way too hard.  Traditional techniques - strong typing,
unavoidable checking of array bounds and such - may be required for a
more sophisticated approach, but they don't in and of themselves help:
One can exhaust resources with entirely "legal" requests.

In addition, the kinds of resources that you can exhaust this way is
broader than you'd first guess.  Memory is obvious; overrunning a thread
stack is perhaps less so.  (That will *usually* only affect the thread
in question, but not always.)  How about file descriptors?  File space?
Available transmission capacity for a variety of kinds of connections?

 							-- Jerry


From neumann at csl.sri.com  Mon Jul 17 17:20:27 2006
From: neumann at csl.sri.com (Peter G. Neumann)
Date: Mon, 17 Jul 2006 14:20:27 PDT
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: Your message of Mon, 17 Jul 2006 15:32:12 -0500 (CDT)
Message-ID: <CMM.0.90.4.1153171227.neumann@chiron.csl.sri.com>

Gary, If you think security is a funny topic, try this one:

  http://haha.nu/funny/funny-math/

From pmeunier at cerias.purdue.edu  Mon Jul 17 17:29:56 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Mon, 17 Jul 2006 17:29:56 -0400
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>
Message-ID: <C0E17994.13D43%pmeunier@cerias.purdue.edu>

I prefer to define the opposite:

"Insecure Software is like a joke,
Except others laugh at you"

I like it because:
-it captures the notion that vulnerabilities, just like jokes, are very
often made apparent by thinking in a different context from the software's
designers (the straight man).

-It conveys the notion that insecure software is shoddy;

-It conveys the notion that there are people who will find out that you run
insecure software;

-It may motivate some people to care about security by invoking social
stigma ;)


Cheers,
Pascal Meunier
Purdue University CERIAS



On 7/15/06 3:27 PM, "Goertzel Karen" <goertzel_karen at bah.com> wrote:

> I've been struggling for a while to synthesise a definition of secure software
> that is short and sweet, yet accurate and comprehensive. Here's what I've come
> up with:
> 
> Secure software is software that remains dependable despite efforts to
> compromise its dependability.
> 
> Agree? Disagree?
> 
> --
> Karen Mercedes Goertzel, CISSP
> Booz Allen Hamilton
> 703-902-6981
> goertzel_karen at bah.com
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php



From everhart at gce.com  Mon Jul 17 19:33:55 2006
From: everhart at gce.com (Glenn and Mary Everhart)
Date: Mon, 17 Jul 2006 19:33:55 -0400
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <44BB3CD3.6030200@novell.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6BF474@va-mail.cigital.com>		<184D5FFC5203644FB4F8864B0EE445B4E73809@MCLNEXVS06.resource.ds.bah.com>		<44BA64E8.1060601@novell.com>		<5e01c29a0607161917m392c98cbn633040541984022c@mail.gmail.com>		<44BB359A.2010001@novell.com>	<5e01c29a0607170019y7aeb2839l368cbb07332e981b@mail.gmail.com>
	<44BB3CD3.6030200@novell.com>
Message-ID: <44BC1E63.7020107@gce.com>

Crispin Cowan wrote:
> mikeiscool wrote:
>> On 7/17/06, Crispin Cowan <crispin at novell.com> wrote:
>>> "supposed to" goes to intent.
>> I don't know. I think there is a difference between "this does what
>> it's supposed to do" and "this has no design faults". That's all I was
>> trying to highlight.
> The difference between "supposed to", "design flaw", and "implementation
> flaw" is entirely dependent on your level of abstraction:
> 
>     * Executive: "build a thingie that lets good guys in and keeps bad
>       guys out."
>     * Director: "build an authentication engine that uses 2-factor
>       tokens to authenticate users and only then lets them in."
>     * Manager: "use OpenSSL and this piece of glue to implement that
>       2-factor thingie."
>     * Coder: "main() { ..." :)
> 
> Errors can occur at any level of translation. When it does something
> "surprising", then the guy at the top can claim that it wasn't
> "supposed" to do that, and if you dig hard enough, you will discover
> *some* layer of abstraction where the vulnerability violates the upper
> intent, but not the lower intent. Hence the bug.
> 
> Some example bugs at each level:
> 
>     * Executive: forgot to specify who is a "good guy"
>     * Director: Forgot to provide complete mediation, so the attacker
>       could bypass the authenticator.
>     * Manager: the glue thingie allowed proper authentication tokens,
>       but also allowed tokens with a string value of 0.
>     * Coder: "gets(token); ..."
> 
> Crispin
> 
Yep...there are plenty of things that can go wrong. There are also plenty of 
rather clever attacks. Designing a system requires much more complete thought
and a comprehensive viewpoint to have a hope...

As one very very minor example consider:

Authentication only for a payment rather resembles a check with only a signature.

Glenn Everhart


From nash at solace.net  Mon Jul 17 19:32:56 2006
From: nash at solace.net (Nash)
Date: Mon, 17 Jul 2006 19:32:56 -0400
Subject: [SC-L] Resource limitation
In-Reply-To: <Pine.SOL.4.61.0607171149510.15505@mental>
References: <Pine.SOL.4.61.0607171149510.15505@mental>
Message-ID: <20060717233256.GD9859@quack.solace.net>



On Mon, Jul 17, 2006 at 05:48:59PM -0400, leichter_jerrold at emc.com
wrote:
> I was recently looking at some code to do regular expression
> matching, when it occurred to me that one can produce fairly small
> regular expressions that require huge amounts of space and time.
> There's nothing in the slightest bit illegal about such regexp's -
> it's just inherent in regular expressions that such things exist.

Yeah... the set of regular languages is big. And, some have pretty
pathological FSM representations.

> In addition, the kinds of resources that you can exhaust this way is
> broader than you'd first guess.  Memory is obvious; overrunning a
> thread stack is perhaps less so.  ... How about file descriptors?
> File space? Available transmission capacity for a variety of kinds
> of connections?
>

One place to look is capability systems. They're more flexible and
should have all the features you want, but are still largely
theoretical.

    http://en.wikipedia.org/wiki/Capability-based_security


That said, every decent Unix system I'm aware of has ulimit, which you
can use to restrict virtual memory allocations, total open files, etc:

    nash @ quack% ulimit -a
    ...
    virtual memory        (kbytes, -v) unlimited

    nash @ quack% ulimit -v 1024 # just 1M RAM, this'll be fun :-)

    nash @ quack% ( find * )
    find: error while loading shared libraries: libc.so.6: failed to map
    segment from shared object: Cannot allocate memory


Alternately, you can implement your own allocator library for your
application and then impose per-thread limits using that library. How
you do that is going to depend alot on the language. Obviously, there
are lots for C/C++ floating around.

    http://en.wikipedia.org/wiki/Memory_allocation

In Java, you don't get nice knobs on Objects and Threads, but you get
several nice knobs on the VM itself: -Xm, -XM, etc. Other high level
languages have similar problems to Java. I.e., how do you abstract the
"size" of a thing when you don't give access to memory as a flat byte
array? Well, you can do lots of fun things using LIFO queues, or LRU
caches, and so forth. There are performance impacts to consider, but
they you can often tweak things so it sucks primarily for the abuser.

None of these is really that hard to implement. So, do we really need
new theory for this? Dunno. One's mileage does vary.

-nash

-- 

"the lyf so short, the craft so long to lerne."
                    - Geoffrey Chaucer

From rgk at cerias.purdue.edu  Mon Jul 17 22:23:27 2006
From: rgk at cerias.purdue.edu (Rajeev Gopalakrishna)
Date: Mon, 17 Jul 2006 22:23:27 -0400 (EDT)
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <CMM.0.90.4.1153160200.neumann@chiron.csl.sri.com>
References: <CMM.0.90.4.1153160200.neumann@chiron.csl.sri.com>
Message-ID: <Pine.GSO.4.58.0607172218510.14714@basm.cerias.purdue.edu>

Reliability is concerned only with accidental failures while security has
to consider malicious attacks as well. The difference is in the intent of
the software user: benign or malicious.

And for a bumper sticker, here is one for the pessimists:

"Secure Software is a Myth"

and another version for the skeptics:

"Is Secure Software a Myth?"

:)

-rajeev


On Mon, 17 Jul 2006, Peter G. Neumann wrote:

> You suggest:
>
>   Secure software is software that remains dependable despite efforts to
>   compromise its dependability.
>
> You need a bigger-picture view that encompasses trustworthiness
> and assurance.
>
> "Dependable systems are systems that remain dependable despite
> would-be compromises to their dependability."
>
> "Trustworthy systems are systems that are worthy of being trusted
> to satisfy their requirements (for security, reliability, survivability,
> safety, or whatever)."
>
> Security is generally too narrow by itself, because a system that is
> not reliable is not likely to be secure, especially when in
> unreliability mode!
>
> The principle of Keep It Simple is inherently unworkable with respect to
> security.  Security is inherently complex.  Trustworthiness is broader and
> even more complex.  But if you don't think about trustworthiness more
> broadly, what you get is not likely to be very secure.
>
> Forget the bumper sticker approach.
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>

From ge at linuxbox.org  Tue Jul 18 06:34:48 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Tue, 18 Jul 2006 05:34:48 -0500 (CDT)
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <Pine.GSO.4.58.0607172218510.14714@basm.cerias.purdue.edu>
Message-ID: <Pine.LNX.4.21.0607180534170.32072-100000@linuxbox.org>

On Mon, 17 Jul 2006, Rajeev Gopalakrishna wrote:
> Reliability is concerned only with accidental failures while security has
> to consider malicious attacks as well. The difference is in the intent of
> the software user: benign or malicious.
> 
> And for a bumper sticker, here is one for the pessimists:
> 
> "Secure Software is a Myth"
> 
> and another version for the skeptics:
> 
> "Is Secure Software a Myth?"
> 
> :)

Again, this would speak only to a very small percentage of the
population. You me, maybe 10K people around the world if we are generous.

> 
> -rajeev
> 
> 
> On Mon, 17 Jul 2006, Peter G. Neumann wrote:
> 
> > You suggest:
> >
> >   Secure software is software that remains dependable despite efforts to
> >   compromise its dependability.
> >
> > You need a bigger-picture view that encompasses trustworthiness
> > and assurance.
> >
> > "Dependable systems are systems that remain dependable despite
> > would-be compromises to their dependability."
> >
> > "Trustworthy systems are systems that are worthy of being trusted
> > to satisfy their requirements (for security, reliability, survivability,
> > safety, or whatever)."
> >
> > Security is generally too narrow by itself, because a system that is
> > not reliable is not likely to be secure, especially when in
> > unreliability mode!
> >
> > The principle of Keep It Simple is inherently unworkable with respect to
> > security.  Security is inherently complex.  Trustworthiness is broader and
> > even more complex.  But if you don't think about trustworthiness more
> > broadly, what you get is not likely to be very secure.
> >
> > Forget the bumper sticker approach.
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org
> > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> > List charter available at - http://www.securecoding.org/list/charter.php
> >
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 


From petesh at indigo.ie  Tue Jul 18 08:04:59 2006
From: petesh at indigo.ie (Pete Shanahan)
Date: Tue, 18 Jul 2006 13:04:59 +0100
Subject: [SC-L] Resource limitation
In-Reply-To: <Pine.SOL.4.61.0607171149510.15505@mental>
References: <Pine.SOL.4.61.0607171149510.15505@mental>
Message-ID: <44BCCE6B.7050700@indigo.ie>

leichter_jerrold at emc.com wrote:
> I was recently looking at some code to do regular expression matching,
> when it occurred to me that one can produce fairly small regular
> expressions that require huge amounts of space and time.  There's
> nothing in the slightest bit illegal about such regexp's - it's just
> inherent in regular expressions that such things exist.
> 

Been there, done that, watched computers go down again and again from this.

> Or consider file compression formats.  Someone out there has a hand-
> constructed zip file that corresponds to a file with more bytes than
> there are particles in the universe.  Again, perfectly legal as it
> stands.
> 
> Back in the old days, when users ran programs in their own processes and
> operating systems actually bothered to have a model of resource usage
> that they enforced, you could at least ensure that the user could only
> hurt himself if handed such an object.  These days, OS's tend to ignore
> resource issues - memory and time are, for most legitimate purposes,
> "too cheap to meter" - and in any case this has long moved outside of
> their visibility:  Clients are attaching to multi-thread servers, and
> all the OS sees is the aggregate demand.
> 

Most typical unix/linux environments contain aggregate resource meters - per
process limitations on resource usage.

> Allocating huge amounts of memory in almost any multi-threaded app is
> likely to cause problems.  Yes, the thread asking for the memory will
> die - but unless the code is written very defensively, it stands a
> good chance of bring down other threads, or the whole application,
> along with it:  Memory is a global resource.

Ah, now this would be due to the standard definition of a thread. If you used
something more akin to light weight processes then you could isolate this
resource consumption problem a little bit better.

A thread is the basic unit of processing, it was never intended to be a unit of
resource consumption.

> 
> We recently hardened a network protocol against this kind of problem.
> You could transfer arbitrary-sized strings over the link.  A string
> was sent as a 4-byte length in bytes, followed by the actual data.
> A request for 4 GB would fail quickly, breaking the connection.  But
> a request for 2 GB might well succeed, starving the rest of the
> application.  Worse, the API supports groups of requests - e.g.,
> arguments to a function.  Even though the individual requests might
> look reasonable, the sum of them could crash the application.  This
> makes the hardened code more complex:  You can't just limit the
> size of an individual request, you have to limit the total amount
> of memory allocated in multiple requests.  Also, because in general
> you don't know what the total will be ahead of time, you end up
> having to be conservative, so that if a request gets right up close
> to the limit, you won't cause the application problems.  (This, of
> course, could cause the application *other* problems.)
> 

Yes, and this falls into general application design. Most network protocols are
designed around the concept of front loading information into the stack. Every
level puts more information at the front, not at the end.
This means that you can make decisions based on a very small piece of data,
allowing you to quickly process it, or kill it should it causes you problems.

If you're allowing such huge data packets and you haven't got the back-end
system in place to process them quickly, and without resource starvation, then
you're just looking to shoot yourself in the foot.

Every system on the planet has had to deal with these problems. From fork-bombs
through to excess network connections. A lot of them can be prevented using
resource limits. Depending on the OS, you can limit resource usage by either
individual process, or group of processes (typically referred to as a task-group).

Should an operating system not provide you with integrated features to protect
you from these resource consumptions, then you can quite easily create
monitoring tools that are integrated into the application to monitor and prevent
these kinds of things.
Under an OS like Solaris, you could use a facility like dtrace to monitor
resource use from both the application and OS level to make resource allocation
decisions. This facility would not need to be integrated into the application.

the problem is that a lot of the resource decisions that are made with
applications are more dependent on the administrator rather than the application
developer. After all, while an application developer may say '10% of physical
memory left is OK', and administrator might say 'but what about that other
service there that needs 15%'.

> Is anyone aware of any efforts to control these kinds of vulnerabili-
> ties?  It's something that cries out for automation:  Getting it right
> by hand is way too hard.  Traditional techniques - strong typing,
> unavoidable checking of array bounds and such - may be required for a
> more sophisticated approach, but they don't in and of themselves help:
> One can exhaust resources with entirely "legal" requests.
> 
> In addition, the kinds of resources that you can exhaust this way is
> broader than you'd first guess.  Memory is obvious; overrunning a thread
> stack is perhaps less so.  (That will *usually* only affect the thread
> in question, but not always.)  How about file descriptors?  File space?
> Available transmission capacity for a variety of kinds of connections?


-- 
Pete	+353 (87) 412 9576 [M]
Just about every computer on the market today runs Unix, except the Mac
(and nobody cares about it).
		-- Bill Joy 6/21/85


From thesp0nge at gmail.com  Tue Jul 18 10:32:12 2006
From: thesp0nge at gmail.com (Paolo Perego)
Date: Tue, 18 Jul 2006 16:32:12 +0200
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <Pine.LNX.4.21.0607180534170.32072-100000@linuxbox.org>
References: <Pine.GSO.4.58.0607172218510.14714@basm.cerias.purdue.edu>
	<Pine.LNX.4.21.0607180534170.32072-100000@linuxbox.org>
Message-ID: <e9cf3c9b0607180732w37bbb73cqd78e682f2ae3edd@mail.gmail.com>

Hi list, I'll introduce myself with a claim:
"Software is like Titanic, pleople claim it was unsinkable. Securing is
providing it power steering"

thesp0nge

On 7/18/06, Gadi Evron <ge at linuxbox.org> wrote:
>
> On Mon, 17 Jul 2006, Rajeev Gopalakrishna wrote:
> > Reliability is concerned only with accidental failures while security
> has
> > to consider malicious attacks as well. The difference is in the intent
> of
> > the software user: benign or malicious.
> >
> > And for a bumper sticker, here is one for the pessimists:
> >
> > "Secure Software is a Myth"
> >
> > and another version for the skeptics:
> >
> > "Is Secure Software a Myth?"
> >
> > :)
>
> Again, this would speak only to a very small percentage of the
> population. You me, maybe 10K people around the world if we are generous.
>
> >
> > -rajeev
> >
> >
> > On Mon, 17 Jul 2006, Peter G. Neumann wrote:
> >
> > > You suggest:
> > >
> > >   Secure software is software that remains dependable despite efforts
> to
> > >   compromise its dependability.
> > >
> > > You need a bigger-picture view that encompasses trustworthiness
> > > and assurance.
> > >
> > > "Dependable systems are systems that remain dependable despite
> > > would-be compromises to their dependability."
> > >
> > > "Trustworthy systems are systems that are worthy of being trusted
> > > to satisfy their requirements (for security, reliability,
> survivability,
> > > safety, or whatever)."
> > >
> > > Security is generally too narrow by itself, because a system that is
> > > not reliable is not likely to be secure, especially when in
> > > unreliability mode!
> > >
> > > The principle of Keep It Simple is inherently unworkable with respect
> to
> > > security.  Security is inherently complex.  Trustworthiness is broader
> and
> > > even more complex.  But if you don't think about trustworthiness more
> > > broadly, what you get is not likely to be very secure.
> > >
> > > Forget the bumper sticker approach.
> > >
> > > _______________________________________________
> > > Secure Coding mailing list (SC-L)
> > > SC-L at securecoding.org
> > > List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> > > List charter available at -
> http://www.securecoding.org/list/charter.php
> > >
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org
> > List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> > List charter available at - http://www.securecoding.org/list/charter.php
> >
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>



-- 
$>cd /pub
$>more beer

AngeL core developer: http://www.sikurezza.org/angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060718/9e775e27/attachment-0001.html 

From secureCoding2dave at davearonson.com  Tue Jul 18 10:52:56 2006
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Tue, 18 Jul 2006 14:52:56 +0000
Subject: [SC-L] bumper sticker slogan for secure software
Message-ID: <W3425927235120751153234376@webmail2>

Paolo Perego [mailto:thesp0nge at gmail.com] writes:

 > "Software is like Titanic, pleople claim it was unsinkable. Securing is
 > providing it power steering"

But power steering wouldn't have saved it.  By the time the iceberg was spotted, there was not enough time to turn that large a boat.  Perhaps radar, but that doesn't make a very good analogy.  Maybe a thicker tougher hull and automatic compartment doors?

-Dave





From dana at vulscan.com  Tue Jul 18 11:45:28 2006
From: dana at vulscan.com (Dana Epp)
Date: Tue, 18 Jul 2006 08:45:28 -0700
Subject: [SC-L] bumper sticker slogan for secure software
Message-ID: <9AE3FC06F0A89A43A4D6F667955082C402D358@sbsmain.Vulscan.local>

Or perhaps less arrogance in believing "it won't sink".

Absolute security is a myth. As is designing absolutely secure software.
It is a lofty goal, but one of an absolute that just isn't achievable as
threats change and new attack patterns are found. Designing secure
software is about attaining a level of balance around software
dependability weighed against mitigated risks against said software to
acceptable tolerance levels, while at the same time ensuring said
software accomplishes the original goal... to solve some problem for the
user. 

On my office door is a bumper sticker I made. It simply says:

0x5

10 points to the first person to explain what that means. 


Regards,
Dana Epp 
[Microsoft Security MVP]
http://silverstr.ufies.org/blog/

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of SC-L Subscriber Dave
Aronson
Sent: Tuesday, July 18, 2006 7:53 AM
To: SC-L at securecoding.org
Subject: [SC-L] bumper sticker slogan for secure software

Paolo Perego [mailto:thesp0nge at gmail.com] writes:

 > "Software is like Titanic, pleople claim it was unsinkable. Securing
is  > providing it power steering"

But power steering wouldn't have saved it.  By the time the iceberg was
spotted, there was not enough time to turn that large a boat.  Perhaps
radar, but that doesn't make a very good analogy.  Maybe a thicker
tougher hull and automatic compartment doors?

-Dave




_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


From massimo at grandmedia.si  Tue Jul 18 12:56:53 2006
From: massimo at grandmedia.si (...)
Date: Tue, 18 Jul 2006 18:56:53 +0200
Subject: [SC-L] bumper sticker slogan for secure software
References: <W41365597693261153141655@webmail2>
Message-ID: <014d01c6aa8b$2bc22e40$c1b13405@pitgroup.local>

well...
there's no possible definition...
unless programmers start thinking and acting in another way, and who 
commissions the software respect and pays for the real value of it, and 
users understand the value,

Secure Software is an Oxymoron


(there may be a reason why this has "moron" inside......) 



From vanderaj at greebo.net  Tue Jul 18 13:17:49 2006
From: vanderaj at greebo.net (Andrew van der Stock)
Date: Wed, 19 Jul 2006 03:17:49 +1000
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <9AE3FC06F0A89A43A4D6F667955082C402D358@sbsmain.Vulscan.local>
References: <9AE3FC06F0A89A43A4D6F667955082C402D358@sbsmain.Vulscan.local>
Message-ID: <E3904018-8198-4F4E-AC16-958C9F547ADA@greebo.net>

Best for older cars...
"My other car is a bit more secure"

Best for Volvos (or pick another high safety brand):
"I wish my finance systems are as safe as this car"

"Honk if you want secure software"

"Who has your data? Ask for secure software next time"

thanks,
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2234 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060719/b049ee0f/attachment.bin 

From wietse at porcupine.org  Tue Jul 18 13:28:01 2006
From: wietse at porcupine.org (Wietse Venema)
Date: Tue, 18 Jul 2006 13:28:01 -0400 (EDT)
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <9AE3FC06F0A89A43A4D6F667955082C402D358@sbsmain.Vulscan.local>
	"from Dana Epp at Jul 18, 2006 08:45:28 am"
Message-ID: <20060718172801.D9C12BC099@spike.porcupine.org>

Dana Epp:
> Or perhaps less arrogance in believing "it won't sink".

Absolutely. Here's my $0.02:

	secure software fails safely

Any non-trivial piece of software has defects. My challenge is not
to eliminate the last defect, but to make the system safe to use
(for some appropriate definition of safe) in the presence of defects.

	Wietse

From michaelslists at gmail.com  Tue Jul 18 20:59:35 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Wed, 19 Jul 2006 10:59:35 +1000
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <9AE3FC06F0A89A43A4D6F667955082C402D358@sbsmain.Vulscan.local>
References: <9AE3FC06F0A89A43A4D6F667955082C402D358@sbsmain.Vulscan.local>
Message-ID: <5e01c29a0607181759x13d531f4n95972f5b60c189d2@mail.gmail.com>

On 7/19/06, Dana Epp <dana at vulscan.com> wrote:
> Or perhaps less arrogance in believing "it won't sink".
>
> Absolute security is a myth.

no it isn't. pretending it is a 'myth' is an attempt by sloppy
programmers and designers to explain away the reasons for their
applications failing.


> As is designing absolutely secure software.
> It is a lofty goal, but one of an absolute that just isn't achievable as
> threats change and new attack patterns are found. Designing secure
> software is about attaining a level of balance around software
> dependability weighed against mitigated risks against said software to
> acceptable tolerance levels, while at the same time ensuring said
> software accomplishes the original goal... to solve some problem for the
> user.
>
> On my office door is a bumper sticker I made. It simply says:
>
> 0x5
>
> 10 points to the first person to explain what that means.

security 101?

-- mic

From pmeunier at cerias.purdue.edu  Wed Jul 19 10:07:23 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Wed, 19 Jul 2006 10:07:23 -0400
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <9AE3FC06F0A89A43A4D6F667955082C402D358@sbsmain.Vulscan.local>
Message-ID: <C0E3B4DB.13DE2%pmeunier@cerias.purdue.edu>




On 7/18/06 11:45 AM, "Dana Epp" <dana at vulscan.com> wrote:

> Or perhaps less arrogance in believing "it won't sink".
> 
> Absolute security is a myth. As is designing absolutely secure software.

I have high hopes in formal methods.

> It is a lofty goal, but one of an absolute that just isn't achievable as
> threats change and new attack patterns are found. Designing secure
> software is about attaining a level of balance around software
> dependability weighed against mitigated risks against said software to
> acceptable tolerance levels, while at the same time ensuring said
> software accomplishes the original goal... to solve some problem for the
> user. 
> 
> On my office door is a bumper sticker I made. It simply says:
> 
> 0x5
> 
> 10 points to the first person to explain what that means.

Since you're at Microsoft I'll bet it's related to "RPC Layer returned error
0x5 (Access is denied.) This may happen if host security is not installed".
http://support.microsoft.com/kb/216558/en-us

So it would be an oblique way of referring to host security.  If it was on a
motel-style door-handle card it could also mean "do not disturb" (send
visitors away with an "access denied").  Perhaps, "go away if you haven't
secured your system".  Who knows besides you ;)

Pascal

> 
> 
> Regards,
> Dana Epp 
> [Microsoft Security MVP]
> http://silverstr.ufies.org/blog/
> 
> -----Original Message-----
> From: sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of SC-L Subscriber Dave
> Aronson
> Sent: Tuesday, July 18, 2006 7:53 AM
> To: SC-L at securecoding.org
> Subject: [SC-L] bumper sticker slogan for secure software
> 
> Paolo Perego [mailto:thesp0nge at gmail.com] writes:
> 
>> "Software is like Titanic, pleople claim it was unsinkable. Securing
> is  > providing it power steering"
> 
> But power steering wouldn't have saved it.  By the time the iceberg was
> spotted, there was not enough time to turn that large a boat.  Perhaps
> radar, but that doesn't make a very good analogy.  Maybe a thicker
> tougher hull and automatic compartment doors?
> 
> -Dave
> 
> 
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 



From vanderaj at greebo.net  Wed Jul 19 10:45:25 2006
From: vanderaj at greebo.net (Andrew van der Stock)
Date: Thu, 20 Jul 2006 00:45:25 +1000
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <5e01c29a0607181759x13d531f4n95972f5b60c189d2@mail.gmail.com>
References: <9AE3FC06F0A89A43A4D6F667955082C402D358@sbsmain.Vulscan.local>
	<5e01c29a0607181759x13d531f4n95972f5b60c189d2@mail.gmail.com>
Message-ID: <E8882F47-BC69-4570-A249-BB781E2DE96A@greebo.net>

Actually, it is a myth.

For every non-trivial system, there are business pressures on  
resourcing, deadlines, and acceptable quality (pick any two). Once a  
business has set their taste for risk, it makes no sense to spend say  
$10m on security controls on a product and delay it for six months  
which may only bring in $2m in revenue in total, or none at all if  
the company runs out of money to bring it to market.

At the moment, most companies neither accept or assign the risk,  
enumerate the risk correctly, nor take adequate steps to eliminate as  
much risk as possible. We need to improve all three aspects. Even in  
a perfect world, there will still be bugs and security defects. Let's  
make sure that the remaining ones are really hard to exploit, and  
when the exploit happens, not much loss occurs.

thanks,
Andrew

On 19/07/2006, at 10:59 AM, mikeiscool wrote:

>> Absolute security is a myth.
>
> no it isn't. pretending it is a 'myth' is an attempt by sloppy
> programmers and designers to explain away the reasons for their
> applications failing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2234 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060720/a1a1e54b/attachment.bin 

From leichter_jerrold at emc.com  Wed Jul 19 10:30:48 2006
From: leichter_jerrold at emc.com (leichter_jerrold at emc.com)
Date: Wed, 19 Jul 2006 10:30:48 -0400
Subject: [SC-L] Resource limitation
Message-ID: <Pine.SOL.4.61.0607191014520.20979@mental>

| > I was recently looking at some code to do regular expression
| > matching, when it occurred to me that one can produce fairly small
| > regular expressions that require huge amounts of space and time.
| > There's nothing in the slightest bit illegal about such regexp's -
| > it's just inherent in regular expressions that such things exist.
| 
| Yeah... the set of regular languages is big. And, some have pretty
| pathological FSM representations.
| 
| > In addition, the kinds of resources that you can exhaust this way is
| > broader than you'd first guess.  Memory is obvious; overrunning a
| > thread stack is perhaps less so.  ... How about file descriptors?
| > File space? Available transmission capacity for a variety of kinds
| > of connections?
| >
| 
| One place to look is capability systems. They're more flexible and
| should have all the features you want, 
Capability systems I've seen have Boolean capabilities.  I agree
that one could, in principle, extend the notion to include resource
limits - but that adds complexity.

|					 but are still largely
| theoretical.
...for an interesting notion of "still".  Capability systems have been
around for 30 years.  They've been implemented repeatedly.  But they
haven't actually succeeded in any meaningful sense anywhere.  The
problem doesn't seem to be capabilities as such - it's the management
of them, which is way too complex.  Great research area....

BTW, as an example of the additional complexity in going from binary
capabilities to resource limits:  If I have a capability, I may
or may not be able to grant it to another actor (keeping it for
myself as well); and I may or may not be able to *transfer* it to
another actor.  With resources, can I have to split my resources
with, say, the subprocesses I create?  Can I start them with the
same resources I have?  Can I pool mine with theirs?  If I have
to split them, is there some way of moving the resources around
later?  (VMS has OS-enforced resources, and has different catagories
of them along these lines.  It's been too long and I don't even
remember the catagories or examples for certain, but things like
"total memory used" are pooled, others are split, and yet others
are simply copied.)

There's a recent research programming language whose name escapes me at
the moment that fully integrates capabilities with the language itself.
Nice work - it was used in a demo of a multi-level secure Web browser or
some such thing recently.  What I don't recall is whether they do
resource control as well.

|     http://en.wikipedia.org/wiki/Capability-based_security
| 
| 
| That said, every decent Unix system I'm aware of has ulimit, which you
| can use to restrict virtual memory allocations, total open files, etc:
| 
|     nash @ quack% ulimit -a
|     ...
|     virtual memory        (kbytes, -v) unlimited
| 
|     nash @ quack% ulimit -v 1024 # just 1M RAM, this'll be fun :-)
| 
|     nash @ quack% ( find * )
|     find: error while loading shared libraries: libc.so.6: failed to map
|     segment from shared object: Cannot allocate memory
...missing the point entirely.  Take a multithreaded server.  Apply a
strict ulimit.  Voila - simple denial of service attack:  It's now
easy for any thread to exhaust available VM, crashing the entire
application.

Thanks, but no thanks.

| 
| Alternately, you can implement your own allocator library for your
| application and then impose per-thread limits using that library. How
| you do that is going to depend alot on the language. Obviously, there
| are lots for C/C++ floating around.
(a) Who said anything about per-*thread* limits?  (b) Even if it is
a per-thread limit, what happens when memory is transfered from thread
to thread; (c) having been there ... you grossly underestimate the
difficulty of "implement[ing] your own allocator library", at least
if performance matters to you.

|     http://en.wikipedia.org/wiki/Memory_allocation
| 
| In Java, you don't get nice knobs on Objects and Threads, but you get
| several nice knobs on the VM itself: -Xm, -XM, etc. 
The moral equivalent of ulimit.

|						      Other high level
| languages have similar problems to Java. I.e., how do you abstract the
| "size" of a thing when you don't give access to memory as a flat byte
| array? Well, you can do lots of fun things using LIFO queues, or LRU
| caches, and so forth. There are performance impacts to consider, but
| they you can often tweak things so it sucks primarily for the abuser.
| 
| None of these is really that hard to implement. So, do we really need
| new theory for this? Dunno. One's mileage does vary.
Well, based on what you've proposed ... yes, we're seriously lacking in
both theory and implementation.
							-- Jerry

| -nash
| 
| -- 
| 
| "the lyf so short, the craft so long to lerne."
|                     - Geoffrey Chaucer
| 

From mouse at Rodents.Montreal.QC.CA  Wed Jul 19 11:22:01 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Wed, 19 Jul 2006 11:22:01 -0400 (EDT)
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <C0E3B4DB.13DE2%pmeunier@cerias.purdue.edu>
References: <C0E3B4DB.13DE2%pmeunier@cerias.purdue.edu>
Message-ID: <200607191525.LAA11582@Sparkle.Rodents.Montreal.QC.CA>

>> Absolute security is a myth.  As is designing absolutely secure
>> software.

> I have high hopes in formal methods.

All formal methods do is push bugs around.  Basically, you end up
writing in a higher-level language (the spec you are formally verifying
the program meets).  You are then subject to the bugs present in *that*
"program" (the spec) and the bugs present in the "compiler" (the formal
verifier).

Formal methods are a useful tool, and have a place.  But they are not a
magic bullet.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From michaelslists at gmail.com  Wed Jul 19 18:53:22 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Thu, 20 Jul 2006 08:53:22 +1000
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <E8882F47-BC69-4570-A249-BB781E2DE96A@greebo.net>
References: <9AE3FC06F0A89A43A4D6F667955082C402D358@sbsmain.Vulscan.local>
	<5e01c29a0607181759x13d531f4n95972f5b60c189d2@mail.gmail.com>
	<E8882F47-BC69-4570-A249-BB781E2DE96A@greebo.net>
Message-ID: <5e01c29a0607191553o62e16598lb647c332df9324c2@mail.gmail.com>

On 7/20/06, Andrew van der Stock <vanderaj at greebo.net> wrote:
> Actually, it is a myth.
>
> For every non-trivial system, there are business pressures on
> resourcing, deadlines, and acceptable quality (pick any two). Once a
> business has set their taste for risk, it makes no sense to spend say
> $10m on security controls on a product and delay it for six months
> which may only bring in $2m in revenue in total, or none at all if
> the company runs out of money to bring it to market.
>
> At the moment, most companies neither accept or assign the risk,
> enumerate the risk correctly, nor take adequate steps to eliminate as
> much risk as possible. We need to improve all three aspects. Even in
> a perfect world, there will still be bugs and security defects. Let's
> make sure that the remaining ones are really hard to exploit, and
> when the exploit happens, not much loss occurs.

yeah.

but none of this changes the fact that it IS possible to write
completely secure code.


> thanks,
> Andrew

-- mic

From dana at vulscan.com  Thu Jul 20 10:49:03 2006
From: dana at vulscan.com (Dana Epp)
Date: Thu, 20 Jul 2006 07:49:03 -0700
Subject: [SC-L] bumper sticker slogan for secure software
Message-ID: <9AE3FC06F0A89A43A4D6F667955082C402D361@sbsmain.Vulscan.local>

> yeah.
> but none of this changes the fact that it IS possible to write
completely secure code.
> -- mic

And it IS possible that a man will walk on Mars someday. But its not
practical or realistic in the society we live in today. I'm sorry mic,
but I have to disagree with you here.

It is EXTREMELY difficult to have code be 100% correct if an application
has any level of real use or complexity. There will be security defects.
The weakest link here is the human factor, and people make mistakes.
More importantly, threats are constantly evolving and what you may
consider completely secure today may not be tomorrow when a new attack
vector is recognized that may attack your software. And unless you wrote
every single line of code yourself without calling out to ANY libraries,
you cannot rely on the security of other libraries or components that
may NOT have the same engineering discipline that you may have on your
own code base. 

Ross Anderson once said that secure software engineering is about
building systems to remain dependable in the face of malice, error, or
mischance. I think he has something there. If we build systems to
maintain confidentiality, integrity and availability, we have the
ability to fail gracefully in a manner to recover from unknown or
changing problems in our software without being detrimental to the user,
or their data.

I don't think we should ever stop striving to reach secure coding
nirvana. But I also understand that in the real world we are still in
our infancy when it comes to secure software as a discipline, and we
still have much to learn before we will reach it. 


Regards,
Dana Epp
[Microsoft Security MVP]
http://silverstr.ufies.org/blog/


From gem at cigital.com  Thu Jul 20 12:18:34 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 20 Jul 2006 12:18:34 -0400
Subject: [SC-L] bumper sticker slogan for secure software
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB74271A@va-mail.cigital.com>

And don't forget about the compiler you will no doubt have to use.  Do you trust that?

You might want to read Thompson's classic "reflections on trusting trust".  www.acm.org/classics/sep95

All your compilers are belong to us.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com


 -----Original Message-----
From: 	Dana Epp [mailto:dana at vulscan.com]
Sent:	Thu Jul 20 12:14:54 2006
To:	Andrew van der Stock
Cc:	SC-L at securecoding.org
Subject:	Re: [SC-L] bumper sticker slogan for secure software

> yeah.
> but none of this changes the fact that it IS possible to write
completely secure code.
> -- mic

And it IS possible that a man will walk on Mars someday. But its not
practical or realistic in the society we live in today. I'm sorry mic,
but I have to disagree with you here.

It is EXTREMELY difficult to have code be 100% correct if an application
has any level of real use or complexity. There will be security defects.
The weakest link here is the human factor, and people make mistakes.
More importantly, threats are constantly evolving and what you may
consider completely secure today may not be tomorrow when a new attack
vector is recognized that may attack your software. And unless you wrote
every single line of code yourself without calling out to ANY libraries,
you cannot rely on the security of other libraries or components that
may NOT have the same engineering discipline that you may have on your
own code base. 

Ross Anderson once said that secure software engineering is about
building systems to remain dependable in the face of malice, error, or
mischance. I think he has something there. If we build systems to
maintain confidentiality, integrity and availability, we have the
ability to fail gracefully in a manner to recover from unknown or
changing problems in our software without being detrimental to the user,
or their data.

I don't think we should ever stop striving to reach secure coding
nirvana. But I also understand that in the real world we are still in
our infancy when it comes to secure software as a discipline, and we
still have much to learn before we will reach it. 


Regards,
Dana Epp
[Microsoft Security MVP]
http://silverstr.ufies.org/blog/

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From fw at deneb.enyo.de  Thu Jul 20 11:54:33 2006
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 20 Jul 2006 17:54:33 +0200
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <17EF6F3064F79040A085A09975A8595305B7F5CC@ex2k.bankofamerica.com>
	(Brian A. Shea's message of "Mon, 17 Jul 2006 08:57:55 -0700")
References: <17EF6F3064F79040A085A09975A8595305B7F5CC@ex2k.bankofamerica.com>
Message-ID: <87lkqop8zq.fsf@mid.deneb.enyo.de>

* Brian A. Shea:

> My slogan:
>
> Unsecured Applications = Unsecured Business

Which is completely acceptable if you and your business partners are
aware of the risk level at which your are running your company.

Secure software costs more, requires more user training, and fails in
hard-to-understand patterns.  If you really need it, you lose.

From fw at deneb.enyo.de  Thu Jul 20 11:58:35 2006
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 20 Jul 2006 17:58:35 +0200
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <200607191525.LAA11582@Sparkle.Rodents.Montreal.QC.CA> (der
	Mouse's message of "Wed, 19 Jul 2006 11:22:01 -0400 (EDT)")
References: <C0E3B4DB.13DE2%pmeunier@cerias.purdue.edu>
	<200607191525.LAA11582@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <87hd1cp8t0.fsf@mid.deneb.enyo.de>

* der Mouse:

>>> Absolute security is a myth.  As is designing absolutely secure
>>> software.
>
>> I have high hopes in formal methods.
>
> All formal methods do is push bugs around.  Basically, you end up
> writing in a higher-level language (the spec you are formally verifying
> the program meets).  You are then subject to the bugs present in *that*
> "program" (the spec) and the bugs present in the "compiler" (the formal
> verifier).

But people are forced to spend more time with the code, which
generally helps them (in particular smart people) to eradicate bugs.
Another way to achieve the same thing is to freeze the code base and
let it mature over decades, but I don't see the business model for
that.

From Kevin.Wall at qwest.com  Thu Jul 20 12:58:48 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Thu, 20 Jul 2006 11:58:48 -0500
Subject: [SC-L] bumper sticker slogan for secure software
Message-ID: <CF8B26B8B49184429CB084616B0019300244E719@itomae2km05.AD.QINTRA.COM>

Dana,

Regarding your remarks about writing perfectly secure code...
well put.

And your remarks about Ross Anderson...

> Ross Anderson once said that secure software engineering is about
> building systems to remain dependable in the face of malice, error,
> or mischance. I think he has something there. If we build systems
> to maintain confidentiality, integrity and availability, we have the
> ability to fail gracefully in a manner to recover from unknown or
> changing problems in our software without being detrimental to
> the user, or their data.

remined me of Anderson and Ralph Needham coining the phrase
(hope I'm getting this right) that "security is like programming
Satan's computer" in the sense that you have an evil extremely
intelligent adversary with unlimited resources and time, etc.
[http://www.cl.cam.ac.uk/ftp/users/rja14/satan.pdf]

So there's a bumper sticker for you:

	Security: programming Satan's computer

Of course, it's likely to be misunderstood by most.
(Maybe we could attribute it to SNL's "church lady".
Sorry Ross. ;-)

BTW, does anyone besides me think that it's time to put
this thread to rest?

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.


From ge at linuxbox.org  Thu Jul 20 13:28:31 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Thu, 20 Jul 2006 12:28:31 -0500 (CDT)
Subject: [SC-L] Google Auditing
Message-ID: <Pine.LNX.4.21.0607201226450.26518-100000@linuxbox.org>

Hi guys!

A few days ago, following the announcements by Dan from Websense and then
HD, I wrote a post covering what they have done and what the future may
gold for Google hacking for security purposes.

http://blogs.securiteam.com/index.php/archives/513

Today a guy posted a blog on using the filetype: feature to find coding
errors:
http://www.cipher.org.uk/index.php?p=projects/bugle.project

	Gadi.
	


From pmeunier at cerias.purdue.edu  Thu Jul 20 13:36:52 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Thu, 20 Jul 2006 13:36:52 -0400
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <87hd1cp8t0.fsf@mid.deneb.enyo.de>
Message-ID: <C0E53774.13E5E%pmeunier@cerias.purdue.edu>



On 7/20/06 11:58 AM, "Florian Weimer" <fw at deneb.enyo.de> wrote:

> * der Mouse:
> 
>>>> Absolute security is a myth.  As is designing absolutely secure
>>>> software.
>> 
>>> I have high hopes in formal methods.
>> 
>> All formal methods do is push bugs around.  Basically, you end up
>> writing in a higher-level language (the spec you are formally verifying
>> the program meets).  You are then subject to the bugs present in *that*
>> "program" (the spec) and the bugs present in the "compiler" (the formal
>> verifier).
> 
> But people are forced to spend more time with the code, which
> generally helps them (in particular smart people) to eradicate bugs.
> Another way to achieve the same thing is to freeze the code base and
> let it mature over decades, but I don't see the business model for
> that.

Also, writing it twice with different languages, especially at different
levels of abstraction, makes it less likely that the same bugs will appear
in both.  You can choose the higher level language so that it has great
expressive power exactly for the things that are a pain to capture and
verify (and thus a source of bugs) in the lower-level language.  Last time I
checked, formal methods were even able to catch design errors in some
networking protocols.  But you're right, they are not absolutely perfect
because the tools and operators aren't, etc...  That doesn't mean they can't
help a great deal.  I have great hopes for their usefulness.  Maybe some day
they will help so much that the distinction between what they can produce
and absolutely secure software will become too small to matter.  Whether
we'll still be alive when that happens is another question.

Pascal




From gem at cigital.com  Thu Jul 20 13:57:26 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 20 Jul 2006 13:57:26 -0400
Subject: [SC-L] bumper sticker slogan for secure software
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB742727@va-mail.cigital.com>

I'm afraid that's not true.  John Knight has a famous paper that shows that design/requirements bugs persist in n-version programming paradigms.  I'll let the interested people google that one up for themselves.

gem

company www.cigital.com.
podcast www.cigital.com/silverbullet
book www.swsec.com

 -----Original Message-----
From: 	Pascal Meunier [mailto:pmeunier at cerias.purdue.edu]
Sent:	Thu Jul 20 13:54:42 2006
To:	Florian Weimer; der Mouse
Cc:	SC-L at securecoding.org
Subject:	Re: [SC-L] bumper sticker slogan for secure software



On 7/20/06 11:58 AM, "Florian Weimer" <fw at deneb.enyo.de> wrote:

> * der Mouse:
> 
>>>> Absolute security is a myth.  As is designing absolutely secure
>>>> software.
>> 
>>> I have high hopes in formal methods.
>> 
>> All formal methods do is push bugs around.  Basically, you end up
>> writing in a higher-level language (the spec you are formally verifying
>> the program meets).  You are then subject to the bugs present in *that*
>> "program" (the spec) and the bugs present in the "compiler" (the formal
>> verifier).
> 
> But people are forced to spend more time with the code, which
> generally helps them (in particular smart people) to eradicate bugs.
> Another way to achieve the same thing is to freeze the code base and
> let it mature over decades, but I don't see the business model for
> that.

Also, writing it twice with different languages, especially at different
levels of abstraction, makes it less likely that the same bugs will appear
in both.  You can choose the higher level language so that it has great
expressive power exactly for the things that are a pain to capture and
verify (and thus a source of bugs) in the lower-level language.  Last time I
checked, formal methods were even able to catch design errors in some
networking protocols.  But you're right, they are not absolutely perfect
because the tools and operators aren't, etc...  That doesn't mean they can't
help a great deal.  I have great hopes for their usefulness.  Maybe some day
they will help so much that the distinction between what they can produce
and absolutely secure software will become too small to matter.  Whether
we'll still be alive when that happens is another question.

Pascal



_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From jet at flatline.net  Thu Jul 20 14:04:46 2006
From: jet at flatline.net (j eric townsend)
Date: Thu, 20 Jul 2006 14:04:46 -0400
Subject: [SC-L] code review tools for tcl?
In-Reply-To: <5e01c29a0607191553o62e16598lb647c332df9324c2@mail.gmail.com>
References: <9AE3FC06F0A89A43A4D6F667955082C402D358@sbsmain.Vulscan.local>
	<5e01c29a0607181759x13d531f4n95972f5b60c189d2@mail.gmail.com>
	<E8882F47-BC69-4570-A249-BB781E2DE96A@greebo.net>
	<5e01c29a0607191553o62e16598lb647c332df9324c2@mail.gmail.com>
Message-ID: <p0623093dc0e5698f5c64@[10.0.1.25]>

I've been asked to review some tcl code that works on data from untrusted sources.  I've dabbled in tcl a couple of times, but don't consider myself any sort of expert and I'm looking for a bit of automated help.

Anyone know of a tool like rats, its4, or codeassure that works on tcl source, or pointers to advice on secure development in tcl?   

thx,
--jet
-- 
jet / KG6ZVQ
http://www.flatline.net
pgp:   0xD0D8C2E8  AC9B 0A23 C61A 1B4A 27C5  F799 A681 3C11 D0D8 C2E8

From BlueBoar at thievco.com  Thu Jul 20 14:54:02 2006
From: BlueBoar at thievco.com (Blue Boar)
Date: Thu, 20 Jul 2006 11:54:02 -0700
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB74271A@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB74271A@va-mail.cigital.com>
Message-ID: <44BFD14A.4070704@thievco.com>

Gary McGraw wrote:
> And don't forget about the compiler you will no doubt have to use.  Do you trust that?
> 
> You might want to read Thompson's classic "reflections on trusting trust".  www.acm.org/classics/sep95
> 
> All your compilers are belong to us.

While that is always a good read, I'm not so sure it's that relevant 
anymore.  There is a LOT of binary analysis going on these days.

					BB

From fw at deneb.enyo.de  Thu Jul 20 15:11:29 2006
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 20 Jul 2006 21:11:29 +0200
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <C0E53774.13E5E%pmeunier@cerias.purdue.edu> (Pascal Meunier's
	message of "Thu, 20 Jul 2006 13:36:52 -0400")
References: <C0E53774.13E5E%pmeunier@cerias.purdue.edu>
Message-ID: <874pxcks66.fsf@mid.deneb.enyo.de>

* Pascal Meunier:

> Also, writing it twice with different languages, especially at different
> levels of abstraction, makes it less likely that the same bugs will appear
> in both.

Algorithmic issues such as denial of service attacks through
unbalanced binary trees or hash table collisions are pretty
independent of the programming language and have been observed in many
incarnations.

If you implement the same protocol, it's likely that you end up with
similar bugs.  The DNS compression loop bug was reinvented many times.
The fundamental mismatch in OpenPGP between key certification (key
plus user ID) and key usage (just the key alone) affected many
independently developed implementations.  Chrome spoofing is
ubiquitous in web browsers.  

Most things in this list are implemented in C or C++, but the problems
are at such a high level that it's unlikely that a different choice of
wildly different programming language would make a huge difference.
If you look at lower-level bugs, such as buffer overflows, I hope that
nobody still thinks that multiple code versions help -- just look at
the long list (even after discounting direct code copies) of botched
ASN.1 decoders.

Some protocols are extremly hard to implement correctly, I'm afraid.
(And not all protocols are unnecessarily complex.)

From pmeunier at cerias.purdue.edu  Thu Jul 20 15:11:06 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Thu, 20 Jul 2006 15:11:06 -0400
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB742727@va-mail.cigital.com>
Message-ID: <C0E54D8A.13E6F%pmeunier@cerias.purdue.edu>



On 7/20/06 1:57 PM, "Gary McGraw" <gem at cigital.com> wrote:

> I'm afraid that's not true.  John Knight has a famous paper that shows that
> design/requirements bugs persist in n-version programming paradigms.  I'll let
> the interested people google that one up for themselves.
> 
> gem

But it's true for stupid bugs like buffer overflows and format string
vulnerabilities, in which we're still swimming, and the proof is the fact
that those aren't possible in some languages.  For design/requirements bugs,
I'm reading:

Why Are Formal Methods Not Used More Widely?
John C. Knight Colleen L. DeJong Matthew S. Gibble Lu?s G. Nakano
Department of Computer Science
University of Virginia
Charlottesville, VA 22903

http://www.cs.virginia.edu/~jck/publications/lfm.97.pdf

and the evidence is that engineers presented with formal specifications were
able to spot many design errors ("Validation by inspection was effective").
Therefore if you have a formal, high-level version it can be validated
better, and formal methods give proof that the lower-level code conforms.

I call that all-around better, and I'm hoping for more of it and better ways
to do it.  Now if you order a cat and needed a dog, nobody can help you.

Pascal


> 
>  -----Original Message-----
> From:  Pascal Meunier [mailto:pmeunier at cerias.purdue.edu]
> Sent: Thu Jul 20 13:54:42 2006
> To: Florian Weimer; der Mouse
> Cc: SC-L at securecoding.org
> Subject: Re: [SC-L] bumper sticker slogan for secure software
> 
> 
> 
> On 7/20/06 11:58 AM, "Florian Weimer" <fw at deneb.enyo.de> wrote:
> 
>> * der Mouse:
>> 
>>>>> Absolute security is a myth.  As is designing absolutely secure
>>>>> software.
>>> 
>>>> I have high hopes in formal methods.
>>> 
>>> All formal methods do is push bugs around.  Basically, you end up
>>> writing in a higher-level language (the spec you are formally verifying
>>> the program meets).  You are then subject to the bugs present in *that*
>>> "program" (the spec) and the bugs present in the "compiler" (the formal
>>> verifier).
>> 
>> But people are forced to spend more time with the code, which
>> generally helps them (in particular smart people) to eradicate bugs.
>> Another way to achieve the same thing is to freeze the code base and
>> let it mature over decades, but I don't see the business model for
>> that.
> 
> Also, writing it twice with different languages, especially at different
> levels of abstraction, makes it less likely that the same bugs will appear
> in both.  You can choose the higher level language so that it has great
> expressive power exactly for the things that are a pain to capture and
> verify (and thus a source of bugs) in the lower-level language.  Last time I
> checked, formal methods were even able to catch design errors in some
> networking protocols.  But you're right, they are not absolutely perfect
> because the tools and operators aren't, etc...  That doesn't mean they can't
> help a great deal.  I have great hopes for their usefulness.  Maybe some day
> they will help so much that the distinction between what they can produce
> and absolutely secure software will become too small to matter.  Whether
> we'll still be alive when that happens is another question.
> 
> Pascal
> 
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 




From leichter_jerrold at emc.com  Thu Jul 20 15:33:30 2006
From: leichter_jerrold at emc.com (leichter_jerrold at emc.com)
Date: Thu, 20 Jul 2006 15:33:30 -0400
Subject: [SC-L] bumper sticker slogan for secure software
Message-ID: <Pine.SOL.4.61.0607201531110.20979@mental>

| >>>> Absolute security is a myth.  As is designing absolutely secure
| >>>> software.
| >> 
| >>> I have high hopes in formal methods.
| >> 
| >> All formal methods do is push bugs around...
| > 
| > But people are forced to spend more time with the code, which
| > generally helps them (in particular smart people) to eradicate bugs....
| 
| Also, writing it twice with different languages, especially at different
| levels of abstraction, makes it less likely that the same bugs will appear
| in both.  You can choose the higher level language so that it has great
| expressive power exactly for the things that are a pain to capture and
| verify (and thus a source of bugs) in the lower-level language....
But always keep in mind a comment (allegedly, I've never actually
seen this) present at the top of something Don Knuth wrote:

	Be careful with this code.  I've only proved
	it correct, not actually tested it.

If Don Knuth can say that about code, the rest of us should be very
humble about our correctness proofs.
							-- Jerry

From fw at deneb.enyo.de  Thu Jul 20 15:46:22 2006
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 20 Jul 2006 21:46:22 +0200
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <C0E54D8A.13E6F%pmeunier@cerias.purdue.edu> (Pascal Meunier's
	message of "Thu, 20 Jul 2006 15:11:06 -0400")
References: <C0E54D8A.13E6F%pmeunier@cerias.purdue.edu>
Message-ID: <87lkqojbzl.fsf@mid.deneb.enyo.de>

* Pascal Meunier:

> But it's true for stupid bugs like buffer overflows and format string
> vulnerabilities, in which we're still swimming, and the proof is the fact
> that those aren't possible in some languages.

Could you name a few such language implementations? 8-)

In most cases, the components that enforces the absence of buffer
overflows are written in C.  In other cases, languages have the
reputation of being free from buffer overflows although it's just not
true: You can create a fully conforming Common Lisp implementation
where code injection through buffer overflows is possible.  On the
other hand, it's possible to construct an ISO C implementation where
accessing memory beyond the end of a buffer is equivalent to calling
abort. (Such CL implementations are very common, but the C
implementatins aren't because they would feature a very unusual ABI or
suffer from poor performance.)

And you need to keep in mind that even with C, we are close to turning
buffer overflows into completely reproducible crashes.  This is not so
much different from supposedly safer programming languages where an
exception is raised in such cases.  The exception can be handled,
sure, but if it is truly unexpected, your system will fail.

>  For design/requirements bugs, I'm reading:

Safety-critical software is a very different beast.  You can make much
stronger assumptions about the environment.  It's not clear if the
results apply to software security in open system.

I'm not saying that formal methods have no value.  But I doubt that
comparisons with projects at completely different
dollars-per-line-of-code levels give immediate insights.

From pmeunier at cerias.purdue.edu  Thu Jul 20 16:03:01 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Thu, 20 Jul 2006 16:03:01 -0400
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <874pxcks66.fsf@mid.deneb.enyo.de>
Message-ID: <C0E559B5.13E7B%pmeunier@cerias.purdue.edu>




On 7/20/06 3:11 PM, "Florian Weimer" <fw at deneb.enyo.de> wrote:

> * Pascal Meunier:
> 
>> Also, writing it twice with different languages, especially at different
>> levels of abstraction, makes it less likely that the same bugs will appear
>> in both.
> 
> Algorithmic issues such as denial of service attacks through
> unbalanced binary trees or hash table collisions are pretty
> independent of the programming language and have been observed in many
> incarnations.
> 
> If you implement the same protocol, it's likely that you end up with
> similar bugs.  The DNS compression loop bug was reinvented many times.
> The fundamental mismatch in OpenPGP between key certification (key
> plus user ID) and key usage (just the key alone) affected many
> independently developed implementations.  Chrome spoofing is
> ubiquitous in web browsers.
> 
> Most things in this list are implemented in C or C++, but the problems
> are at such a high level that it's unlikely that a different choice of
> wildly different programming language would make a huge difference.
> If you look at lower-level bugs, such as buffer overflows, I hope that
> nobody still thinks that multiple code versions help -- just look at
> the long list (even after discounting direct code copies) of botched
> ASN.1 decoders.
> 
> Some protocols are extremly hard to implement correctly, I'm afraid.
> (And not all protocols are unnecessarily complex.)
> 

It's obvious that if you just translate a bad, complicated algorithm or
protocol from one language to the next, they'll all be bad.  It remains that
sometimes when you make people say something stupid twice they catch on the
second time, especially during code reviews, because they re-express the
code using natural language.  That's why I said, "less likely".  It works
with some and not others.

Pascal



From ljknews at mac.com  Thu Jul 20 16:20:07 2006
From: ljknews at mac.com (ljknews)
Date: Thu, 20 Jul 2006 16:20:07 -0400
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <874pxcks66.fsf@mid.deneb.enyo.de>
References: <C0E53774.13E5E%pmeunier@cerias.purdue.edu>
	<874pxcks66.fsf@mid.deneb.enyo.de>
Message-ID: <p05200f14c0e595c4ae4d@[192.168.1.254]>

At 9:11 PM +0200 7/20/06, Florian Weimer wrote:

> Most things in this list are implemented in C or C++, but the problems
> are at such a high level that it's unlikely that a different choice of
> wildly different programming language would make a huge difference.
> If you look at lower-level bugs, such as buffer overflows, I hope that
> nobody still thinks that multiple code versions help

It helps so long as some of the languages chosen are those immune to
buffer overflows.
-- 
Larry Kilgallen

From pmeunier at cerias.purdue.edu  Thu Jul 20 16:28:07 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Thu, 20 Jul 2006 16:28:07 -0400
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <87lkqojbzl.fsf@mid.deneb.enyo.de>
Message-ID: <C0E55F97.13E7E%pmeunier@cerias.purdue.edu>




On 7/20/06 3:46 PM, "Florian Weimer" <fw at deneb.enyo.de> wrote:

> * Pascal Meunier:
> 
>> But it's true for stupid bugs like buffer overflows and format string
>> vulnerabilities, in which we're still swimming, and the proof is the fact
>> that those aren't possible in some languages.
> 
> Could you name a few such language implementations? 8-)
> 
> In most cases, the components that enforces the absence of buffer
> overflows are written in C.
<snip>

That's irrelevant.  What is important is that some magic formal tool could
say that some code in language "A", where bug of type "k" is possible, is
not equivalent to the version in language "B", where type "k" bugs are
impossible, ergo you have found a type "k" bug (in the absence of any other
bug in that section of code...).

I know someone is going to ask, "why didn't you code it only in language B
then?", to which there can be many different answers, and I don't want to
get into that.


>>  For design/requirements bugs, I'm reading:
> 
> Safety-critical software is a very different beast.  You can make much
> stronger assumptions about the environment.  It's not clear if the
> results apply to software security in open system.
> 
> I'm not saying that formal methods have no value.  But I doubt that
> comparisons with projects at completely different
> dollars-per-line-of-code levels give immediate insights.

That's one of the things I'm hoping for:  that more and better formal
methods become more affordable and practical.  Spark, for example,
demonstrated that the costs of some formal methods were much lower than what
people expected, in real projects.  That gives me hope.

Pascal

 



From ljknews at mac.com  Thu Jul 20 16:59:35 2006
From: ljknews at mac.com (ljknews)
Date: Thu, 20 Jul 2006 16:59:35 -0400
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <87lkqojbzl.fsf@mid.deneb.enyo.de>
References: <C0E54D8A.13E6F%pmeunier@cerias.purdue.edu>
	<87lkqojbzl.fsf@mid.deneb.enyo.de>
Message-ID: <p05200f16c0e59e7ebb4d@[192.168.1.254]>

At 9:46 PM +0200 7/20/06, Florian Weimer wrote:
> * Pascal Meunier:
> 
>> But it's true for stupid bugs like buffer overflows and format string
>> vulnerabilities, in which we're still swimming, and the proof is the fact
>> that those aren't possible in some languages.
>
> Could you name a few such language implementations? 8-)

Ada !

> In most cases, the components that enforces the absence of buffer
> overflows are written in C.

Not in VAX/DEC/Compaq/HP Ada, which is the one that I use.

But the "components" that enforce the absence of buffer overflows are
not written in Bliss (the language of the Ada RTL for that compiler)
either.  They are in the code that is generated, or the failure to
generate that code because the problem was caught at compile time.
-- 
Larry Kilgallen

From dana at vulscan.com  Thu Jul 20 18:44:38 2006
From: dana at vulscan.com (Dana Epp)
Date: Thu, 20 Jul 2006 15:44:38 -0700
Subject: [SC-L] bumper sticker slogan for secure software
Message-ID: <9AE3FC06F0A89A43A4D6F667955082C402D364@sbsmain.Vulscan.local>

Actually, Brian Shea got the points for emailing me that he knew it was
the system error "Access Denied".

An extra 10 points goes to Andrew van der Stock for his explaination
that:

"apparently the term originates from radio, where 5x5 means good
reception and good signal strength (in that order). So

0x5

means

- no reception ("0")
- good signal strength ("5")

ie, we're doing ok at getting our message out, but people aren't  
listening yet. "

That cracked me up. So fitting for this forum.


Regards,
Dana Epp 
[Microsoft Security MVP]
http://silverstr.ufies.org/blog/

-----Original Message-----
From: mikeiscool [mailto:michaelslists at gmail.com] 
Sent: Thursday, July 20, 2006 3:25 PM
To: Wall, Kevin
Cc: Dana Epp; SC-L at securecoding.org
Subject: Re: [SC-L] bumper sticker slogan for secure software

> BTW, does anyone besides me think that it's time to put this thread to

> rest?

I do.

But i'm still waiting for my points from dana ...


> -kevin

-- mic


From johwi at ida.liu.se  Fri Jul 21 07:15:01 2006
From: johwi at ida.liu.se (John Wilander)
Date: Fri, 21 Jul 2006 13:15:01 +0200
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <p05200f16c0e59e7ebb4d@[192.168.1.254]>
Message-ID: <200607211115.k6LBFCoW007733@portofix.ida.liu.se>

I've actually been using a secure software slogan for a few years, both in
teaching and in pitching business. It's taken from Howard and LeBlanc's
book "Writing Secure Code":

- Security features are not secure features -

The statement mesmerizes people and aguably needs a "necessarily" to be
more precise. But it's short and does the trick for me---it separates
adding security functions from trying to secure all functions in the
system (during all phases).

   Regards, John

____________________________
John Wilander, PhD Student
Computer and Information Sc.
Linkoping University, Sweden
http://www.ida.liu.se/~johwi

From michaelslists at gmail.com  Thu Jul 20 18:26:13 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Fri, 21 Jul 2006 08:26:13 +1000
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <87lkqop8zq.fsf@mid.deneb.enyo.de>
References: <17EF6F3064F79040A085A09975A8595305B7F5CC@ex2k.bankofamerica.com>
	<87lkqop8zq.fsf@mid.deneb.enyo.de>
Message-ID: <5e01c29a0607201526h78810b6ajb78d7fa92d3ab6d3@mail.gmail.com>

On 7/21/06, Florian Weimer <fw at deneb.enyo.de> wrote:
> * Brian A. Shea:
>
> > My slogan:
> >
> > Unsecured Applications = Unsecured Business
>
> Which is completely acceptable if you and your business partners are
> aware of the risk level at which your are running your company.
>
> Secure software costs more, requires more user training, and fails in
> hard-to-understand patterns.  If you really need it, you lose.

Really secure software should require _less_ user training, not more.

-- mic

From michaelslists at gmail.com  Thu Jul 20 18:48:51 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Fri, 21 Jul 2006 08:48:51 +1000
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <9AE3FC06F0A89A43A4D6F667955082C402D360@sbsmain.Vulscan.local>
References: <9AE3FC06F0A89A43A4D6F667955082C402D360@sbsmain.Vulscan.local>
Message-ID: <5e01c29a0607201548v500b1e13wc2e7ceb6787c0791@mail.gmail.com>

On 7/21/06, Dana Epp <dana at vulscan.com> wrote:
> > yeah.
> > but none of this changes the fact that it IS possible to write
> completely secure code.
> > -- mic
>
> And it IS possible that a man will walk on Mars someday. But its not
> practical or realistic in the society we live in today. I'm sorry mic,
> but I have to disagree with you here.
>
> It is EXTREMELY difficult to have code be 100% correct if an application
> has any level of real use or complexity. There will be security defects.

Why? Why accept this as a fact? It is not a fact. If you put
procedures in place and appropriately review and test you can be
confident.


> The weakest link here is the human factor, and people make mistakes.

Yes they do. So help them to stop it by teaching and testing and reviewing.


> More importantly, threats are constantly evolving and what you may
> consider completely secure today may not be tomorrow when a new attack
> vector is recognized that may attack your software.

This isn't as true and as wide spread as you make it sound. Consider,
for example, "SQL Injection". Assuming I do not upgrade my database,
and do not change my code and server (i.e. do not change my
environment at all), then if I have prevented this attack initially
nothing new will come up to suddenly make it work.

If the environment IS changed, however, then of course it's expected
that the program should be reviewed and checked again.


> And unless you wrote
> every single line of code yourself without calling out to ANY libraries,
> you cannot rely on the security of other libraries or components that
> may NOT have the same engineering discipline that you may have on your
> own code base.

Not true; you can call other libraries happily and with confidence if
you handle the case of them going all kinds of wrong.


> Ross Anderson once said that secure software engineering is about
> building systems to remain dependable in the face of malice, error, or
> mischance. I think he has something there. If we build systems to
> maintain confidentiality, integrity and availability, we have the
> ability to fail gracefully in a manner to recover from unknown or
> changing problems in our software without being detrimental to the user,
> or their data.
>
> I don't think we should ever stop striving to reach secure coding
> nirvana. But I also understand that in the real world we are still in
> our infancy when it comes to secure software as a discipline, and we
> still have much to learn before we will reach it.

Yes, Much to learn. Like the fact that it _is_ reachable if you
believe you can reach it. And, you know, study yoga and live in a
cliff for a few years.


> Regards,
> Dana Epp
> [Microsoft Security MVP]
> http://silverstr.ufies.org/blog/

-- mic

From mouse at Rodents.Montreal.QC.CA  Thu Jul 20 18:48:10 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Thu, 20 Jul 2006 18:48:10 -0400 (EDT)
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <44BFD14A.4070704@thievco.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB74271A@va-mail.cigital.com>
	<44BFD14A.4070704@thievco.com>
Message-ID: <200607202258.SAA00520@Sparkle.Rodents.Montreal.QC.CA>

>> You might want to read Thompson's classic "reflections on trusting
>> trust".  www.acm.org/classics/sep95
> While that is always a good read, I'm not so sure it's that relevant
> anymore.  There is a LOT of binary analysis going on these days.

Yes - but you're trusting your binary analysis tools to be intact.
You're trusting the OS to give you honest copies of what's on disk.
You're trusting lots of things which could be subverted - you could be
talking to a complete funkspiel, in theory.

At some point you have to say "the chance of the system being subverted
here is low enough I'm going to ignore it".  For example, when I buy
transistors from the electronics shop, I don't worry about the
possibility that they have enough smarts inside them to act in weird
ways when used in certain applications.  As a theoretical example of
the kind of thing I mean, consider a transistor that, when used as a
switch in a serial-line level-shifter, replaces the incoming data with
other data.  I choose to trust that the stuff inside the package is
sufficiently close to what I think it is to not introduce any
insecurities relevant to my threat model.

But if my threat model included an adversary sufficiently resourceful
and subtle to subvert the electronic-part distribution chain upstream
of me, and the price of getting subverted were high enough, I might
want to set up a small smelter/forge/whatever to make my own
transistors.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From mouse at Rodents.Montreal.QC.CA  Thu Jul 20 19:24:16 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Thu, 20 Jul 2006 19:24:16 -0400 (EDT)
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <C0E55F97.13E7E%pmeunier@cerias.purdue.edu>
References: <C0E55F97.13E7E%pmeunier@cerias.purdue.edu>
Message-ID: <200607202327.TAA00748@Sparkle.Rodents.Montreal.QC.CA>

> What is important is that some magic formal tool could say that some
> code in language "A", where bug of type "k" is possible, is not
> equivalent to the version in language "B", where type "k" bugs are
> impossible, ergo you have found a type "k" bug (in the absence of any
> other bug in that section of code...).

Well, no.  You know that a bug exists.  It could be in one version (you
don't know which one), or it could be in the verifier.

If you assume that the verifier is bug-free, and you assume that the
language-A version is semantically correct, then you know that a bug
exists in the language-B version.  It might be of type k or it might be
of some other type (possibly a type that can exist in language A,
possibly not).  And in any case, you have not found it; you have only
demonstrated its existence.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From ken at krvw.com  Fri Jul 21 08:11:00 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 21 Jul 2006 08:11:00 -0400
Subject: [SC-L] Administrivia: Bumper Stickers
Message-ID: <A598A1FB-33D0-4A80-BF32-0CAD534401A4@krvw.com>

Greetings SC-L,

It's been a busy couple of days here on SC-L.  The bumper sticker  
thread, in particular, has obviously generated a *lot* of (useful and  
interesting) discussion.  While I'm reluctant to stop legitimate and  
open debate of opinions, I think that it's fair to say that this  
thread has pretty much run its course.  As such, I'm going to be  
increasingly diligent in rejecting submissions to it that don't carry  
the debate further.  I'd like to ask for everyone's support in  
helping this thread die its natural death and move on to other subjects.

So, to those that want to continue the thread, be prepared to prove  
to me with each message that your message(s) deserves to be approved  
for distribution to the list, please.

Cheers,

Ken

Kenneth Van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com





From mark at markgraff.com  Fri Jul 21 12:28:48 2006
From: mark at markgraff.com (Mark Graff)
Date: Fri, 21 Jul 2006 09:28:48 -0700
Subject: [SC-L] bumper sticker slogan for secure software
References: <mailman.183.1153483511.51224.sc-l@securecoding.org>
Message-ID: <004e01c6ace2$beea2480$0501a8c0@LIBERTY>

There's another point to consider, when talking about whether True Security 
is Possible. And I have to say I've never been happy with the forms I've 
found so far to express it...

Security, in many cases, decays. It's like what we used to call, in the Old 
Days, "bit rot". Software that has "worked" "perfectly well" for years (that 
is, failures and mistakes have fallen under the threshold of detection) 
suddenly stop "working". Often, it's because some element of the environment 
in which the system runs has changed around it. It could be a library that 
the program uses, for instance. I suppose it could be a change in the way 
the software is used, or applied.

So while most software decays in some way while it ages, I seem to observe 
that the security aspect of a program decays faster than the rest of it. 
(This has some analogies in the "real" world. Some parts of a car, for 
example, wear out faster than the rest. Tires and Brake pads. It's an 
interesting feature of good design, of course, to isolate the effects of 
wear and tear into parts intended to be disposable. But I digress.)

I have therefore often wondered if we should be talking, not about how 
"secure" a system is, in a static sense, but rather what its security 
half-life is. This is the point of my hoary thought experiment (sorry if 
you've heard this one) in which we prepare a desktop with the latest and 
greatest in the way of anti-virus stuff, firewalls, OS patches, and so 
forth, then spin it down, shrink-wrap it, and put it in a closet. If we take 
it out a year later and spin it up, that system will be less sure--more 
likely to successfully be compromised--than it was when it was spun down. 
How fast security decays will vary, depending mostly on which OS and app 
software it runs and how corrosive, if you will, that part of the overall 
operating landscape (the Internet, say)  is. This reasoning leads me to the 
thought that Mac OS X, for example, is "more secure" than Windows XP for 
reasons having nothing directly to do with design or implementation, but 
rather pertaining to its very ubiquity. XP, in this sense, is the center of 
the bullseye.

Gee, maybe software systems emanate a modicum of "unsecurity gravity", so 
that if you get a great many of them together (that is, if millions and 
millions of people buy the product), security plummets, and declines as the 
square of the distance to True Dead Center of the day's commonplace 
platform. Or, to put it another way, this is why XP sucks.

Well, I said I've never been happy with the way I've expressed this.

-mg-


----- Original Message ----- 
From: <sc-l-request at securecoding.org>
To: <sc-l at securecoding.org>
Sent: Friday, July 21, 2006 5:05 AM
Subject: SC-L Digest, Vol 2, Issue 124


> Send SC-L mailing list submissions to
> sc-l at securecoding.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://krvw.com/mailman/listinfo/sc-l
> or, via email, send a message with subject or body 'help' to
> sc-l-request at securecoding.org
>
> You can reach the person managing the list at
> sc-l-owner at securecoding.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SC-L digest..."
>
>
> Today's Topics:
>
>   1. Re: bumper sticker slogan for secure software (Pascal Meunier)
>   2. Re: bumper sticker slogan for secure software
>      (leichter_jerrold at emc.com)
>   3. Re: bumper sticker slogan for secure software (Florian Weimer)
>   4. Re: bumper sticker slogan for secure software (Pascal Meunier)
>   5. Re: bumper sticker slogan for secure software (ljknews)
>   6. Re: bumper sticker slogan for secure software (Pascal Meunier)
>   7. Re: bumper sticker slogan for secure software (ljknews)
>   8. Re: bumper sticker slogan for secure software (Dana Epp)
>   9. Re: bumper sticker slogan for secure software (John Wilander)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 20 Jul 2006 15:11:06 -0400
> From: Pascal Meunier <pmeunier at cerias.purdue.edu>
> Subject: Re: [SC-L] bumper sticker slogan for secure software
> To: Gary McGraw <gem at cigital.com>, Florian Weimer <fw at deneb.enyo.de>,
> der Mouse <mouse at rodents.montreal.qc.ca>
> Cc: SC-L at securecoding.org
> Message-ID: <C0E54D8A.13E6F%pmeunier at cerias.purdue.edu>
> Content-Type: text/plain; charset="ISO-8859-1"
>
>
>
> On 7/20/06 1:57 PM, "Gary McGraw" <gem at cigital.com> wrote:
>
>> I'm afraid that's not true.  John Knight has a famous paper that shows 
>> that
>> design/requirements bugs persist in n-version programming paradigms. 
>> I'll let
>> the interested people google that one up for themselves.
>>
>> gem
>
> But it's true for stupid bugs like buffer overflows and format string
> vulnerabilities, in which we're still swimming, and the proof is the fact
> that those aren't possible in some languages.  For design/requirements 
> bugs,
> I'm reading:
>
> Why Are Formal Methods Not Used More Widely?
> John C. Knight Colleen L. DeJong Matthew S. Gibble Lu?s G. Nakano
> Department of Computer Science
> University of Virginia
> Charlottesville, VA 22903
>
> http://www.cs.virginia.edu/~jck/publications/lfm.97.pdf
>
> and the evidence is that engineers presented with formal specifications 
> were
> able to spot many design errors ("Validation by inspection was 
> effective").
> Therefore if you have a formal, high-level version it can be validated
> better, and formal methods give proof that the lower-level code conforms.
>
> I call that all-around better, and I'm hoping for more of it and better 
> ways
> to do it.  Now if you order a cat and needed a dog, nobody can help you.
>
> Pascal
>
>
>>
>>  -----Original Message-----
>> From:  Pascal Meunier [mailto:pmeunier at cerias.purdue.edu]
>> Sent: Thu Jul 20 13:54:42 2006
>> To: Florian Weimer; der Mouse
>> Cc: SC-L at securecoding.org
>> Subject: Re: [SC-L] bumper sticker slogan for secure software
>>
>>
>>
>> On 7/20/06 11:58 AM, "Florian Weimer" <fw at deneb.enyo.de> wrote:
>>
>>> * der Mouse:
>>>
>>>>>> Absolute security is a myth.  As is designing absolutely secure
>>>>>> software.
>>>>
>>>>> I have high hopes in formal methods.
>>>>
>>>> All formal methods do is push bugs around.  Basically, you end up
>>>> writing in a higher-level language (the spec you are formally verifying
>>>> the program meets).  You are then subject to the bugs present in *that*
>>>> "program" (the spec) and the bugs present in the "compiler" (the formal
>>>> verifier).
>>>
>>> But people are forced to spend more time with the code, which
>>> generally helps them (in particular smart people) to eradicate bugs.
>>> Another way to achieve the same thing is to freeze the code base and
>>> let it mature over decades, but I don't see the business model for
>>> that.
>>
>> Also, writing it twice with different languages, especially at different
>> levels of abstraction, makes it less likely that the same bugs will 
>> appear
>> in both.  You can choose the higher level language so that it has great
>> expressive power exactly for the things that are a pain to capture and
>> verify (and thus a source of bugs) in the lower-level language.  Last 
>> time I
>> checked, formal methods were even able to catch design errors in some
>> networking protocols.  But you're right, they are not absolutely perfect
>> because the tools and operators aren't, etc...  That doesn't mean they 
>> can't
>> help a great deal.  I have great hopes for their usefulness.  Maybe some 
>> day
>> they will help so much that the distinction between what they can produce
>> and absolutely secure software will become too small to matter.  Whether
>> we'll still be alive when that happens is another question.
>>
>> Pascal
>>
>>
>>
>> _______________________________________________
>> Secure Coding mailing list (SC-L)
>> SC-L at securecoding.org
>> List information, subscriptions, etc - 
>> http://krvw.com/mailman/listinfo/sc-l
>> List charter available at - http://www.securecoding.org/list/charter.php
>>
>>
>>
>>
>> ----------------------------------------------------------------------------
>> This electronic message transmission contains information that may be
>> confidential or privileged.  The information contained herein is intended
>> solely for the recipient and use by any other party is not authorized. 
>> If
>> you are not the intended recipient (or otherwise authorized to receive 
>> this
>> message by the intended recipient), any disclosure, copying, distribution 
>> or
>> use of the contents of the information is prohibited.  If you have 
>> received
>> this electronic message transmission in error, please contact the sender 
>> by
>> reply email and delete all copies of this message.  Cigital, Inc. accepts 
>> no
>> responsibility for any loss or damage resulting directly or indirectly 
>> from
>> the use of this email or its contents.
>> Thank You.
>> ----------------------------------------------------------------------------
>>
>> _______________________________________________
>> Secure Coding mailing list (SC-L)
>> SC-L at securecoding.org
>> List information, subscriptions, etc - 
>> http://krvw.com/mailman/listinfo/sc-l
>> List charter available at - http://www.securecoding.org/list/charter.php
>>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 20 Jul 2006 15:33:30 -0400
> From: leichter_jerrold at emc.com
> Subject: Re: [SC-L] bumper sticker slogan for secure software
> To: pmeunier at cerias.purdue.edu
> Cc: mouse at rodents.montreal.qc.ca, SC-L at securecoding.org
> Message-ID: <Pine.SOL.4.61.0607201531110.20979 at mental>
> Content-Type: text/plain; charset="iso-8859-1"
>
> | >>>> Absolute security is a myth.  As is designing absolutely secure
> | >>>> software.
> | >>
> | >>> I have high hopes in formal methods.
> | >>
> | >> All formal methods do is push bugs around...
> | >
> | > But people are forced to spend more time with the code, which
> | > generally helps them (in particular smart people) to eradicate 
> bugs....
> |
> | Also, writing it twice with different languages, especially at different
> | levels of abstraction, makes it less likely that the same bugs will 
> appear
> | in both.  You can choose the higher level language so that it has great
> | expressive power exactly for the things that are a pain to capture and
> | verify (and thus a source of bugs) in the lower-level language....
> But always keep in mind a comment (allegedly, I've never actually
> seen this) present at the top of something Don Knuth wrote:
>
> Be careful with this code.  I've only proved
> it correct, not actually tested it.
>
> If Don Knuth can say that about code, the rest of us should be very
> humble about our correctness proofs.
> -- Jerry
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 20 Jul 2006 21:46:22 +0200
> From: Florian Weimer <fw at deneb.enyo.de>
> Subject: Re: [SC-L] bumper sticker slogan for secure software
> To: Pascal Meunier <pmeunier at cerias.purdue.edu>
> Cc: der Mouse <mouse at rodents.montreal.qc.ca>, SC-L at securecoding.org
> Message-ID: <87lkqojbzl.fsf at mid.deneb.enyo.de>
> Content-Type: text/plain; charset=us-ascii
>
> * Pascal Meunier:
>
>> But it's true for stupid bugs like buffer overflows and format string
>> vulnerabilities, in which we're still swimming, and the proof is the fact
>> that those aren't possible in some languages.
>
> Could you name a few such language implementations? 8-)
>
> In most cases, the components that enforces the absence of buffer
> overflows are written in C.  In other cases, languages have the
> reputation of being free from buffer overflows although it's just not
> true: You can create a fully conforming Common Lisp implementation
> where code injection through buffer overflows is possible.  On the
> other hand, it's possible to construct an ISO C implementation where
> accessing memory beyond the end of a buffer is equivalent to calling
> abort. (Such CL implementations are very common, but the C
> implementatins aren't because they would feature a very unusual ABI or
> suffer from poor performance.)
>
> And you need to keep in mind that even with C, we are close to turning
> buffer overflows into completely reproducible crashes.  This is not so
> much different from supposedly safer programming languages where an
> exception is raised in such cases.  The exception can be handled,
> sure, but if it is truly unexpected, your system will fail.
>
>>  For design/requirements bugs, I'm reading:
>
> Safety-critical software is a very different beast.  You can make much
> stronger assumptions about the environment.  It's not clear if the
> results apply to software security in open system.
>
> I'm not saying that formal methods have no value.  But I doubt that
> comparisons with projects at completely different
> dollars-per-line-of-code levels give immediate insights.
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 20 Jul 2006 16:03:01 -0400
> From: Pascal Meunier <pmeunier at cerias.purdue.edu>
> Subject: Re: [SC-L] bumper sticker slogan for secure software
> To: Florian Weimer <fw at deneb.enyo.de>
> Cc: der Mouse <mouse at rodents.montreal.qc.ca>, SC-L at securecoding.org
> Message-ID: <C0E559B5.13E7B%pmeunier at cerias.purdue.edu>
> Content-Type: text/plain; charset="US-ASCII"
>
>
>
>
> On 7/20/06 3:11 PM, "Florian Weimer" <fw at deneb.enyo.de> wrote:
>
>> * Pascal Meunier:
>>
>>> Also, writing it twice with different languages, especially at different
>>> levels of abstraction, makes it less likely that the same bugs will 
>>> appear
>>> in both.
>>
>> Algorithmic issues such as denial of service attacks through
>> unbalanced binary trees or hash table collisions are pretty
>> independent of the programming language and have been observed in many
>> incarnations.
>>
>> If you implement the same protocol, it's likely that you end up with
>> similar bugs.  The DNS compression loop bug was reinvented many times.
>> The fundamental mismatch in OpenPGP between key certification (key
>> plus user ID) and key usage (just the key alone) affected many
>> independently developed implementations.  Chrome spoofing is
>> ubiquitous in web browsers.
>>
>> Most things in this list are implemented in C or C++, but the problems
>> are at such a high level that it's unlikely that a different choice of
>> wildly different programming language would make a huge difference.
>> If you look at lower-level bugs, such as buffer overflows, I hope that
>> nobody still thinks that multiple code versions help -- just look at
>> the long list (even after discounting direct code copies) of botched
>> ASN.1 decoders.
>>
>> Some protocols are extremly hard to implement correctly, I'm afraid.
>> (And not all protocols are unnecessarily complex.)
>>
>
> It's obvious that if you just translate a bad, complicated algorithm or
> protocol from one language to the next, they'll all be bad.  It remains 
> that
> sometimes when you make people say something stupid twice they catch on 
> the
> second time, especially during code reviews, because they re-express the
> code using natural language.  That's why I said, "less likely".  It works
> with some and not others.
>
> Pascal
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 20 Jul 2006 16:20:07 -0400
> From: ljknews <ljknews at mac.com>
> Subject: Re: [SC-L] bumper sticker slogan for secure software
> To: SC-L at securecoding.org
> Message-ID: <p05200f14c0e595c4ae4d@[192.168.1.254]>
> Content-Type: text/plain; charset="us-ascii"
>
> At 9:11 PM +0200 7/20/06, Florian Weimer wrote:
>
>> Most things in this list are implemented in C or C++, but the problems
>> are at such a high level that it's unlikely that a different choice of
>> wildly different programming language would make a huge difference.
>> If you look at lower-level bugs, such as buffer overflows, I hope that
>> nobody still thinks that multiple code versions help
>
> It helps so long as some of the languages chosen are those immune to
> buffer overflows.
> -- 
> Larry Kilgallen
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 20 Jul 2006 16:28:07 -0400
> From: Pascal Meunier <pmeunier at cerias.purdue.edu>
> Subject: Re: [SC-L] bumper sticker slogan for secure software
> To: Florian Weimer <fw at deneb.enyo.de>
> Cc: der Mouse <mouse at rodents.montreal.qc.ca>, SC-L at securecoding.org
> Message-ID: <C0E55F97.13E7E%pmeunier at cerias.purdue.edu>
> Content-Type: text/plain; charset="US-ASCII"
>
>
>
>
> On 7/20/06 3:46 PM, "Florian Weimer" <fw at deneb.enyo.de> wrote:
>
>> * Pascal Meunier:
>>
>>> But it's true for stupid bugs like buffer overflows and format string
>>> vulnerabilities, in which we're still swimming, and the proof is the 
>>> fact
>>> that those aren't possible in some languages.
>>
>> Could you name a few such language implementations? 8-)
>>
>> In most cases, the components that enforces the absence of buffer
>> overflows are written in C.
> <snip>
>
> That's irrelevant.  What is important is that some magic formal tool could
> say that some code in language "A", where bug of type "k" is possible, is
> not equivalent to the version in language "B", where type "k" bugs are
> impossible, ergo you have found a type "k" bug (in the absence of any 
> other
> bug in that section of code...).
>
> I know someone is going to ask, "why didn't you code it only in language B
> then?", to which there can be many different answers, and I don't want to
> get into that.
>
>
>>>  For design/requirements bugs, I'm reading:
>>
>> Safety-critical software is a very different beast.  You can make much
>> stronger assumptions about the environment.  It's not clear if the
>> results apply to software security in open system.
>>
>> I'm not saying that formal methods have no value.  But I doubt that
>> comparisons with projects at completely different
>> dollars-per-line-of-code levels give immediate insights.
>
> That's one of the things I'm hoping for:  that more and better formal
> methods become more affordable and practical.  Spark, for example,
> demonstrated that the costs of some formal methods were much lower than 
> what
> people expected, in real projects.  That gives me hope.
>
> Pascal
>
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 20 Jul 2006 16:59:35 -0400
> From: ljknews <ljknews at mac.com>
> Subject: Re: [SC-L] bumper sticker slogan for secure software
> To: SC-L at securecoding.org
> Message-ID: <p05200f16c0e59e7ebb4d@[192.168.1.254]>
> Content-Type: text/plain; charset="us-ascii"
>
> At 9:46 PM +0200 7/20/06, Florian Weimer wrote:
>> * Pascal Meunier:
>>
>>> But it's true for stupid bugs like buffer overflows and format string
>>> vulnerabilities, in which we're still swimming, and the proof is the 
>>> fact
>>> that those aren't possible in some languages.
>>
>> Could you name a few such language implementations? 8-)
>
> Ada !
>
>> In most cases, the components that enforces the absence of buffer
>> overflows are written in C.
>
> Not in VAX/DEC/Compaq/HP Ada, which is the one that I use.
>
> But the "components" that enforce the absence of buffer overflows are
> not written in Bliss (the language of the Ada RTL for that compiler)
> either.  They are in the code that is generated, or the failure to
> generate that code because the problem was caught at compile time.
> -- 
> Larry Kilgallen
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 20 Jul 2006 15:44:38 -0700
> From: "Dana Epp" <dana at vulscan.com>
> Subject: Re: [SC-L] bumper sticker slogan for secure software
> To: <michaelslists at gmail.com>, "Wall, Kevin" <Kevin.Wall at qwest.com>
> Cc: SC-L at securecoding.org
> Message-ID:
> <9AE3FC06F0A89A43A4D6F667955082C402D364 at sbsmain.Vulscan.local>
> Content-Type: text/plain; charset="us-ascii"
>
> Actually, Brian Shea got the points for emailing me that he knew it was
> the system error "Access Denied".
>
> An extra 10 points goes to Andrew van der Stock for his explaination
> that:
>
> "apparently the term originates from radio, where 5x5 means good
> reception and good signal strength (in that order). So
>
> 0x5
>
> means
>
> - no reception ("0")
> - good signal strength ("5")
>
> ie, we're doing ok at getting our message out, but people aren't
> listening yet. "
>
> That cracked me up. So fitting for this forum.
>
>
> Regards,
> Dana Epp
> [Microsoft Security MVP]
> http://silverstr.ufies.org/blog/
>
> -----Original Message-----
> From: mikeiscool [mailto:michaelslists at gmail.com]
> Sent: Thursday, July 20, 2006 3:25 PM
> To: Wall, Kevin
> Cc: Dana Epp; SC-L at securecoding.org
> Subject: Re: [SC-L] bumper sticker slogan for secure software
>
>> BTW, does anyone besides me think that it's time to put this thread to
>
>> rest?
>
> I do.
>
> But i'm still waiting for my points from dana ...
>
>
>> -kevin
>
> -- mic
>
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 21 Jul 2006 13:15:01 +0200
> From: John Wilander <johwi at ida.liu.se>
> Subject: Re: [SC-L] bumper sticker slogan for secure software
> To: SC-L at securecoding.org
> Message-ID: <200607211115.k6LBFCoW007733 at portofix.ida.liu.se>
> Content-Type: text/plain; charset=us-ascii
>
> I've actually been using a secure software slogan for a few years, both in
> teaching and in pitching business. It's taken from Howard and LeBlanc's
> book "Writing Secure Code":
>
> - Security features are not secure features -
>
> The statement mesmerizes people and aguably needs a "necessarily" to be
> more precise. But it's short and does the trick for me---it separates
> adding security functions from trying to secure all functions in the
> system (during all phases).
>
>   Regards, John
>
> ____________________________
> John Wilander, PhD Student
> Computer and Information Sc.
> Linkoping University, Sweden
> http://www.ida.liu.se/~johwi
>
>
> ------------------------------
>
> _______________________________________________
> SC-L mailing list
> SC-L at securecoding.org
> http://krvw.com/mailman/listinfo/sc-l
>
>
> End of SC-L Digest, Vol 2, Issue 124
> ************************************
> 


From crispin at novell.com  Fri Jul 21 13:44:49 2006
From: crispin at novell.com (Crispin Cowan)
Date: Fri, 21 Jul 2006 10:44:49 -0700
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <5e01c29a0607201548v500b1e13wc2e7ceb6787c0791@mail.gmail.com>
References: <9AE3FC06F0A89A43A4D6F667955082C402D360@sbsmain.Vulscan.local>
	<5e01c29a0607201548v500b1e13wc2e7ceb6787c0791@mail.gmail.com>
Message-ID: <44C11291.4020807@novell.com>

mikeiscool wrote:
> On 7/21/06, Dana Epp <dana at vulscan.com> wrote:
>   
>>> yeah.
>>> but none of this changes the fact that it IS possible to write completely secure code.
>>>       
>> And it IS possible that a man will walk on Mars someday. But its not
>> practical or realistic in the society we live in today. I'm sorry mic,
>> but I have to disagree with you here.
>>
>> It is EXTREMELY difficult to have code be 100% correct if an application
>> has any level of real use or complexity. There will be security defects.
>>     
> Why? Why accept this as a fact? It is not a fact. If you put
> procedures in place and appropriately review and test you can be
> confident.
>   
Sorry, but it is a fact. Yes, you can have provably correct code. Cost
is approximately $20,000 per line of code. That is what the "procedures"
required for correct code cost. Oh, and they are kind of super-linear,
so one program of 200 lines costs more than 2 programs of 100 lines.

>> More importantly, threats are constantly evolving and what you may
>> consider completely secure today may not be tomorrow when a new attack
>> vector is recognized that may attack your software.
>>     
> This isn't as true and as wide spread as you make it sound. Consider,
> for example, "SQL Injection". Assuming I do not upgrade my database,
> and do not change my code and server (i.e. do not change my
> environment at all), then if I have prevented this attack initially
> nothing new will come up to suddenly make it work.
>   
Indeed, consider SQL injection attacks. They didn't exist 5 years ago,
because no one had thought of them. Same with XSS bugs. Same with printf
format string attacks. All of them are examples of processing user input
without validation, but they are all really big classes of such, and
they were discovered to occur in very large numbers in common code.

What Dana is trying to tell you is that some time in the next year or
so, someone is going to discover yet another of these major
vulnerability classes that no one has thought of before. At that point,
a lot of code that was thought to be reasonably secure suddenly is
vulnerable.

>> And unless you wrote
>> every single line of code yourself without calling out to ANY libraries,
>> you cannot rely on the security of other libraries or components that
>> may NOT have the same engineering discipline that you may have on your
>> own code base.
>>     
> Not true; you can call other libraries happily and with confidence if
> you handle the case of them going all kinds of wrong.
>   
This also is false. Consider the JPG bug that badly 0wned Microsoft
desktops a while back. It was a bug in an image processing library. You
try to view an image by processing it with the library, and the result
is that the attacker can execute arbitrary code in your process. That is
pretty difficult to defensively program against.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unaticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From securecoding2dave at davearonson.com  Fri Jul 21 19:43:43 2006
From: securecoding2dave at davearonson.com (securecoding2dave at davearonson.com)
Date: Fri, 21 Jul 2006 19:43:43 -0400
Subject: [SC-L] security half-life and critical mass
In-Reply-To: <004e01c6ace2$beea2480$0501a8c0@LIBERTY>
References: <mailman.183.1153483511.51224.sc-l@securecoding.org>
	<004e01c6ace2$beea2480$0501a8c0@LIBERTY>
Message-ID: <44C166AF.3050802@davearonson.com>

Mark Graff wrote:

> I have therefore often wondered if we should be talking, not about how 
> "secure" a system is, in a static sense, but rather what its security 
> half-life is.

Interesting point!

> This reasoning leads me to the 
> thought that Mac OS X, for example, is "more secure" than Windows XP for 
> reasons having nothing directly to do with design or implementation, but 
> rather pertaining to its very ubiquity. XP, in this sense, is the center of 
> the bullseye.

This one however has been raised many times before.  Yes, if MacOS (or 
Linux or BSD or OS/2 or whatever) had a much larger market share, there 
would be many more attacks developed against it than now.  However, from 
all I've read (not having actually TRIED to attack it myself), it is 
indeed much more securely designed, implemented, and typically deployed, 
installed, and maintained, than Windows.  So, assuming equal market 
share, I predict that you'd have several times the viruses, worms, 
rootkits, etc. directed against Windows, simply because there are 
several times as many chinks in its armor, and, just as now, gazillions 
of times as many Windows machines actually broken into or otherwise 
damaged due to bad security, as Mac.

> Gee, maybe software systems emanate a modicum of "unsecurity gravity", so 
> that if you get a great many of them together (that is, if millions and 
> millions of people buy the product), security plummets, and declines as the 
> square of the distance to True Dead Center of the day's commonplace 
> platform. Or, to put it another way, this is why XP sucks.

It's one factor.  If the market share figures were reversed, there would 
probably not be as many attacks written for it, and certainly there 
would be fewer worm-infected machines trying to attack other XP boxen. 
But it's far from the only reason.

> ----- Original Message ----- 
> From: <sc-l-request at securecoding.org>
> To: <sc-l at securecoding.org>
> Sent: Friday, July 21, 2006 5:05 AM
> Subject: SC-L Digest, Vol 2, Issue 124

Please trim your quoted matter to just what's necessary to give us a 
clue what you're talking about.  Google nettiquette.

-Dave

From dcrocker at eschertech.com  Fri Jul 21 17:57:17 2006
From: dcrocker at eschertech.com (David Crocker)
Date: Fri, 21 Jul 2006 22:57:17 +0100
Subject: [SC-L] Cost of provably-correct code (was: bumper sticker slogan
	for secure software)
In-Reply-To: <44C11291.4020807@novell.com>
Message-ID: <00f701c6ad10$a35a8ba0$cb00000a@escheradmin>

Crispin Cowan wrote on 21 July 2006 18:45:

>>
Yes, you can have provably correct code. Cost is approximately $20,000 per line
of code. That is what the "procedures" required for correct code cost. Oh, and
they are kind of super-linear, so one program of 200 lines costs more than 2
programs of 100 lines.
<<

To arrive at that cost, I can only assume that you are referring to a process in
which all the proofs are done by hand, as was attempted for a few projects in
the 1980s. We current achieve automatic proof rates of 98% to 100% (using PD),
and I hear that Praxis also achieves automatic proof rates well over 90% (using
Spark) these days. This has brought down the cost of producing provable code
enormously.

You are perhaps also including the cost of verifying the object code against the
source code. Although this is sometimes a requirement in the safety-critical
software world, I think it unlikely to be necessary for all but a very few
secure applications, assuming a mature compiler is used.

>>
Indeed, consider SQL injection attacks. They didn't exist 5 years ago, because
no one had thought of them. Same with XSS bugs. Same with printf format string
attacks. All of them are examples of processing user input without validation,
but they are all really big classes of such, and they were discovered to occur
in very large numbers in common code.

What Dana is trying to tell you is that some time in the next year or so,
someone is going to discover yet another of these major vulnerability classes
that no one has thought of before. At that point, a lot of code that was thought
to be reasonably secure suddenly is vulnerable.
<<

I agree, a new class of vulnerability may well be discovered. However, if the
code was specified and developed so as to be provably correct, then it is highly
likely that immunity to a new class of attack can be expressed by adding
additional formal requirements, allowing an immediate evaluation of where in the
design and implementation the vulnerabilities (if any) lie.

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com






From mouse at Rodents.Montreal.QC.CA  Sat Jul 22 15:46:18 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Sat, 22 Jul 2006 15:46:18 -0400 (EDT)
Subject: [SC-L] Cost of provably-correct code (was: bumper sticker
	slogan	for secure software)
In-Reply-To: <00f701c6ad10$a35a8ba0$cb00000a@escheradmin>
References: <00f701c6ad10$a35a8ba0$cb00000a@escheradmin>
Message-ID: <200607221952.PAA29490@Sparkle.Rodents.Montreal.QC.CA>

>> Yes, you can have provably correct code.

Perhaps.  But then you have bugs in the prover (and thus proof)
instead.  Human mistakes if it's human proof, bugs in the code for
automated proof.  You also have bugs in the spec that you're proving
the code conforms to (unless you're simply trying to prove something
like "this code never writes outside an array's dimentioned bounds",
which is not what I usually take "provably correct code" to mean).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From crispin at novell.com  Sun Jul 23 13:18:43 2006
From: crispin at novell.com (Crispin Cowan)
Date: Sun, 23 Jul 2006 10:18:43 -0700
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <5e01c29a0607201526h78810b6ajb78d7fa92d3ab6d3@mail.gmail.com>
References: <17EF6F3064F79040A085A09975A8595305B7F5CC@ex2k.bankofamerica.com>	<87lkqop8zq.fsf@mid.deneb.enyo.de>
	<5e01c29a0607201526h78810b6ajb78d7fa92d3ab6d3@mail.gmail.com>
Message-ID: <44C3AF73.6050105@novell.com>

mikeiscool wrote:
> On 7/21/06, Florian Weimer <fw at deneb.enyo.de> wrote:
>   
>> Secure software costs more, requires more user training, and fails in
>> hard-to-understand patterns.  If you really need it, you lose.
>>     
> Really secure software should require _less_ user training, not more.
>   
That depends.

If "really secure" means "free of defects", then yes, it should be
easier to use, because it will have fewer surprising quirks.

However, since there is so little defect-free software, most often a
"really secure" system is one with lots of belt-and-suspenders access
controls and authentication checks all over the place. "Security" is the
business of saying "no" to the bad guys, so it necessarily involves
saying "no" if you don't have all your ducks in a row.

As a result, really secure systems tend to require lots of user training
and are a hassle to use because they require permission all the time.
Imagine if every door in your house was spring loaded and closed itself
after you went through. And locked itself. And you had to use a key to
open it each time. And each door had a different key. That would be
really secure, but it would also not be very convenient.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unaticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From michaelslists at gmail.com  Sun Jul 23 18:42:10 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Mon, 24 Jul 2006 08:42:10 +1000
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <44C3AF73.6050105@novell.com>
References: <17EF6F3064F79040A085A09975A8595305B7F5CC@ex2k.bankofamerica.com>
	<87lkqop8zq.fsf@mid.deneb.enyo.de>
	<5e01c29a0607201526h78810b6ajb78d7fa92d3ab6d3@mail.gmail.com>
	<44C3AF73.6050105@novell.com>
Message-ID: <5e01c29a0607231542n76030436ia000e6c6cdd1a7f1@mail.gmail.com>

> As a result, really secure systems tend to require lots of user training
> and are a hassle to use because they require permission all the time.

No I disagree still. Consider a smart card. Far easier to use then the
silly bank logins that are available these days. Far easier then even
bothering to check if the address bar is yellow, due to FF, or some
other useless addon.

You just plug it in, and away you go, pretty much.

And requiring user permission does not make a system harder to use
(per se). It can be implemented well, and implemented badly.


> Imagine if every door in your house was spring loaded and closed itself
> after you went through. And locked itself. And you had to use a key to
> open it each time. And each door had a different key. That would be
> really secure, but it would also not be very convenient.

We're talking computers here. Technology lets you automate things.


> Crispin

-- mic

From michaelslists at gmail.com  Sun Jul 23 19:13:49 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Mon, 24 Jul 2006 09:13:49 +1000
Subject: [SC-L] bumper sticker slogan for secure software
In-Reply-To: <44C11291.4020807@novell.com>
References: <9AE3FC06F0A89A43A4D6F667955082C402D360@sbsmain.Vulscan.local>
	<5e01c29a0607201548v500b1e13wc2e7ceb6787c0791@mail.gmail.com>
	<44C11291.4020807@novell.com>
Message-ID: <5e01c29a0607231613w72f01a3o970c1d8c43b1d153@mail.gmail.com>

> Sorry, but it is a fact. Yes, you can have provably correct code. Cost
> is approximately $20,000 per line of code. That is what the "procedures"
> required for correct code cost. Oh, and they are kind of super-linear,
> so one program of 200 lines costs more than 2 programs of 100 lines.

Someone already pointed this out but your numbers here have no basis.
Provide references or something, otherwise they are meaningless.


> > This isn't as true and as wide spread as you make it sound. Consider,
> > for example, "SQL Injection". Assuming I do not upgrade my database,
> > and do not change my code and server (i.e. do not change my
> > environment at all), then if I have prevented this attack initially
> > nothing new will come up to suddenly make it work.
>
> Indeed, consider SQL injection attacks. They didn't exist 5 years ago,

Prove it.


> because no one had thought of them. Same with XSS bugs.

Again prove it.

I might say that they didn't exist at a given time because apps that
were affected weren't widely deployed. Online BBS's are relatively
new, and that, to my memory, was the first place for XSS bugs.


> What Dana is trying to tell you is that some time in the next year or
> so, someone is going to discover yet another of these major
> vulnerability classes that no one has thought of before. At that point,
> a lot of code that was thought to be reasonably secure suddenly is
> vulnerable.

Right, but if your environment is unchanged and you've looked at all
angles, then you will not be affected. Note that I'm not saying it's
easy, but ..


> > Not true; you can call other libraries happily and with confidence if
> > you handle the case of them going all kinds of wrong.
>
> This also is false. Consider the JPG bug that badly 0wned Microsoft
> desktops a while back. It was a bug in an image processing library. You
> try to view an image by processing it with the library, and the result
> is that the attacker can execute arbitrary code in your process. That is
> pretty difficult to defensively program against.

Why?


> Crispin

-- mic

From crispin at novell.com  Sun Jul 23 23:59:42 2006
From: crispin at novell.com (Crispin Cowan)
Date: Sun, 23 Jul 2006 20:59:42 -0700
Subject: [SC-L] Cost of provably-correct code
In-Reply-To: <00f701c6ad10$a35a8ba0$cb00000a@escheradmin>
References: <00f701c6ad10$a35a8ba0$cb00000a@escheradmin>
Message-ID: <44C445AE.7010102@novell.com>

David Crocker wrote:
> Crispin Cowan wrote on 21 July 2006 18:45:
>   
>> Yes, you can have provably correct code. Cost is approximately $20,000 per line
>> of code. That is what the "procedures" required for correct code cost. Oh, and
>> they are kind of super-linear, so one program of 200 lines costs more than 2
>L programs of 100 lines.
>
> To arrive at that cost, I can only assume that you are referring to a process in
> which all the proofs are done by hand, as was attempted for a few projects in
> the 1980s.
I did not arrive at it. It is (allegedly) the NSA's estimate of cost per
LOC for EAL7 provably correct assurance. This was quoted to me from a
friend at a company who has an A1 (orange book) secure microkernel.

>>  We current achieve automatic proof rates of 98% to 100% (using PD),
>> and I hear that Praxis also achieves automatic proof rates well over 90% (using
>> Spark) these days. This has brought down the cost of producing provable code
>> enormously.

Interesting. That could possibly bring down the cost of High Assurance
software enormously.

How would your prover work on (say) something like the Xen hypervisor?
Or the L4 microkernel?

Caveat: they are C code :(

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes




From dana at vulscan.com  Mon Jul 24 12:47:19 2006
From: dana at vulscan.com (Dana Epp)
Date: Mon, 24 Jul 2006 09:47:19 -0700
Subject: [SC-L] "Bumper sticker" definition of secure software
Message-ID: <9AE3FC06F0A89A43A4D6F667955082C402D367@sbsmain.Vulscan.local>

But secure software is not a technology problem, it's a business one.
Focused on people.

If smartcards were so great, why isn't every single computer in the
world equipped with a reader? There will always be technology safeguards
we can put in place to mitigate particular problems. But technology is
not a panacea here. 

There will always be trade-offs that will trump secure design and
deployment of safeguards. It's not about putting ABSOLUTE security in...
It's about putting just enough security in to mitigate risks to
acceptable levels to the business scenario at hand, and at a cost that
is justifiable. Smartcard readers aren't deployed everywhere as they
simply are too costly to deploy, against particular PERCEIVED threats
that may or not be part of an application's threat profile.

I agree that we can significantly lessen the technology integration
problem with computers. We are, after all, supposed to be competent
developers that can leverage the IT infrastructure to our bidding. The
problem is when we keep our head in the technology bubble without
thinking about the business impacts and costs, wasting resources in the
wrong areas.

It is no different than "network security professionals" that deploy
$30,000 firewalls to protect digital assets worth less than the computer
they are on. (I once saw a huge Checkpoint firewall protecting an MP3
server. Talk about waste.) Those guys should be shot for ever making
that recommendation. As should secure software engineers who think they
can solve all problems with technology without considering all risks and
impacts to the business.


Regards,
Dana Epp 
[Microsoft Security MVP]
http://silverstr.ufies.org/blog/

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of mikeiscool
Sent: Sunday, July 23, 2006 3:42 PM
To: Crispin Cowan
Cc: Secure Coding Mailing List
Subject: Re: [SC-L] "Bumper sticker" definition of secure software

> As a result, really secure systems tend to require lots of user 
> training and are a hassle to use because they require permission all
the time.

No I disagree still. Consider a smart card. Far easier to use then the
silly bank logins that are available these days. Far easier then even
bothering to check if the address bar is yellow, due to FF, or some
other useless addon.

You just plug it in, and away you go, pretty much.

And requiring user permission does not make a system harder to use (per
se). It can be implemented well, and implemented badly.


> Imagine if every door in your house was spring loaded and closed 
> itself after you went through. And locked itself. And you had to use a

> key to open it each time. And each door had a different key. That 
> would be really secure, but it would also not be very convenient.

We're talking computers here. Technology lets you automate things.


> Crispin

-- mic
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


From Ed.Reed at aesec.com  Mon Jul 24 15:06:34 2006
From: Ed.Reed at aesec.com (Ed Reed (Aesec))
Date: Mon, 24 Jul 2006 15:06:34 -0400
Subject: [SC-L] Cost of provably-correct code
In-Reply-To: <mailman.1.1153756801.41256.sc-l@securecoding.org>
References: <mailman.1.1153756801.41256.sc-l@securecoding.org>
Message-ID: <44C51A3A.7050301@aesec.com>

>
> David Crocker wrote:
>   
>> > Crispin Cowan wrote on 21 July 2006 18:45:
>> >   
>>     
>>> >> Yes, you can have provably correct code. Cost is approximately $20,000 per line
>>> >> of code. That is what the "procedures" required for correct code cost. Oh, and
>>> >> they are kind of super-linear, so one program of 200 lines costs more than 2
>>>       
>> >L programs of 100 lines.
>> >
>> > To arrive at that cost, I can only assume that you are referring to a process in
>> > which all the proofs are done by hand, as was attempted for a few projects in
>> > the 1980s.
>>     
> I did not arrive at it. It is (allegedly) the NSA's estimate of cost per
> LOC for EAL7 provably correct assurance. This was quoted to me from a
> friend at a company who has an A1 (orange book) secure microkernel.
>   

Well, not specifically for an EAL7 program, perhaps, but rather for a 
Class A1 system like ours, which is arguably a superset of an EAL7 
protection profile corresponding to the Mandatory Component (only) 
functional requirements for a Class A1 system under the Trusted Network 
Interpretation of the TCSEC.  That is, for a reference monitor 
verifiably enforcing the Mandatory Access Control (both integrity and 
secrecy) security policy (for Multi-Level Security), including formal 
top level specification and correspondence mapping to the 
implementation, including trusted distribution and RAMP (Ratings 
Assurance Maintenance Phase, which allows changes to the system to be 
evaluated incrementally rather than requiring re-examination of the 
whole system each time).

The system has a formally layered architecture (without loops) and can 
be configured with no covert storage channels (the only general purpose 
system we know of that can make such a claim),

Proving a software system is correct is one thing.  Proving it is 
correct as part of the hardware/software system of which it is a part is 
a second thing.  And proving you can securely deliver it and security 
revise it is yet something else, I suppose.

I expect that such a high cost estimate would include everything from 
clean-sheet design through evaluated configuration delivery of the 
product.  It's not the cost to prove something.  It's the cost to design 
and develop something you can prove, and then do so.
>   
>>> >>  We current achieve automatic proof rates of 98% to 100% (using PD),
>>> >> and I hear that Praxis also achieves automatic proof rates well over 90% (using
>>> >> Spark) these days. This has brought down the cost of producing provable code
>>> >> enormously.
>>>       
>
> Interesting. That could possibly bring down the cost of High Assurance
> software enormously.
>
> How would your prover work on (say) something like the Xen hypervisor?
> Or the L4 microkernel?
>
> Caveat: they are C code  :( 
>
> Crispin
The class A1 system referenced uses Pascal for the reference monitor / 
security kernel, with a small amount of assembler to handle 
hardware-interface things that couldn't be done any other way.

Pascal was chosen because it seemed a better fit than PL1, I 
suppose...for the 286-architecture environment for which it was 
originally developed.  It presently runs on Pentium-class processors.

A type-safe language was deemed necessary to support the assurance 
evaluation effort, as I understand it.

The formal internal model and top level specification is written in Ina 
Jo, the specification language of the Unisys Formal Development 
Methodology.  Reference section 7.6 "Design Specification and 
Verification" of the Final Evaluation Report for further details and 
section 8.18 "Design Specification and Verification" for the evaluators 
comments.  The Class A1 certificate is available at 
http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EPL-94-008.html or our 
copy at http://www.aesec.com/eval/CSC-EPL-94-008.html (alas, the 
Evaluated Products List is no longer generally accessible, outside the 
.mil domain, at least - I'll be happy to provide a postscript or Acrobat 
PDF copy of the FER to anyone who asks me off line for it - please don't 
blast the list with such requests, though).

Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060724/0721a432/attachment.html 

From michaelslists at gmail.com  Mon Jul 24 18:48:04 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Tue, 25 Jul 2006 08:48:04 +1000
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <9AE3FC06F0A89A43A4D6F667955082C402D367@sbsmain.Vulscan.local>
References: <9AE3FC06F0A89A43A4D6F667955082C402D367@sbsmain.Vulscan.local>
Message-ID: <5e01c29a0607241548o6d5e8b8bg57505274412f38c@mail.gmail.com>

On 7/25/06, Dana Epp <dana at vulscan.com> wrote:
> But secure software is not a technology problem,

Yes it is.


> it's a business one.
> Focused on people.

This is part of the issue, not the whole issue.


> If smartcards were so great, why isn't every single computer in the
> world equipped with a reader?

The answer isn't that smart cards aren't great, it's that it's not a
practical possibility. Maybe oneday it will be.


> There will always be technology safeguards
> we can put in place to mitigate particular problems. But technology is
> not a panacea here.

*sigh* I never said it was. No one said it was.


> It is no different than "network security professionals" that deploy
> $30,000 firewalls to protect digital assets worth less than the computer
> they are on. (I once saw a huge Checkpoint firewall protecting an MP3
> server. Talk about waste.) Those guys should be shot for ever making
> that recommendation. As should secure software engineers who think they
> can solve all problems with technology without considering all risks and
> impacts to the business.

All this is interesting but useless for this discussion. Nobody said
you should try and solve all problems with technology without consider
the impacts to the business. Please go back and read the original
posts to find out what we were talking about before going off on a
boring, totally unoriginal, rant, that everyone here is already
intimately familiar with.


> Regards,
> Dana Epp

-- mic

From vanderaj at greebo.net  Mon Jul 24 19:24:12 2006
From: vanderaj at greebo.net (Andrew van der Stock)
Date: Mon, 24 Jul 2006 16:24:12 -0700
Subject: [SC-L] "Bumper sticker" definition of secure software
In-Reply-To: <5e01c29a0607231542n76030436ia000e6c6cdd1a7f1@mail.gmail.com>
References: <17EF6F3064F79040A085A09975A8595305B7F5CC@ex2k.bankofamerica.com>
	<87lkqop8zq.fsf@mid.deneb.enyo.de>
	<5e01c29a0607201526h78810b6ajb78d7fa92d3ab6d3@mail.gmail.com>
	<44C3AF73.6050105@novell.com>
	<5e01c29a0607231542n76030436ia000e6c6cdd1a7f1@mail.gmail.com>
Message-ID: <A5EED492-2667-43C7-9182-4B19602A7662@greebo.net>

NB: I am not speaking on behalf of my employer and this is my  
personal opinion.

Banks in general do not use smart cards as they suffer from the same  
issue as two factor non-transaction signing fobs - they are somewhat  
trivial to trick users into giving up a credential. Connected keys  
are the worst - they induce laziness in the user and infer security  
which is not actually there.

Smart card integration over web apps is non-existent. The HTTP 1.1  
protocol does not support two factor transaction signing nor smart  
cards in general (unless you are just using SSL with a client-side  
cert, which is just as vulnerable as a normal IB app today if the  
attacker chooses a CSRF attack). Therefore, you need *something*  
extra to make 2FA USB fob authentication work. RSA has an ActiveX  
plugin (Keon WebPassport) which works great in an Intranet  
environment and you control all the resources. However, such  
solutions have a support overhead and locks users into just Win32  
platform, and locks out pretty much any site that blocks ActiveX  
controls on their PCs.

Here's why such devices will not fly:

*) costs money to ensure that the crypto is compliant with national  
and international standards
*) costs money to develop and deploy secure internal PKI and secure  
operational procedures to issue certificates for the devices. For the  
average institution, this is a lot of overhead.
*) costs money to deploy (need to send out software, instructions,  
device, smart card)
*) costs money to register users securely (is sending through the  
mail acceptable?) <- this step was stuffed up in the UK's Chip and  
Pin roll out, so we have an excellent data point already

http://www.theregister.co.uk/2004/09/16/chip_pin_crime_wave/

*) costs money to train users to only insert their smart card when  
your app is running and not just leave it in
*) costs money to support users when your software gets the blame for  
their user's support woes (whether true or not)
*) doesn't improve security if the user can just say yes.

The typical dialog for these things is "Please press Submit to pay  
Nice Person $100 using your token". If the app suffers from an XSS,  
why is this prompt safe? Can you trust "Nice Person" or $100?

Disconnected trx signing devices are simple, cheap, and have *fewer*  
costs. Note I do not say none of the costs, but it is significantly  
less and at least we don't trust the user's browser, the user's  
browser can be any platform (MacOS X, Linux, FreeBSD, Win95, XP,  
Vista), we don't end up supporting the user's desktop, and we don't  
need to train the users so much.

That's why smart cards will not be used if the Bank has done a proper  
side-by-side comparison, and compared the relative risk versus cost.  
Smart cards (and anything which requires platform support) are less  
secure, less trustworthy, take more effort, and cost more.

thanks,
Andrew

On 23/07/2006, at 3:42 PM, mikeiscool wrote:

> No I disagree still. Consider a smart card. Far easier to use then the
> silly bank logins that are available these days. Far easier then even
> bothering to check if the address bar is yellow, due to FF, or some
> other useless addon.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2234 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060724/21195f27/attachment.bin 

From ken at krvw.com  Tue Jul 25 13:04:37 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 25 Jul 2006 13:04:37 -0400
Subject: [SC-L] Dark Reading - Application and Perimeter Security - Hacking
	the Vista Kernel - Security News Analysis
Message-ID: <F3B3E5DA-57BC-4ABD-B3A5-6C15E05413DE@krvw.com>

Here's an interesting article from Dark Reading regarding a software  
attack on the existing Vista beta:

http://www.darkreading.com/document.asp? 
doc_id=99780&f_src=darkreading_section_296

I noticed, in particular, that the attack is against a design  
weakness of Vista -- "The attack doesn't use your typical buffer  
overflow or other bug, but basically exploits a Vista (and Windows)  
design problem -- that user-mode applications are allowed to access  
raw disk sectors, Rutkowska says."

The attack, which is being described in detail at Blackhat, looks for  
"interesting" OS code to be paged out and then carefully modifies the  
contents of the page file in order to dupe Vista into loading the  
corrupt page data.

Cheers,

Ken

Kenneth Van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060725/08cd73e8/attachment.html 

From petesh at indigo.ie  Tue Jul 25 15:31:02 2006
From: petesh at indigo.ie (Pete Shanahan)
Date: Tue, 25 Jul 2006 20:31:02 +0100
Subject: [SC-L] Dark Reading - Application and Perimeter Security -
 Hacking the Vista Kernel - Security News Analysis
In-Reply-To: <F3B3E5DA-57BC-4ABD-B3A5-6C15E05413DE@krvw.com>
References: <F3B3E5DA-57BC-4ABD-B3A5-6C15E05413DE@krvw.com>
Message-ID: <44C67176.30301@indigo.ie>

Hang on a minute,
I thought you had to have administrator access before you were permitted raw
access to the hard drive.

The createfile documentation tells us that opening a physical disk / Volume
requires that the caller must have administrative privileges.

I'm just wondering how flawed the implementation of the windows paging model is
that it would allow for this kind of breach. The standard model I'm familiar
with would simply flush the page from memory, and would not keep a copy in the
external page-file, instead relying on the copy that already exists on the disk.

Obviously I need to read more on this.

Kenneth Van Wyk wrote:
> Here's an interesting article from Dark Reading regarding a software
> attack on the existing Vista beta:
> 
> http://www.darkreading.com/document.asp?doc_id=99780&f_src=darkreading_section_296
> <http://www.darkreading.com/document.asp?doc_id=99780&f_src=darkreading_section_296>
> 
> I noticed, in particular, that the attack is against a design weakness
> of Vista -- "The attack doesn't use your typical buffer overflow or
> other bug, but basically exploits a Vista (and Windows) design problem
> -- that user-mode applications are allowed to access raw disk sectors,
> Rutkowska says."
> 
> The attack, which is being described in detail at Blackhat, looks for
> "interesting" OS code to be paged out and then carefully modifies the
> contents of the page file in order to dupe Vista into loading the
> corrupt page data.


-- 
Pete	+353 (87) 412 9576 [M]
Where there's a will, there's an Inheritance Tax.


From secureCoding2dave at davearonson.com  Tue Jul 25 16:15:46 2006
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Tue, 25 Jul 2006 20:15:46 +0000
Subject: [SC-L] Dark Reading - Application and Perimeter Security -
 Hacking the Vista Kernel - Security News Analysis
Message-ID: <W583741057944421153858546@webmail2>

Pete Shanahan [mailto:petesh at indigo.ie] writes:

 > I'm just wondering how flawed the implementation of the windows
 > paging model is that it would allow for this kind of breach. The
 > standard model I'm familiar with would simply flush the page from
 > memory, and would not keep a copy in the external page-file,
 > instead relying on the copy that already exists on the disk.

Perhaps the code in question is stored compressed, so that there is no verbatim copy already on disk.  (I have no clue if Windows does this.)

-Dave



From Ken at krvw.com  Tue Jul 25 18:43:34 2006
From: Ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 25 Jul 2006 18:43:34 -0400
Subject: [SC-L] Forwarded: PHP encryption for the common man
Message-ID: <4F5FA1FA-7B69-471A-BFF0-0210B78C3EA4@krvw.com>

FYI, I saw an interesting article today on IBM's web site detailing  
how to (and how NOT to) use encryption within PHP code.  Those  
interested can find the article at:

http://www-128.ibm.com/developerworks/library/os-php-encrypt/ 
index.html?ca=drs-

Cheers,

Ken

Kenneth Van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060725/de5f0d9e/attachment.html 

From michaelslists at gmail.com  Tue Jul 25 19:14:10 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Wed, 26 Jul 2006 09:14:10 +1000
Subject: [SC-L] Forwarded: PHP encryption for the common man
In-Reply-To: <4F5FA1FA-7B69-471A-BFF0-0210B78C3EA4@krvw.com>
References: <4F5FA1FA-7B69-471A-BFF0-0210B78C3EA4@krvw.com>
Message-ID: <5e01c29a0607251614q70675c22yab0c9fb1b662ce11@mail.gmail.com>

On 7/26/06, Kenneth Van Wyk <Ken at krvw.com> wrote:
>
> FYI, I saw an interesting article today on IBM's web site detailing how to
> (and how NOT to) use encryption within PHP code.  Those interested can find
> the article at:
>
> http://www-128.ibm.com/developerworks/library/os-php-encrypt/index.html?ca=drs-

This doesn't seem like a _great_ article, for the 'common man', as it
involves, at least in the last step, executing a binary with propsed
input from the user (i.e. a username, or something) as command line
parameters. It validates one (the 'msg' from the form), but not the
others that may be adjusted to accept input as well.

Not only is the binary ran, but it would imply that the script as
executable permissions on at least that file, if not the entire
directory, or even entire system. All of which are bad.

It also recommends to use md5, which is totally broken as a secure
hashing function and should not be used at all.


> Cheers,
>
> Ken

-- mic

From rcs at cert.org  Tue Jul 25 19:23:18 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Tue, 25 Jul 2006 19:23:18 -0400
Subject: [SC-L]  Dark Reading - CERT Seeks Secure Coding Input
In-Reply-To: <44C67176.30301@indigo.ie>
References: <F3B3E5DA-57BC-4ABD-B3A5-6C15E05413DE@krvw.com>
	<44C67176.30301@indigo.ie>
Message-ID: <44C6A7E6.8050609@cert.org>


Speaking of interesting articles from Dark Reading:

http://www.darkreading.com/document.asp?doc_id=99807&WT.svl=news1_1

This is relatively early exposure for this effort.  I am hoping to
engage the folks on this list (and elsewhere) in this effort in the fall
once the public wiki is stood up.

In completely unrelated news, a Korean translation of "Secure Coding in
C and C++" (http://www.cert.org/books/secure-coding/) is now available,
although I don't know how you would buy it except maybe by contacting
Pearson Education Asia at http://www.pearsoned-asia.com/

Thanks-
rCs

From petesh at indigo.ie  Wed Jul 26 12:49:31 2006
From: petesh at indigo.ie (Pete Shanahan)
Date: Wed, 26 Jul 2006 17:49:31 +0100
Subject: [SC-L] Dark Reading - Application and Perimeter Security -
 Hacking the Vista Kernel - Security News Analysis
In-Reply-To: <378dde5d0607260822h43fedc41n7a90152580037113@mail.gmail.com>
References: <378dde5d0607260822h43fedc41n7a90152580037113@mail.gmail.com>
Message-ID: <44C79D1B.5080605@indigo.ie>

Ken Buchanan wrote:
>> I thought you had to have administrator access before you were

> If you took Joanna to mean 'User privileges' when she said
> 'user-mode', then you were mistaken.  The opposite of user mode is
> kernel mode.

Yes, I think that would be my foot-in-mouth there. I misread the article,
misinterpreting privileges when it meant non-kernel mode.

> 
>> I'm just wondering how flawed the implementation of the windows paging
>> model is
>> that it would allow for this kind of breach. The standard model I'm
>> familiar
>> with would simply flush the page from memory, and would not keep a
>> copy in the
>> external page-file, instead relying on the copy that already exists on
>> the disk.
> 
> Can you explain this objection a little better?  I understand Joanna's
> attack to imply that she is  forcing OS code to be paged out of
> memory, meaning it is now on disk and no longer in physical memory.
> She modifies the paged-out code using raw disk writes, since
> sector-level access bypasses the file system's access control
> protection.  Then, when the OS code is needed again, it is paged back
> into physical memory carrying a whatever little Easter Egg Joanna
> cared to hide in it.

Again, a slight silliness on my behalf - I was thinking that the modifications
were being made to the content of the page-file and not the binary on-disk, as
mentioned in the article:

  This isn't simple for hackers to execute, however. "For the attack to succeed,
  one needs to find a reliable way to force interesting kernel code to be paged
  out, then find that code inside a page file and modify it. And finally, the
  kernel needs to load that code (now modified) again into physical memory and
  execute it," she says. "The proof-of-concept code I implemented solves all
  those challenges allowing for very reliable exploitation."

I presume the flaw with the OS is that the code signing check only occurs once,
at driver load time, rather than every time any part of it gets paged in.

I've seen malicious cache page corruption on Solaris, where you corrupt a page
that is already loaded in memory, which does not require root access to work.

-- 
Pete	+353 (87) 412 9576 [M]
The first time, it's a KLUDGE!
The second, a trick.
Later, it's a well-established technique!

	-- Mike Broido, Intermetrics


From dave.wichers at aspectsecurity.com  Wed Jul 26 14:57:00 2006
From: dave.wichers at aspectsecurity.com (Dave Wichers)
Date: Wed, 26 Jul 2006 14:57:00 -0400
Subject: [SC-L] ANNOUNCING: 3rd annual US OWASP AppSec Conference - Oct
	16-18 2006 - Seattle, WA
Message-ID: <02e101c6b0e5$46c82900$6564a8c0@intranet.aspectsecurity.com>

Dear Colleague,

OWASP is proud to announce its third annual U.S. Application Security
Conference. This year's conference will be held October 16-18 at the Bell
Harbor International Conference Center right on the waterfront in downtown
Seattle, WA. Please reserve these dates!! The first two conferences were on
the East coast so we felt it was the West coast's turn. This facility looks
to be the nicest facility we have had the opportunity to use yet.

This conference will include:
- Training (On Oct 16): various 1-day application security courses are being
offered the day prior to the conference
- Main Conference (Oct 17-18) This year's conference will include
presentations and also some panels to help encourage discussion amongst the
attendees
- Evening Social Event (Oct 17) - We are planning a social event as we do
each conference which facilitates the attendees ability to mingle and get to
know each other better.

Current details on the conference are available on the OWASP website at
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006

This year's conference will be kicked off with a keynote by Michael Howard
from Microsoft on "The Benefits of the SDL initiative to Microsoft and its
Customers". Mike is a top member of Microsoft's security team and a coauthor
of several application security books including Writing Secure Code, 2nd
Ed., and 19 Deadly Sins of Software Security. He will be talking about the
Microsoft Security Development Lifecycle (SDL) and the benefits Microsoft
has gained by developing and adopting it.

OWASP's AppSec conferences are dedicated to real-world application security
issues and solutions. You'll learn many aspects of application security,
including people, process, and technology perspectives.

You'll hear presentations on topics like:

  - Web Services Security
  - Securing AJAX Applications
  - The Microsoft Secure Development Lifecycle
  - The benefits of various new and enhanced OWASP projects, like:
         - OWASP Software Assurance Metrics
         - OWASP Code Review Standards
         - OWASP Java Project
         - OWASP .Net Project

The two panels are going to be on:
  - Lessons learned from Major Application Security Initiatives
  - What is in your application security toolbox?

The exact agenda is still being developed and will be posted to the site as
soon as possible.

REGISTRATION DETAILS: As a non-profit charitable organization, OWASP has
been able to keep the cost to $400 per seat if you are able to register
prior to Sept. 18, 2006. The cost to OWASP Members is only $350 prior to
Sept. 18th.

Registration is not available yet, but should be in the next week or so.
Please reserve these dates in the mean time.

PLEASE NOTE THAT ALL TICKETS WILL BE NON REFUNDABLE TO REDUCE ADMINISTRATION
COSTS

TRAINING COURSES (October 16):
These classes will be held at the Bell Harbor International Conference
Center. Each class is $675 for conference attendees (and includes lunch).
Registration for the courses will be available via the conference
registration page.

  - FOUNDATIONS OF APPLICATION SECURITY
  - WEB SERVICES AND XML SECURITY
  - ADVANCED .NET SECURITY (planned)

More details on these training courses are available at: 
http://www.owasp.org/index.php/AppSec_Seattle_2006/Training

EVENING SOCIAL EVENT - Oct 17: An optional dinner event is being planned.
Stay tuned for more details.

This event involves a dinner at a nearby location from 7-9 PM, followed by
drinks local watering holes. We hope to see all of you there as this is a
great chance to mingle and meet many members of the OWASP community.

ACCOMMODATIONS: Information about local accommodations, including reduced
rate rooms will be available at:
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006#Accommodations

If you know others that would be interested in attending the 3rd annual US
OWASP conference, please forward them this email and let them know about
this opportunity.

Please contact me with any questions. Looking forward to seeing you all
there!

Thanks, Dave

Dave Wichers, OWASP Conferences Chair
The OWASP Foundation
http://www.owasp.org 



From gem at cigital.com  Mon Jul 31 17:51:12 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 31 Jul 2006 17:51:12 -0400
Subject: [SC-L] Silver bullet
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB742996@va-mail.cigital.com>


Hi all,

International man of mystery Dana Epp is my guest in the episode of silver bullet that went up seconds ago:
http://www.cigital.com/silverbullet/show-004/

Dana is a long time software security guy and has a great blog to boot.

Check it out (and feel free to post some comments on the site).

gem

company www.cigital.com
book www.swsec.com
podcast www.cigital.com/silverbullet


Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From peter.amey at praxis-his.com  Thu Aug  3 03:32:07 2006
From: peter.amey at praxis-his.com (Peter Amey)
Date: Thu, 3 Aug 2006 08:32:07 +0100
Subject: [SC-L] Cost of provably-correct code
Message-ID: <4BF0455B353E524FBEA15C3A490F7DFE3236FC@EVS01.praxis.local>

 [Re-send, I am not sure the first copy made it to the list]

> -----Original Message-----
> From: sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org
<mailto:sc-l-bounces at securecoding.org> ] On Behalf Of Crispin Cowan
> Sent: 21 July 2006 18:45
> To: mikeiscool
> Cc: SC-L at securecoding.org
> Subject: Re: [SC-L] bumper sticker slogan for secure software
> 
> mikeiscool wrote:
> > On 7/21/06, Dana Epp <dana at vulscan.com> wrote:
> > 
> >>> yeah.
> >>> but none of this changes the fact that it IS possible to
> write completely secure code.
> >>> 
> >> And it IS possible that a man will walk on Mars someday. 
> But its not
> >> practical or realistic in the society we live in today. I'm sorry 
> >> mic, but I have to disagree with you here.
> >>
> >> It is EXTREMELY difficult to have code be 100% correct if an 
> >> application has any level of real use or complexity. There
> will be security defects.
> >> 
> > Why? Why accept this as a fact? It is not a fact. If you put 
> > procedures in place and appropriately review and test you can be 
> > confident.
> > 

> Sorry, but it is a fact. Yes, you can have provably correct code. Cost

> is approximately $20,000 per line of code. That is what the 
> "procedures"
> required for correct code cost. Oh, and they are kind of super-linear,

> so one program of 200 lines costs more than 2 programs of 100 lines.

I would be fascinated to know where this figure comes from. Our
experience is that formal development methods, which at least offer the
possibility of defect-free software, are /cheaper/ as well as resulting
in lower rates of defect. At least one major organization, with rather a
strong interest in security, agrees with us (see:
http://www.praxis-his.com/news/TokeneerNews.asp
<http://www.praxis-his.com/news/TokeneerNews.asp>  or, for the full
paper, http://www.praxis-his.com/pdfs/issse2006tokeneer.pdf
<http://www.praxis-his.com/pdfs/issse2006tokeneer.pdf> ).

I think we have to /aim/ for zero defects and choose technical
approaches that make that aim credible. If we don't then what defect
rate shall we aim for and how will we know if we have achieved it? 

Of course, as good engineers, we should never allow ourselves the hubris
of /believing/ we have achieved zero defects but that doesn't invalidate
the aim. (Aircraft manufacturers do a great deal of mathematical
analysis of stresses in wings but still proof load test each new design;
they don't expect to find any problems because of the amount of analysis
they have done but, very occasionally, they do).

regards

 

Peter



**********************************************************************

This email is confidential and intended solely for the use of the individual to whom it is addressed.  If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited.  If you have received this email in error please contact the sender.  Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis High Integrity Systems Ltd (Praxis HIS). 

 Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis HIS or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof.  The IT Department at Praxis HIS can be contacted at it.support at praxis-his.com

**********************************************************************



From Ed.Reed at aesec.com  Thu Aug  3 14:55:35 2006
From: Ed.Reed at aesec.com (Ed Reed (Aesec))
Date: Thu, 03 Aug 2006 14:55:35 -0400
Subject: [SC-L] Cost of provably-correct code (Peter Amey)
In-Reply-To: <mailman.1.1154620801.575.sc-l@securecoding.org>
References: <mailman.1.1154620801.575.sc-l@securecoding.org>
Message-ID: <44D246A7.8050708@aesec.com>


> Date: Thu, 3 Aug 2006 08:32:07 +0100
> From: "Peter Amey" <peter.amey at praxis-his.com>
> Subject: Re: [SC-L] Cost of provably-correct code
> To: <sc-l at securecoding.org>
> Message-ID:
> 	<4BF0455B353E524FBEA15C3A490F7DFE3236FC at EVS01.praxis.local>
> Content-Type: text/plain; charset="US-ASCII"
>
>  [Re-send, I am not sure the first copy made it to the list]
>
>
> I think we have to /aim/ for zero defects and choose technical
> approaches that make that aim credible. If we don't then what defect
> rate shall we aim for and how will we know if we have achieved it? 
>
>   
I agree - in the industrial world defects in workmanship and manufacture 
were taken for granted until product liability laws and ever-more 
intensive competition drove some desperate soles (the Japanese and 
Demming come to mind) to seek to differentiate themselves on the basis 
of low cost through the obsessive analysis and elimination of defects.  
They went from having a reputation for producing "junk electronics" to 
setting the standard for high value, low cost products.

The insight was that reproduce-able processes could be incrementally 
improved.

It changed many industries.

Now we have a couple of decades of experience with efforts (Xerox' 
Quality Improvement Process, Malcolm Baldridge Awards, Zero-Defect, 
Six-Sigma programs, etc.) to apply similar monitoring and analysis 
techniques to a whole range of manufacturing, service, administration 
and other industries.

But not software.  Oh, no - not software.  Too hard, too complex, some say.

I like that the Software Engineering Institute folks at Carnegie-Mellon 
are working to identify just WHICH process in software development is 
reproduce-able, so they can develop the analytical tools and processes 
to control them.

So far one they've come up with is the determinedly reproduce-ably way 
software developers repeat the same mistakes they make, over and over 
and over again.

We're not talking buffer over flows, here - we're talking careless use 
of scanf() and strcpy(), and other similar "known bad practices".

I hope they're successful promoting their programs ("Personal Software 
Process" and "Team Software Process"), because I believe they'll improve 
the overall quality of software produced by development organizations 
that use them.

But...

I don't think incremental improvement will get you to defect-free code - 
because incremental improvement is likely to be something of a 
random-walk sort of search algorithm for perfection.

The engineering approach the rest of the world uses, I hope, is a little 
more structured -

Do you know what you want?
Do you know what you DON'T want?
Can you verify that what you design / built will
   give you what you want
   not give you what you don't want?

If you can verify, through formal analysis, logical reasoning, and 
inspectible process discipline (to avoid corruption by subversion), then 
you can talk about something being both correct (does what it should) 
and secure (doesn't do what it shouldn't).

The effects of Six Sigma processes is supposed to control defects to a 
rate of 3.4 per million.  In conventional software terms, that's .0034  
defects per thousand lines of code, if you treat the production of a 
line of code as the reproduce-able process.

Compare that to conventional wisdom of software defect rates for 
commercially developed code.

Indeed, even rates of .1 defect / KLOC (which is very good) are still 
2-3 orders of magnitude greater than the goals set out by other 
industries for their own quality measures 
(http://www.softwaretechnews.com/stn8-2/praxis.html).

But that's what I think we, in the software industry, need to begin 
aiming for in order to merit calling our discipline "engineering", in my 
opinion.  Other industries are doing this, and they're doing it in the 
real-world context of customer service departments, documentation 
writing, electronic and industrial manufacturing.

It can be done.  It has been done.   It is hard.

So was programming a GUI application when the Macintosh came out 
(remember QuickDraw?).  We learned to live with it.

Ed
> Of course, as good engineers, we should never allow ourselves the hubris
> of /believing/ we have achieved zero defects but that doesn't invalidate
> the aim. (Aircraft manufacturers do a great deal of mathematical
> analysis of stresses in wings but still proof load test each new design;
> they don't expect to find any problems because of the amount of analysis
> they have done but, very occasionally, they do).
>
> regards
>
>  
>
> Peter


From ken at krvw.com  Mon Aug  7 08:55:22 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 7 Aug 2006 08:55:22 -0400
Subject: [SC-L] Six steps to secure sensitive data in MySQL - Program -
	MySQL - Builder AU
Message-ID: <C5538644-92BD-4388-9A3D-AE064A617BFE@krvw.com>

Greetings SC-Lers,

FYI, here's a link to an article on MySQL security.  Nothing huge,  
just a short list of useful tips, but I figured it could be of  
interest here.

http://www.builderau.com.au/program/mysql/soa/ 
Six_steps_to_secure_sensitive_data_in_MySQL/0,39028784,39266102,00.htm

Cheers,

Ken
-----
Kenneth R. Van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060807/c5a655c7/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20060807/c5a655c7/attachment.bin 

From ken at krvw.com  Wed Aug  9 09:20:05 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 9 Aug 2006 09:20:05 -0400
Subject: [SC-L] A New Open Source Approach to Weakness
Message-ID: <BBF7C74B-5839-4F89-AF5D-9EBFA4D00702@krvw.com>

FYI, here's an article about Fortify's pernicious kingdom taxonomy of  
common coding defects that I thought would be of interest here:

http://www.internetnews.com/dev-news/article.php/3623751

Cheers,

Ken
-----
Kenneth R. Van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060809/09d4739a/attachment.html 

From gbuday at gmail.com  Wed Aug  9 10:08:29 2006
From: gbuday at gmail.com (Gergely Buday)
Date: Wed, 9 Aug 2006 16:08:29 +0200
Subject: [SC-L] A New Open Source Approach to Weakness
In-Reply-To: <BBF7C74B-5839-4F89-AF5D-9EBFA4D00702@krvw.com>
References: <BBF7C74B-5839-4F89-AF5D-9EBFA4D00702@krvw.com>
Message-ID: <90d975d30608090708t504587c9qf047d91a084e7783@mail.gmail.com>

On 09/08/06, Kenneth Van Wyk <ken at krvw.com> wrote:
>
> FYI, here's an article about Fortify's pernicious kingdom taxonomy of common
> coding defects that I thought would be of interest here:
>
> http://www.internetnews.com/dev-news/article.php/3623751

The link to the original paper is:

http://vulncat.fortifysoftware.com/docs/tcm_taxonomy_submission.pdf

Cheers

- Gergely

From gem at cigital.com  Wed Aug  9 13:24:19 2006
From: gem at cigital.com (Gary McGraw)
Date: Wed, 9 Aug 2006 13:24:19 -0400
Subject: [SC-L] A New Open Source Approach to Weakness
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB742A31@va-mail.cigital.com>

Also note that there is a chapter in "software security" about the pernicious kingdoms...www.swsec.com.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com

 -----Original Message-----
From: 	Gergely Buday [mailto:gbuday at gmail.com]
Sent:	Wed Aug 09 10:53:52 2006
To:	Secure Coding
Subject:	Re: [SC-L] A New Open Source Approach to Weakness

On 09/08/06, Kenneth Van Wyk <ken at krvw.com> wrote:
>
> FYI, here's an article about Fortify's pernicious kingdom taxonomy of common
> coding defects that I thought would be of interest here:
>
> http://www.internetnews.com/dev-news/article.php/3623751

The link to the original paper is:

http://vulncat.fortifysoftware.com/docs/tcm_taxonomy_submission.pdf

Cheers

- Gergely
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From jeff.williams at aspectsecurity.com  Wed Aug  9 11:50:23 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Wed, 9 Aug 2006 11:50:23 -0400
Subject: [SC-L] A New Open Source Approach to Weakness
In-Reply-To: <90d975d30608090708t504587c9qf047d91a084e7783@mail.gmail.com>
Message-ID: <B9A412898630124ABE8350F4EBD32E840CE3D5@mymail.aspectsecurity.com>

Fortify has graciously donated these vulnerability writeups to OWASP,
where they will be maintained wikipedia-style.  We have a strong team of
reviewers in place to review all changes daily.  There are a total of
almost 500 vulnerabilities now, from Fortify, CLASP, and many other
sources.  We're creating an interlinked knowledgebase of common
application security principles, threats, attacks, vulnerabilities, and
countermeasures.  Anyone can participate, so come help us out.

http://www.owasp.org/index.php/Category:OWASP_Honeycomb_Project 

--Jeff
 
-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Gergely Buday
Sent: Wednesday, August 09, 2006 10:08 AM
To: Secure Coding
Subject: [***SPAM (header)***] - Re: [SC-L] A New Open Source Approach
to Weakness - Email found in subject

On 09/08/06, Kenneth Van Wyk <ken at krvw.com> wrote:
>
> FYI, here's an article about Fortify's pernicious kingdom taxonomy of
common
> coding defects that I thought would be of interest here:
>
> http://www.internetnews.com/dev-news/article.php/3623751

The link to the original paper is:

http://vulncat.fortifysoftware.com/docs/tcm_taxonomy_submission.pdf

Cheers

- Gergely
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


From mcgegick at ncsu.edu  Thu Aug 10 19:06:19 2006
From: mcgegick at ncsu.edu (mcgegick at ncsu.edu)
Date: Thu, 10 Aug 2006 19:06:19 -0400 (EDT)
Subject: [SC-L] A New Open Source Approach to Weakness
In-Reply-To: <mailman.3.1155225601.98574.sc-l@securecoding.org>
References: <mailman.3.1155225601.98574.sc-l@securecoding.org>
Message-ID: <24254.64.80.176.20.1155251179.squirrel@webmail.ncsu.edu>

The Honeycomb project seems interesting.  This sounds a lot like the
Common Weakness Enumeration (CWE ? see http://cwe.mitre.org) effort that
has been going on for the past year as part of the DHS software assurance
metrics and tool evaluation project.  The CWE is an aggregation of sources
including Seven Pernicious Kingdoms, CLASP, PLOVER, ten from OWASP, the
Web Security Threat Classification, 19 Deadly Sins, etc. that describes
software weaknesses (to date ~500 of them) in a consistently named fashion
and provides a taxonomy to organize the relationships between the
weaknesses.  The classification comes with the help of a large community
effort including NIST, MITRE, DHS, NSA, many commercial organizations,
academia, and the public.  And, I believe there are currently 15-20 tool
vendors, including Fortify Software and Secure Software, that are
contributing and mapping their content to the CWE.

Thanks,

Michael Gegick


From jeff.williams at aspectsecurity.com  Thu Aug 10 22:56:05 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Thu, 10 Aug 2006 22:56:05 -0400
Subject: [SC-L] A New Open Source Approach to Weakness
In-Reply-To: <24254.64.80.176.20.1155251179.squirrel@webmail.ncsu.edu>
Message-ID: <B9A412898630124ABE8350F4EBD32E840CE4A2@mymail.aspectsecurity.com>

We're familiar with the CWE project and there's a lot of overlap between
our vulnerabilities - not surprising given that most came from the same
sources.  Where possible we're trying to keep the same names.  We've
found that some of the topics are really attacks, and have organized
them accordingly.  One of the really great things that CWE has done is
providing links to actual CVE entries demonstrating each of the
vulnerabilities.

We started Honeycomb to:

 - create a complete library of application security building-blocks,
including principles, threats, attacks, vulnerabilities, and
countermeasures

 - enable the rich interconnection of those building-blocks in ways that
a strict one-dimensional taxonomy cannot allow

 - encourage security experts in the community to share their knowledge,
argue, edit, discuss, and resolve in wisdom of crowds fashion

--Jeff

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of mcgegick at ncsu.edu
Sent: Thursday, August 10, 2006 7:06 PM
To: sc-l at securecoding.org
Subject: [***SPAM (header)***] - Re: [SC-L] A New Open Source Approach
to Weakness - Email found in subject

The Honeycomb project seems interesting.  This sounds a lot like the
Common Weakness Enumeration (CWE - see http://cwe.mitre.org) effort that
has been going on for the past year as part of the DHS software
assurance
metrics and tool evaluation project.  The CWE is an aggregation of
sources
including Seven Pernicious Kingdoms, CLASP, PLOVER, ten from OWASP, the
Web Security Threat Classification, 19 Deadly Sins, etc. that describes
software weaknesses (to date ~500 of them) in a consistently named
fashion
and provides a taxonomy to organize the relationships between the
weaknesses.  The classification comes with the help of a large community
effort including NIST, MITRE, DHS, NSA, many commercial organizations,
academia, and the public.  And, I believe there are currently 15-20 tool
vendors, including Fortify Software and Secure Software, that are
contributing and mapping their content to the CWE.

Thanks,

Michael Gegick

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc -
http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


From livshits at cs.stanford.edu  Fri Aug 11 14:41:46 2006
From: livshits at cs.stanford.edu (Benjamin Livshits)
Date: Fri, 11 Aug 2006 11:41:46 -0700
Subject: [SC-L] LAPSE: code auditing tool for Java
Message-ID: <004b01c6bd75$ccc9fa50$bcae0c80@oberon>

We are happy to announce the first public release of LAPSE: a source code
security scanner for Java. LAPSE is an Eclipse plugin that helps automate
the code review process for Java J2EE applications. 

LAPSE is inspired by existing lightweight security auditing tools such as
RATS, pscan, and FlawFinder. Unlike those tools, however, LAPSE addresses
Web applications vulnerabilities such as SQL injection, cross-site
scripting, path traversal, etc. LAPSE is not intended as a comprehensive
solution for Web application security, but rather as an aid in the code
review process.

More information about LAPSE can be found at 

	http://suif.stanford.edu/~livshits/work/lapse/

Enjoy.

-Ben
http://www.stanford.edu/~livshits/


From dave.wichers at aspectsecurity.com  Sun Aug 13 18:39:35 2006
From: dave.wichers at aspectsecurity.com (Dave Wichers)
Date: Sun, 13 Aug 2006 18:39:35 -0400
Subject: [SC-L] ANNOUNCING: 3rd Annual US OWASP AppSec Conference - Oct
	16-18 2006 - Seattle, WA
Message-ID: <B9A412898630124ABE8350F4EBD32E840CE4FE@mymail.aspectsecurity.com>

Many more details for the OWASP conference have been settled and are now
available on the OWASP site, including:

1) Most of the agenda is set: See:
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006/Agenda

2) Conference hotel discounts have been negotiated and I'd strongly
recommend making your reservations early as many of the rates expire
after Sept 15. And downtown Seattle hotels are expensive so locking in
the conference rates will be helpful.

See:
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006#Accommodations

3) The dinner event is now planned for Anthony's Pier 66, right near the
conference center.

See:
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006#Evening_Social_
Event_-_Oct_17th

4) All the pricing details are now on the site as well, repeated from
the message below. See:
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006#Conference_Fees

The only thing missing is opening registration for the conference :-(
Due to unforeseen difficulties with our credit card processing accounts,
we haven't been able to open registration yet. It SHOULD be open in the
next 2-3 days. I'll send out another announcement when registration is
open. In the mean time, I'd recommend booking your hotel and flights to
lock in advanced pricing!!!!

Thanks, Dave

Dave Wichers
OWASP Conferences Chair

-----Original Message-----
From: Dave Wichers [mailto:dave.wichers at aspectsecurity.com] 
Sent: Wednesday, July 26, 2006 2:57 PM
To: 'SC-L at securecoding.org'; 'webappsec at securityfocus.com'
Subject: ANNOUNCING: 3rd Annual US OWASP AppSec Conference - Oct 16-18
2006 - Seattle, WA

Dear Colleague,

OWASP is proud to announce its third annual U.S. Application Security
Conference. This year's conference will be held October 16-18 at the
Bell Harbor International Conference Center right on the waterfront in
downtown Seattle, WA. Please reserve these dates!! The first two
conferences were on the East coast so we felt it was the West coast's
turn. This facility looks to be the nicest facility we have had the
opportunity to use yet.

This conference will include:
- Training (On Oct 16): various 1-day application security courses are
being offered the day prior to the conference
- Main Conference (Oct 17-18) This year's conference will include
presentations and also some panels to help encourage discussion amongst
the attendees
- Evening Social Event (Oct 17) - We are planning a social event as we
do each conference which facilitates the attendees ability to mingle and
get to know each other better.

Current details on the conference are available on the OWASP website at
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006

This year's conference will be kicked off with a keynote by Michael
Howard from Microsoft on "The Benefits of the SDL initiative to
Microsoft and its Customers". Mike is a top member of Microsoft's
security team and a coauthor of several application security books
including Writing Secure Code, 2nd Ed., and 19 Deadly Sins of Software
Security. He will be talking about the Microsoft Security Development
Lifecycle (SDL) and the benefits Microsoft has gained by developing and
adopting it.

OWASP's AppSec conferences are dedicated to real-world application
security issues and solutions. You'll learn many aspects of application
security, including people, process, and technology perspectives.

You'll hear presentations on topics like:

  - Web Services Security
  - Securing AJAX Applications
  - The Microsoft Secure Development Lifecycle
  - The benefits of various new and enhanced OWASP projects, like:
         - OWASP Software Assurance Metrics
         - OWASP Code Review Standards
         - OWASP Java Project
         - OWASP .Net Project

The two panels are going to be on:
  - Lessons learned from Major Application Security Initiatives
  - What is in your application security toolbox?

The current agenda is available at: 
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006/Agenda

REGISTRATION DETAILS: As a non-profit charitable organization, OWASP has
been able to keep the cost to $400 per seat if you are able to register
prior to Sept. 18, 2006. The cost to OWASP Members is only $350 prior to
Sept. 18th.

Registration is not available yet, but should be in the next week or so.
Please reserve these dates in the mean time.

PLEASE NOTE THAT ALL TICKETS WILL BE NON REFUNDABLE TO REDUCE
ADMINISTRATION COSTS

TRAINING COURSES (October 16):
These classes will be held at the Bell Harbor International Conference
Center. Each class is $675 for conference attendees (and includes
lunch). Registration for the courses will be available via the
conference registration page.

  - FOUNDATIONS OF APPLICATION SECURITY
  - WEB SERVICES AND XML SECURITY
  - ADVANCED .NET SECURITY

More details on these training courses are available at: 
http://www.owasp.org/index.php/AppSec_Seattle_2006/Training

EVENING SOCIAL EVENT - Oct 17: An optional dinner event is being
planned. Stay tuned for more details.

This event involves a dinner at a nearby location from 7-9 PM, followed
by drinks local watering holes. We hope to see all of you there as this
is a great chance to mingle and meet many members of the OWASP
community.

ACCOMMODATIONS: Information about local accommodations, including
reduced rate rooms will be available at:
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006#Accommodations

If you know others that would be interested in attending the 3rd annual
US OWASP conference, please forward them this email and let them know
about this opportunity.

Please contact me with any questions. Looking forward to seeing you all
there!

Thanks, Dave

Dave Wichers, OWASP Conferences Chair
The OWASP Foundation
http://www.owasp.org 



From gem at cigital.com  Mon Aug 14 14:35:39 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 14 Aug 2006 14:35:39 -0400
Subject: [SC-L] Cheating Online Games and why Google is Evil
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB421495@va-mail.cigital.com>

Hi all,

Just back from vacation and digging out from the pile.  Ironic that a
vacation seems to be a necessity to catch up from vacation!

A couple of things popped while I was flying around (sans toothpaste
there at the end).  At Blackhat a couple of weeks ago, Greg Hoglund gave
a talk called "Hacking World of Warcraft(r): An Exercise in Advanced
Rootkit Design"
<http://www.blackhat.com/html/bh-usa-06/bh-usa-06-speakers.html>.  Greg
and I are working on a book together  called "Exploiting Online Games".
AWL released a "short cut" which is basically part of the unfinished
book in pdf form called "Cheating Online Games"
<http://www.awprofessional.com/bookstore/product.asp?isbn=0321460723&rl=
1>.  The short cut concept is a new for AWL, and we're the guinea
pigs...what do you think?

Greg and I think that online games make an excellent petri dish for
studying advanced concepts in distributed systems and software security.
Lots of cool tech, and an arms race that is second to none.

During vacation (deadlines never cease) I also wrote a piece for
darkreading called "Why Google is Evil"
<http://www.darkreading.com/document.asp?doc_id=100643&WT.svl=column1_3>
.  This is about the idea of using Google to look for targets and
sploits, something that has come up on sc-l in the past.  If you're
really psyched about mis-using Google, check out Johnny Long's book.

Feedback is always welcome.  Happy August 14th.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From johwi at ida.liu.se  Tue Aug 15 04:03:07 2006
From: johwi at ida.liu.se (John Wilander)
Date: Tue, 15 Aug 2006 10:03:07 +0200
Subject: [SC-L] Web Services vs. Minimizing Attack Surface
Message-ID: <44E17FBB.60800@ida.liu.se>

Hi!

The security principle of minimizing your attack surface (Writing Secure 
Code, 2nd Ed.) is all about minimizing open sockets, rpc endpoints, 
named pipes etc. that facilitate network communication between 
applications. Web services and Service Oriented Architecture on the 
other hand are all about exposing functionality to offer interoperability.
    Have any of you had discussions on the seemingly obvious conflict 
between these things? I would be very happy to hear your conclusions and 
opinions!

    Regards, John

____________________________
John Wilander, PhD student
Computer and Information Sc.
Linkoping University, Sweden
http://www.ida.liu.se/~johwi

From gunnar at arctecgroup.net  Tue Aug 15 10:15:55 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue, 15 Aug 2006 09:15:55 -0500
Subject: [SC-L] Web Services vs. Minimizing Attack Surface
In-Reply-To: <44E17FBB.60800@ida.liu.se>
Message-ID: <C107414B.20DE%gunnar@arctecgroup.net>

There may be a conflict here depending on the implementation in practice,
but not necessarily. SOA and Web Services often aggregate lots of endpoints
(enterprise service buses do this for example) into a smaller set of service
interfaces.

A couple of weeks ago at MetriCon, Pratyusa Manadhata gave a talk on attack
surface metrics which decoupled the attack surface into methods, channel,
and data the same way Web Services does.
(http://1raindrop.typepad.com/1_raindrop/2006/08/metricon_softwa.html)

-gp


On 8/15/06 3:03 AM, "John Wilander" <johwi at ida.liu.se> wrote:

> Hi!
> 
> The security principle of minimizing your attack surface (Writing Secure
> Code, 2nd Ed.) is all about minimizing open sockets, rpc endpoints,
> named pipes etc. that facilitate network communication between
> applications. Web services and Service Oriented Architecture on the
> other hand are all about exposing functionality to offer interoperability.
>     Have any of you had discussions on the seemingly obvious conflict
> between these things? I would be very happy to hear your conclusions and
> opinions!
> 
>     Regards, John
> 
> ____________________________
> John Wilander, PhD student
> Computer and Information Sc.
> Linkoping University, Sweden
> http://www.ida.liu.se/~johwi
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php



From Holger.Peine at iese.fraunhofer.de  Tue Aug 15 10:28:46 2006
From: Holger.Peine at iese.fraunhofer.de (Holger.Peine at iese.fraunhofer.de)
Date: Tue, 15 Aug 2006 16:28:46 +0200
Subject: [SC-L] Web Services vs. Minimizing Attack Surface
Message-ID: <687F148231CEBF449E6206E3FA7AAC3F135F97@hermes.iese.fhg.de>

> [mailto:sc-l-bounces at securecoding.org] On Behalf Of John Wilander
> Sent: Dienstag, 15. August 2006 10:03
> Subject: [SC-L] Web Services vs. Minimizing Attack Surface
> 
> Hi!
> 
> The security principle of minimizing your attack surface 
> (Writing Secure 
> Code, 2nd Ed.) is all about minimizing open sockets, rpc endpoints, 
> named pipes etc. that facilitate network communication between 
> applications. Web services and Service Oriented Architecture on the 
> other hand are all about exposing functionality to offer 
> interoperability.

I don't see a conflict here: A web service (just as any
network-accessible
service, no matter whether programmed using sockets, Java RMI, SOAP or
whatever) is _intended_ to provide some function to the outside world,
so you have to open _some_ door into your system. The advice about
minimizing the attack surface is about not opening any doors you don't
really need (or worse, didn't even intend to open).

Another matter is the question of whether it might be easier to
produce a vulnerability when providing some function in the form of a
web service as opposed to another technique. One could argue in this
direction, e.g. because of creating new attack vectors such as XML
injection, or helping the attacker by providing the WSDL. But again,
this does not make web services incompatible with the principle of
minimal attack surface per se.

Kind regards,
Holger Peine

-- 
Dr. Holger Peine, Security and Safety
Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
Phone +49-631-6800-2134, Fax -1899 (shared)
PGP key via http://pgp.mit.edu ; fingerprint is 1BFA 30CB E3ED BA99 E7AE
2BBB C126 A592 48EA F9F8


From nash at solace.net  Tue Aug 15 10:48:09 2006
From: nash at solace.net (Nash)
Date: Tue, 15 Aug 2006 10:48:09 -0400
Subject: [SC-L] Web Services vs. Minimizing Attack Surface
In-Reply-To: <44E17FBB.60800@ida.liu.se>
References: <44E17FBB.60800@ida.liu.se>
Message-ID: <20060815144809.GN25558@quack.solace.net>


Thinking about "attackable surface area" is a good metaphor, but I
think it's breaking down on you.

Think about a classic forms-driven (MVC) web application. If it's at
all complex, it'll contain a variety of form processing programs that
are all interlinked with a complex state-sharing mechanism. Such an
application might be hosted on just a single "port" or "service", but
it has huge surface area. It's also devilishly difficult to verify the
code.

On the other hand, many web services look like lots and lots of
"services", but each of them has extremely limited surface area on its
own. WS programs are typically smaller than their forms-processing
cousins-- even with all the automagic frameworks for MVC.

Web services tend to be specified syntactically as opposed to
semantically. In other words, the behavior of the RPC service is
defined by how you've structured your requests and is often not based
upon the content of an server-internal state sharing mechanism. This
is a huge advantage for security because it means that the scope of a
WS service is narrowly limited to its syntactic function. It shouldn't
tend to bleed out into other functional areas. 

Finally, because web services are smaller and easier to write, they
should be (much) easier to verify for correctness. Many WS frameworks
also provide really nice abstractions of authentication and
authorization, so that you can check those separately without even
having to look at business logic in the process.

So, point being that I think that claiming that WS/SOA architectures
have greater "surface area" is ignoring the big picture. Our notion of
surface area needs to become more sophisticated to account for the
architectural differences between WS and classic-MVC apps.

If web developers want to use web services, I can't see why shouldn't
do so immediately. It shouldn't be THAT difficult for WS/SOA to make a
net positive impact on security.

Security folks shouldn't be scared of WS/SOA, we should be welcoming
it. It's a great opportunity to reintegrate seurity in a way that we
just never had with the Web 1.0 universe.


    -nash


On Tue, Aug 15, 2006 at 10:03:07AM +0200, John Wilander wrote:
> Hi!
> 
> The security principle of minimizing your attack surface (Writing
> Secure Code, 2nd Ed.) is all about minimizing open sockets, rpc
> endpoints, named pipes etc. that facilitate network communication
> between applications. Web services and Service Oriented Architecture
> on the other hand are all about exposing functionality to offer
> interoperability.  Have any of you had discussions on the seemingly
> obvious conflict between these things? I would be very happy to hear
> your conclusions and opinions!
> 
>     Regards, John
> 
> ____________________________ John Wilander, PhD student Computer and
> Information Sc.  Linkoping University, Sweden
> http://www.ida.liu.se/~johwi
> _______________________________________________ Secure Coding
> mailing list (SC-L) SC-L at securecoding.org List information,
> subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List
> charter available at - http://www.securecoding.org/list/charter.php

-- 
Please do not mock other religons
in your quest for the Spaghetti god.

        - anonymous

From ge at linuxbox.org  Tue Aug 15 16:02:02 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Tue, 15 Aug 2006 15:02:02 -0500 (CDT)
Subject: [SC-L] Web Services vs. Minimizing Attack Surface
In-Reply-To: <687F148231CEBF449E6206E3FA7AAC3F135F97@hermes.iese.fhg.de>
Message-ID: <Pine.LNX.4.21.0608151500200.27900-100000@linuxbox.org>

ou get to play with the code, in some cases anyway.Other than that and the
fact the code runs, mostly, locally, there is no difference.

The one major different is that  with some services, the vulnerability is
local as everybody builds their own.

The main issue here is that web services allow for easy access to the
machine, and for access to many third party and unrelated scripts and
modules that will not be accessible by most other programs, once already
connected.

	Gadi.

On Tue, 15 Aug 2006 Holger.Peine at iese.fraunhofer.de wrote:

> > [mailto:sc-l-bounces at securecoding.org] On Behalf Of John Wilander
> > Sent: Dienstag, 15. August 2006 10:03
> > Subject: [SC-L] Web Services vs. Minimizing Attack Surface
> > 
> > Hi!
> > 
> > The security principle of minimizing your attack surface 
> > (Writing Secure 
> > Code, 2nd Ed.) is all about minimizing open sockets, rpc endpoints, 
> > named pipes etc. that facilitate network communication between 
> > applications. Web services and Service Oriented Architecture on the 
> > other hand are all about exposing functionality to offer 
> > interoperability.
> 
> I don't see a conflict here: A web service (just as any
> network-accessible
> service, no matter whether programmed using sockets, Java RMI, SOAP or
> whatever) is _intended_ to provide some function to the outside world,
> so you have to open _some_ door into your system. The advice about
> minimizing the attack surface is about not opening any doors you don't
> really need (or worse, didn't even intend to open).
> 
> Another matter is the question of whether it might be easier to
> produce a vulnerability when providing some function in the form of a
> web service as opposed to another technique. One could argue in this
> direction, e.g. because of creating new attack vectors such as XML
> injection, or helping the attacker by providing the WSDL. But again,
> this does not make web services incompatible with the principle of
> minimal attack surface per se.
> 
> Kind regards,
> Holger Peine
> 
> -- 
> Dr. Holger Peine, Security and Safety
> Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
> Phone +49-631-6800-2134, Fax -1899 (shared)
> PGP key via http://pgp.mit.edu ; fingerprint is 1BFA 30CB E3ED BA99 E7AE
> 2BBB C126 A592 48EA F9F8
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 


From johwi at ida.liu.se  Wed Aug 16 05:22:36 2006
From: johwi at ida.liu.se (John Wilander)
Date: Wed, 16 Aug 2006 11:22:36 +0200
Subject: [SC-L] Web Services vs. Minimizing Attack Surface
In-Reply-To: <687F148231CEBF449E6206E3FA7AAC3F135F97@hermes.iese.fhg.de>
References: <687F148231CEBF449E6206E3FA7AAC3F135F97@hermes.iese.fhg.de>
Message-ID: <44E2E3DC.6040601@ida.liu.se>

Thanks for all the replies so far! I would just like to comment on 
Holger Peine's and Mike Hines' viewpoints.

Holger.Peine at iese.fraunhofer.de wrote:
> I don't see a conflict here: A web service (just as any
> network-accessible
> service, no matter whether programmed using sockets, Java RMI, SOAP or
> whatever) is _intended_ to provide some function to the outside world,
> so you have to open _some_ door into your system. The advice about
> minimizing the attack surface is about not opening any doors you don't
> really need (or worse, didn't even intend to open).

As you say, any kind of system is _intended_ to provide some function. 
But security bugs often hide in unintended, undocumented or unknown 
functionality. By increasing the attack surface you also increase the 
risk of adding unknown functions.

Mike Hines commented on web services running everything through port 80 
(HTTP) as negating "... any value of firewalls and most likely intrusion 
detection systems". Indeed, web services tunnel a lot of functionality 
through port 80, effectively hiding it from many system monitoring 
defense measures. The security will rely on validating SOAP envelopes 
and prevention at the application/run-time system level. It seems to me 
like a huge burden.

    Regards, John

____________________________
John Wilander, PhD student
Computer and Information Sc.
Linkoping University, Sweden
http://www.ida.liu.se/~johwi

From michaelslists at gmail.com  Wed Aug 16 07:23:33 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Wed, 16 Aug 2006 21:23:33 +1000
Subject: [SC-L] Web Services vs. Minimizing Attack Surface
In-Reply-To: <44E2E3DC.6040601@ida.liu.se>
References: <687F148231CEBF449E6206E3FA7AAC3F135F97@hermes.iese.fhg.de>
	<44E2E3DC.6040601@ida.liu.se>
Message-ID: <5e01c29a0608160423m4a206bc6mf66cc17b10253e15@mail.gmail.com>

On 8/16/06, John Wilander <johwi at ida.liu.se> wrote:
> Thanks for all the replies so far! I would just like to comment on
> Holger Peine's and Mike Hines' viewpoints.
>
> Holger.Peine at iese.fraunhofer.de wrote:
> > I don't see a conflict here: A web service (just as any
> > network-accessible
> > service, no matter whether programmed using sockets, Java RMI, SOAP or
> > whatever) is _intended_ to provide some function to the outside world,
> > so you have to open _some_ door into your system. The advice about
> > minimizing the attack surface is about not opening any doors you don't
> > really need (or worse, didn't even intend to open).
>
> As you say, any kind of system is _intended_ to provide some function.
> But security bugs often hide in unintended, undocumented or unknown
> functionality. By increasing the attack surface you also increase the
> risk of adding unknown functions.
>
> Mike Hines commented on web services running everything through port 80
> (HTTP) as negating "... any value of firewalls and most likely intrusion
> detection systems". Indeed, web services tunnel a lot of functionality
> through port 80, effectively hiding it from many system monitoring
> defense measures. The security will rely on validating SOAP envelopes
> and prevention at the application/run-time system level. It seems to me
> like a huge burden.

A huge burden or a huge benefit? You can validate everything in one
spot, and maybe even solve problems in one spot.

Imagine if everything went into the same system; thereby suggesting
that all attacks would be similar (i.e. all attacks against the soap
parsers of various apps, or something). If it all goes in one hole,
you can fix it once with your IDS, or whatever acronym you have
installed.

You seem to be saying that any given app i want to write, and have
publically accessible, I should write to accept connections on another
port, or find another channel to operate on (maybe through a website
app dll calls, or something).

But then, if we do that, we have to re-write everything each time.
Doesn't make alot of sense ...


>     Regards, John


-- mic

From gunnar at arctecgroup.net  Wed Aug 16 09:08:26 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Wed, 16 Aug 2006 08:08:26 -0500
Subject: [SC-L] Web Services vs. Minimizing Attack Surface
In-Reply-To: <44E2E3DC.6040601@ida.liu.se>
Message-ID: <C10882FA.2108%gunnar@arctecgroup.net>

1) you don't have to run web services over port 80

2) you can run lots of interesting things over port 80 not just web services

3) web services are an incremental improvement over dcom, mq series, and
rmi-iiop. I do not see that the IDS and Systems monitoring situation is any
worse, since they are weak in these areas as well.

4) the fact that you *can* validate soap envelopes (and body), as opposed to
the security services available in the aforementioned technologies, is
precisely the point. Web services have a number of interesting ways to
deploy security to protect your messages, SAML, WS-Security, WS-Trust, are
all improvements over what is available in web services' predecessors for
interoperable security services.

-gp


On 8/16/06 4:22 AM, "John Wilander" <johwi at ida.liu.se> wrote:

> Thanks for all the replies so far! I would just like to comment on
> Holger Peine's and Mike Hines' viewpoints.
> 
> Holger.Peine at iese.fraunhofer.de wrote:
>> I don't see a conflict here: A web service (just as any
>> network-accessible
>> service, no matter whether programmed using sockets, Java RMI, SOAP or
>> whatever) is _intended_ to provide some function to the outside world,
>> so you have to open _some_ door into your system. The advice about
>> minimizing the attack surface is about not opening any doors you don't
>> really need (or worse, didn't even intend to open).
> 
> As you say, any kind of system is _intended_ to provide some function.
> But security bugs often hide in unintended, undocumented or unknown
> functionality. By increasing the attack surface you also increase the
> risk of adding unknown functions.
> 
> Mike Hines commented on web services running everything through port 80
> (HTTP) as negating "... any value of firewalls and most likely intrusion
> detection systems". Indeed, web services tunnel a lot of functionality
> through port 80, effectively hiding it from many system monitoring
> defense measures. The security will rely on validating SOAP envelopes
> and prevention at the application/run-time system level. It seems to me
> like a huge burden.
> 
>     Regards, John
> 
> ____________________________
> John Wilander, PhD student
> Computer and Information Sc.
> Linkoping University, Sweden
> http://www.ida.liu.se/~johwi
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php



From ge at linuxbox.org  Wed Aug 16 09:38:28 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Wed, 16 Aug 2006 08:38:28 -0500 (CDT)
Subject: [SC-L] Web Services vs. Minimizing Attack Surface
In-Reply-To: <5e01c29a0608160423m4a206bc6mf66cc17b10253e15@mail.gmail.com>
Message-ID: <Pine.LNX.4.21.0608160837410.17257-100000@linuxbox.org>

On Wed, 16 Aug 2006, mikeiscool wrote:
> On 8/16/06, John Wilander <johwi at ida.liu.se> wrote:
> > Thanks for all the replies so far! I would just like to comment on
> > Holger Peine's and Mike Hines' viewpoints.
> >
> > Holger.Peine at iese.fraunhofer.de wrote:
> > > I don't see a conflict here: A web service (just as any
> > > network-accessible
> > > service, no matter whether programmed using sockets, Java RMI, SOAP or
> > > whatever) is _intended_ to provide some function to the outside world,
> > > so you have to open _some_ door into your system. The advice about
> > > minimizing the attack surface is about not opening any doors you don't
> > > really need (or worse, didn't even intend to open).
> >
> > As you say, any kind of system is _intended_ to provide some function.
> > But security bugs often hide in unintended, undocumented or unknown
> > functionality. By increasing the attack surface you also increase the
> > risk of adding unknown functions.
> >
> > Mike Hines commented on web services running everything through port 80
> > (HTTP) as negating "... any value of firewalls and most likely intrusion
> > detection systems". Indeed, web services tunnel a lot of functionality
> > through port 80, effectively hiding it from many system monitoring
> > defense measures. The security will rely on validating SOAP envelopes
> > and prevention at the application/run-time system level. It seems to me
> > like a huge burden.
> 
> A huge burden or a huge benefit? You can validate everything in one
> spot, and maybe even solve problems in one spot.
> 
> Imagine if everything went into the same system; thereby suggesting
> that all attacks would be similar (i.e. all attacks against the soap
> parsers of various apps, or something). If it all goes in one hole,
> you can fix it once with your IDS, or whatever acronym you have
> installed.
> 
> You seem to be saying that any given app i want to write, and have
> publically accessible, I should write to accept connections on another
> port, or find another channel to operate on (maybe through a website
> app dll calls, or something).
> 
> But then, if we do that, we have to re-write everything each time.
> Doesn't make alot of sense ...

You do realize you just described the Internet, right?

	Gadi.

> 
> 
> >     Regards, John
> 
> 
> -- mic
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 


From dave.wichers at aspectsecurity.com  Wed Aug 16 15:19:39 2006
From: dave.wichers at aspectsecurity.com (Dave Wichers)
Date: Wed, 16 Aug 2006 15:19:39 -0400
Subject: [SC-L] Registration Now Open!: 3rd Annual US OWASP AppSec
	Conference - Oct 16-18 2006 - Seattle, WA
Message-ID: <B9A412898630124ABE8350F4EBD32E840CE5E6@mymail.aspectsecurity.com>

Registration for the 3rd Annual US OWASP Conference is now open.

It is available at:
http://guest.cvent.com/i.aspx?4W,M3,57a181da-f20b-40fb-80ef-472a647bce7b

OWASP is switching to the use of Cvent to help manage the conference
registration process. Hopefully this will make it easier and a better
experience for everyone. Feedback on this switch is appreciated.

For the moment, we are providing all the conference information on both
the OWASP portal and Cvent at:

http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006 and
http://guest.cvent.com/i.aspx?5S,M3,57a181da-f20b-40fb-80ef-472a647bce7b

Registration is only available at the Cvent link above. Please register
early. The most important thing is that the conference hotel prices and
availability are only locked in until Sept. 22. After that, the prices
may revert to the conference hotel's normal prices or worse, the rooms
may simply not be available, so please register for the conference and
hotel as soon as possible.

For those flying in, you may be better off without a car as the
conference, the hotels, and the dinner are all within walking distance
of each other and it costs $20+ / night to park your car many places.

Thanks, Dave

Dave Wichers
OWASP Conferences Chair

-----Original Message-----
From: Dave Wichers [mailto:dave.wichers at aspectsecurity.com] 
Sent: Wednesday, July 26, 2006 2:57 PM
To: 'SC-L at securecoding.org'; 'webappsec at securityfocus.com'
Subject: ANNOUNCING: 3rd Annual US OWASP AppSec Conference - Oct 16-18
2006 - Seattle, WA

Dear Colleague,

OWASP is proud to announce its third annual U.S. Application Security
Conference. This year's conference will be held October 16-18 at the
Bell Harbor International Conference Center right on the waterfront in
downtown Seattle, WA. Please reserve these dates!! The first two
conferences were on the East coast so we felt it was the West coast's
turn. This facility looks to be the nicest facility we have had the
opportunity to use yet.

This conference will include:
- Training (On Oct 16): various 1-day application security courses are
being offered the day prior to the conference
- Main Conference (Oct 17-18) This year's conference will include
presentations and also some panels to help encourage discussion amongst
the attendees
- Evening Social Event (Oct 17) - We are planning a social event as we
do each conference which facilitates the attendees ability to mingle and
get to know each other better.

Current details on the conference are available on the OWASP website at
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006

This year's conference will be kicked off with a keynote by Michael
Howard from Microsoft on "The Benefits of the SDL initiative to
Microsoft and its Customers". Mike is a top member of Microsoft's
security team and a coauthor of several application security books
including Writing Secure Code, 2nd Ed., and 19 Deadly Sins of Software
Security. He will be talking about the Microsoft Security Development
Lifecycle (SDL) and the benefits Microsoft has gained by developing and
adopting it.

OWASP's AppSec conferences are dedicated to real-world application
security issues and solutions. You'll learn many aspects of application
security, including people, process, and technology perspectives.

You'll hear presentations on topics like:

  - Web Services Security
  - Securing AJAX Applications
  - The Microsoft Secure Development Lifecycle
  - The benefits of various new and enhanced OWASP projects, like:
         - OWASP Software Assurance Metrics
         - OWASP Code Review Standards
         - OWASP Java Project
         - OWASP .Net Project

The two panels are going to be on:
  - Lessons learned from Major Application Security Initiatives
  - What is in your application security toolbox?

The current agenda is available at: 
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006/Agenda

REGISTRATION DETAILS: As a non-profit charitable organization, OWASP has
been able to keep the cost to $400 per seat if you are able to register
prior to Sept. 18, 2006. The cost to OWASP Members is only $350 prior to
Sept. 18th.

PLEASE NOTE THAT ALL TICKETS WILL BE NON REFUNDABLE TO REDUCE
ADMINISTRATION COSTS

TRAINING COURSES (October 16):
These classes will be held at the Bell Harbor International Conference
Center. Each class is $675 for conference attendees (and includes
lunch). Registration for the courses will be available via the
conference registration page.

  - FOUNDATIONS OF APPLICATION SECURITY
  - WEB SERVICES AND XML SECURITY
  - ADVANCED .NET SECURITY

More details on these training courses are available at: 
http://www.owasp.org/index.php/AppSec_Seattle_2006/Training

EVENING SOCIAL EVENT - Oct 17: An optional dinner event has been planned
for Anthony's Pier 66. See the site for more details.

This event involves a dinner from 7-9 PM, followed by drinks at local
watering holes. We hope to see all of you there as this is a great
chance to mingle and meet many members of the OWASP community.

ACCOMMODATIONS: Information about local accommodations, including
reduced rate rooms will be available at:
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006#Accommodations

If you know others that would be interested in attending the 3rd annual
US OWASP conference, please forward them this email and let them know
about this opportunity.

Please contact me with any questions. Looking forward to seeing you all
there!

Thanks, Dave

Dave Wichers, OWASP Conferences Chair
The OWASP Foundation
http://www.owasp.org 



From ken at krvw.com  Wed Aug 16 15:43:59 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 16 Aug 2006 15:43:59 -0400
Subject: [SC-L] Dr. Dobb's | Whitebox Security Testing Using Code Scanning |
	August 14, 2006
Message-ID: <2FDD1147-2719-43B1-ABA6-D01A29AF6CDF@krvw.com>

FYI, here's an interesting article from Dr. Dobb's Journal regarding  
the use of static analysis tools for scanning for coding bugs:

http://www.ddj.com/dept/security/191901556

Cheers,

Ken
-----
Kenneth R. Van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060816/33cda057/attachment.html 

From rcs at cert.org  Thu Aug 17 10:04:21 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Thu, 17 Aug 2006 10:04:21 -0400
Subject: [SC-L] secure integer library
In-Reply-To: <C10882FA.2108%gunnar@arctecgroup.net>
References: <C10882FA.2108%gunnar@arctecgroup.net>
Message-ID: <44E47765.5020302@cert.org>


The CERT/CC has released a beta version of a secure integer library for
the C Programming Language.  The library is available for download from
the CERT/CC Secure Coding Initiative web page at:
http://www.cert.org/secure-coding/

The purpose of this library is to provide a collection of utility
functions that can assist software developers in writing C programs that
are free from common integer problems such as integer overflow, integer
truncation, and sign errors that are a common source of software
vulnerabilities.

Functions have been provided for all integer operations subject to
overflow such as addition, subtraction, multiplication, division, unary
negation, etc.) for int, long, long long, and size_t integers.  The
following example illustrates how the library can be used to add two
signed long integer values:

	long retsl, xsl, ysl;
	xsl = LONG_MAX;
	ysl = 0;
	retsl = addsl(xsl,ysl);

For short integer types (char and short) it is necessary to truncate the
result of the addition using one of the safe conversion functions
provided, for example:

	char retsc, xsc, ysc;
	xsc = SCHAR_MAX;
	ysc = 0;
	retsc = si2sc(addsi(xsc, ysc));
	
For error handling, the secure integer library uses the mechanism for
Runtime-constraint handling defined by TR 24731 "Specification for
Safer, More Secure C Library Functions" available at:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1135.pdf

The implementation uses the high performance algorithms defined by Henry
S. Warren in the book "Hacker's Delight".

For more information on vulnerabilities and other problems resulting
from the incorrect use of integers in C and C++ please read Chapter 5 of
"Secure Coding in C and C++" which is available as a free download from
the CERT web site:

http://www.cert.org/books/secure-coding/moreinfo.html

Please address any defect reports, comments and suggestions concerning
the Secure Integer Library or CERT Secure Coding Initiative to me.
Thanks to Henry and to Juan Alvarado who coded the implementation.

Thanks,
rCs


-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC

Work: 412-268-7608
FAX: 412-268-6989

From pmeunier at cerias.purdue.edu  Thu Aug 17 11:43:09 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Thu, 17 Aug 2006 11:43:09 -0400
Subject: [SC-L] secure integer library
In-Reply-To: <44E47765.5020302@cert.org>
Message-ID: <C10A06CD.149C3%pmeunier@cerias.purdue.edu>

Nice.  I'll mention it in my secure programming class this semester.  I'd be
interested in any exercises/labs based on it, appropriate for undergrads.

Cheers,
Pascal


On 8/17/06 10:04 AM, "Robert C. Seacord" <rcs at cert.org> wrote:

> 
> The CERT/CC has released a beta version of a secure integer library for
> the C Programming Language.  The library is available for download from
> the CERT/CC Secure Coding Initiative web page at:
> http://www.cert.org/secure-coding/
> 
> The purpose of this library is to provide a collection of utility
> functions that can assist software developers in writing C programs that
> are free from common integer problems such as integer overflow, integer
> truncation, and sign errors that are a common source of software
> vulnerabilities.
> 
> Functions have been provided for all integer operations subject to
> overflow such as addition, subtraction, multiplication, division, unary
> negation, etc.) for int, long, long long, and size_t integers.  The
> following example illustrates how the library can be used to add two
> signed long integer values:
> 
> long retsl, xsl, ysl;
> xsl = LONG_MAX;
> ysl = 0;
> retsl = addsl(xsl,ysl);
> 
> For short integer types (char and short) it is necessary to truncate the
> result of the addition using one of the safe conversion functions
> provided, for example:
> 
> char retsc, xsc, ysc;
> xsc = SCHAR_MAX;
> ysc = 0;
> retsc = si2sc(addsi(xsc, ysc));
> 
> For error handling, the secure integer library uses the mechanism for
> Runtime-constraint handling defined by TR 24731 "Specification for
> Safer, More Secure C Library Functions" available at:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1135.pdf
> 
> The implementation uses the high performance algorithms defined by Henry
> S. Warren in the book "Hacker's Delight".
> 
> For more information on vulnerabilities and other problems resulting
> from the incorrect use of integers in C and C++ please read Chapter 5 of
> "Secure Coding in C and C++" which is available as a free download from
> the CERT web site:
> 
> http://www.cert.org/books/secure-coding/moreinfo.html
> 
> Please address any defect reports, comments and suggestions concerning
> the Secure Integer Library or CERT Secure Coding Initiative to me.
> Thanks to Henry and to Juan Alvarado who coded the implementation.
> 
> Thanks,
> rCs
> 



From rcs at cert.org  Thu Aug 17 13:09:18 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Thu, 17 Aug 2006 13:09:18 -0400
Subject: [SC-L] secure integer library
In-Reply-To: <C10A06CD.149C3%pmeunier@cerias.purdue.edu>
References: <C10A06CD.149C3%pmeunier@cerias.purdue.edu>
Message-ID: <44E4A2BE.6010601@cert.org>

Pascal,

> Nice.  I'll mention it in my secure programming class this semester.  I'd be
> interested in any exercises/labs based on it, appropriate for undergrads.

ok.  i'll be teaching an undergraduate elective on secure coding at CMU
in the spring so i'll probably need to get to work on that soon.  8^)

rCs

-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC

Work: 412-268-7608
FAX: 412-268-6989

From Kevin.Wall at qwest.com  Mon Aug 28 00:51:47 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Sun, 27 Aug 2006 23:51:47 -0500
Subject: [SC-L] How can we stop the spreading insecure coding examples at
	training classes, etc.?
Message-ID: <CF8B26B8B49184429CB084616B0019300244E8CB@itomae2km05.AD.QINTRA.COM>

First a bit of background and a confession.

The background: I recently attended a local 4 hr
Microsoft training seminar called "Get Connected with the
.NET Framework 2.0 and Visual Studio(c) 2005". However, I
want to clarify that this example is NOT just a Microsoft
issue. It's an industry-wide issue; only the examples I give
are from this most recent Microsoft training seminar. (Actually,
calling it "training" is probably a stretch; it was more like
and advertisement for .NET Framework 3.0 (a.k.a., "Atlas")
and a forthcoming version of Visual Studio, but that's another
gripe. ;-)

The confession: 90% of the examples presented at this training
was in Visual Basic and about 10% was C#. I personally think that
VB is horrid as a programming language (for the most part, I
concur with Dijkstra about anything BASIC-like; see .sig, below),
and so may be causing some bias with my observations.

Anyway, back to the main point. At this training seminar, the
demo code that they showed (which mostly was about Atlas features,
not about .NET Framework 2.0 features) had very little in the way
of proper security checks. This was most notable in the almost
complete absence of authorization checks and proper data
validation checks. Also, most of these quotations below
are actually paraphrases (including my own!), but nevertheless,
I believe they are fairly accurate and hopefully non-biased.

At one point, the speaker asked "what's wrong with this code
fragment" (a demo to upload a file). I said "there's no proper
data validation, so one can use a series of '..\' in the file
name and use it to do directory traversal attacks and overwrite
whatever file the user id running the web server has permissions
to write to." (Of course, that was the "wrong" answer. Their
"proper" answer was that W3C had instituted a max size of 4MB or
so on files that could be uploaded in this manner, but they had a
mechanism to get around it.)

At another point, while Atlas JavaScript gadgets was being demoed,
someone asked if one could use XMLHttpRequest (XHR) to invoke
_any_ URL. The speaker correctly answered "no; only back to the
originating host:port from where the JavaScript was downloaded
from". The questioner then remarked something like "oh, that's too
bad". But instead of explaining why allowing cross-domain requests
is inherently a BAD Thing, the speaker replied "oh, don't worry;
we also provide you with some software [apparently a proxy of
sorts -kww] that Microsoft wrote that you can put on your web
server so your users can call out to any URL that they wish,
so it's not limited to calling just pages on your own site."
"Great, I thought. Why don't you also provide some mechanisms to
automatically insert random XSS and SQL injection vulnerabilities
into your code too." Sigh. 

Now understand, these are only a few recent examples presented
at this training. Over the past few years, I've seen numerous
other lame examples of demo code elsewhere, ranging from symmetric
encryption examples using block ciphers (where it's implied that
you should always just use ECB mode; in fact no other cipher
modes are even mentioned!), to showing how to create a web
service without even mentioning any mechanisms for authentication
or authorization. (Actually, many typically don't even
_recognize_ the NEED for such things.)

Make no mistake in thinking that this poor practice is limited
to Microsoft. At one point or another, we probably have all done
something like this and then just casually mentioned "of course
you need to do X, Y, and Z to make it secure". I understand the
the pedagogical need that example code has to be kept simple.
Usually much of the error code is completely omitted, not just
security-related checks. But most developers have enough sense
of the application-related errors to know they need to add the
application-level error checking; not so for security-related
checks--at least not for your average developer.

Of course the big problem with any poor examples is that this
is just the type of thing that developers who have little security
experience will copy-and-paste into their PRODUCTION code, thus
exposing the vulnerabilities.  And nowadays, it's even made
easier to copy-and-paste this insecure code by either making it
available for download from the Internet or passing it out on a
CD or DVD. Many of us have probably been guilty of that too,
at least once in our lives.

But we need to all recognize that there is no reason that the
demo code that made available for downloading or on a CD needs
to be the exact same code displayed during the training.
(N.B.: I've not yet checked the DVD supplied by Microsoft,
but the instructors said [paraphrase] we would find "the exact
same code were are using in our examples on the DVD".)

I think that this practice of leaving out the "security
details" to just make the demo code short and sweet has got
to stop. Or minimally, we have to make the code that people
copy-and-paste from have all the proper security checks even
if we don't cover them in training. If we're lucky, maybe
they won't delete them when the re-use the code.

I was so irate after this whole experience, I filled up the
entire comments section of the evaluation form complaining
about this and how it was a tragedy given that other parts
of Microsoft seem to be working so hard to improve security.

But my question is, is that enough? Should I (we) do more, like
complaining to someone higher up in security--in this case,
to someone at Microsoft, perhaps and advocate such as Michael
Howard? And if so, to whom? And what, if anything, can
we do collectively to try to prevent these types of insecure
demos from making their way into the hands of large numbers
of developers? Maybe we are not raising a big enough stink
in this regard.

Okay; thanks for allowing me to vent. I feel better now, a
little...
-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
"It is practically impossible to teach good programming to
 students that have had a prior exposure to BASIC: as potential
 programmers they are mentally mutilated beyond hope of
 regeneration"
    - Edsger Dijkstra, How do we tell truths that matter?
      http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.


From gem at cigital.com  Mon Aug 28 15:04:23 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 28 Aug 2006 15:04:23 -0400
Subject: [SC-L] Silver Bullet #5: Ed Felten
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB742D35@va-mail.cigital.com>

Hi all,

The latest Silver Bullet Security Podcast features an interview I did
with Ed Felten.  It just went up today.  You can download the podcast
and subscribe to the RSS feed here:
www.cigital.com/silverbullet

In addition, IEEE Security & Privacy magazine has prepared a partial
transcript of our conversation which can be found here:
http://www.cigital.com/silverbullet/shows/silverbullet-005-efelten.pdf

The transcript will be published in the November/December issue of the
magazine.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From neumann at csl.sri.com  Mon Aug 28 17:28:08 2006
From: neumann at csl.sri.com (Peter G. Neumann)
Date: Mon, 28 Aug 2006 14:28:08 PDT
Subject: [SC-L] How can we stop the spreading insecure coding examples
 at training classes, etc.?
In-Reply-To: Your message of Sun, 27 Aug 2006 23:51:47 -0500
Message-ID: <CMM.0.90.4.1156800488.neumann@chiron.csl.sri.com>

> But my question is, is that enough? 

Of course not.  It's nowhere near enough.  
Of course, there is NEVER "ENOUGH" in this business.
But what you are suggesting is still very far from 
what might be thought of as enough under the circumstances.

PGN


From pmeunier at purdue.edu  Mon Aug 28 16:40:45 2006
From: pmeunier at purdue.edu (pmeunier at purdue.edu)
Date: Mon, 28 Aug 2006 16:40:45 -0400
Subject: [SC-L] How can we stop the spreading insecure coding examples
	at training classes, etc.?
In-Reply-To: <CF8B26B8B49184429CB084616B0019300244E8CB@itomae2km05.AD.QINTRA.COM>
References: <CF8B26B8B49184429CB084616B0019300244E8CB@itomae2km05.AD.QINTRA.COM>
Message-ID: <1156797645.44f354cd4623f@webmail.purdue.edu>

Quoting "Wall, Kevin" <Kevin.Wall at qwest.com>:

(clip)
> At another point, while Atlas JavaScript gadgets was being demoed,
> someone asked if one could use XMLHttpRequest (XHR) to invoke
> _any_ URL. The speaker correctly answered "no; only back to the
> originating host:port from where the JavaScript was downloaded
> from". The questioner then remarked something like "oh, that's too
> bad". But instead of explaining why allowing cross-domain requests
> is inherently a BAD Thing, the speaker replied "oh, don't worry;
> we also provide you with some software [apparently a proxy of
> sorts -kww] that Microsoft wrote that you can put on your web
> server so your users can call out to any URL that they wish,
> so it's not limited to calling just pages on your own site."
> "Great, I thought. Why don't you also provide some mechanisms to
> automatically insert random XSS and SQL injection vulnerabilities
> into your code too." Sigh. 
>
<snip>

Kevin,
   Thanks, I almost fell out of my chair laughing.  It reminds me of their
"SOAP" idea to bypass those pesky firewalls.  Apple also finds that security
measure "unfortunate" without an explanation of the underlying security reasons:

"Second, the domain of the URL request destination must be the same as the one
that serves up the page containing the script. This means, unfortunately, that
client-side scripts cannot fetch web service data from other sources..."
(http://developer.apple.com/internet/webcontent/xmlhttpreq.html)

But neverfear, tell your users who use Firefox to install the Greasemonkey
extension, and hop, you can bypass this security nuisance 
(http://blog.monstuff.com/archives/000262.html  -- though this entry points out
it should be used only for development purposes and otherwise a bad idea).  IE
users just have to click OK in the "confirmation" dialog box that pops up.

I hate JavaScript because it makes me feel so much at the mercy of web
developers, who sometimes require it just to emulate an <A> link or a submit
button...  

Pascal

From pmeunier at purdue.edu  Tue Aug 29 15:48:17 2006
From: pmeunier at purdue.edu (pmeunier at purdue.edu)
Date: Tue, 29 Aug 2006 15:48:17 -0400
Subject: [SC-L] How can we stop the spreading insecure coding examples
	at training classes, etc.?
In-Reply-To: <CF8B26B8B49184429CB084616B0019300244E8CB@itomae2km05.AD.QINTRA.COM>
References: <CF8B26B8B49184429CB084616B0019300244E8CB@itomae2km05.AD.QINTRA.COM>
Message-ID: <1156880897.44f49a01620aa@webmail.purdue.edu>

Quoting "Wall, Kevin" <Kevin.Wall at qwest.com>:


> I think that this practice of leaving out the "security
> details" to just make the demo code short and sweet has got
> to stop. Or minimally, we have to make the code that people
> copy-and-paste from have all the proper security checks even
> if we don't cover them in training. If we're lucky, maybe
> they won't delete them when the re-use the code.

I agree, and would like to extend it: security should be discussed *at the same
time* that a topic is.  Teaching security in a separate class, like I have been
doing, reaches only a fraction of the audience, and reinforces an attitude of
security as an afterthought, or security as an option.  Comments in the code
should explain (or refer to explanations of) why changing or deleting those
lines is a bad idea.  

However, I'm afraid that it would irritate students, and make security the new
"grammar and spelling" for which points are deducted from "perfectly valid
write-ups" (i.e., "it's my ideas that count, not how well I spell").  So, this
idea may be more successful with professionals courses than with undergrads.  As
far as students go, if it's not on the test it might as well be a policy that
isn't enforced, so it's not an option to try to teach it but to not grade based
on it.  Good luck also in trying to get all professors to update their classes
and cover security correctly...  Please share any answers or insights as to this
dilemma.  

Thanks,
Pascal


From Ed.Reed at aesec.com  Wed Aug 30 13:17:01 2006
From: Ed.Reed at aesec.com (Ed Reed (Aesec))
Date: Wed, 30 Aug 2006 13:17:01 -0400
Subject: [SC-L] e: How can we stop the spreading insecure coding examples at,
 training classes, etc.?
In-Reply-To: <mailman.1.1156953601.18972.sc-l@securecoding.org>
References: <mailman.1.1156953601.18972.sc-l@securecoding.org>
Message-ID: <44F5C80D.4030804@aesec.com>

>
> Message: 1
> Date: Tue, 29 Aug 2006 15:48:17 -0400
> From: pmeunier at purdue.edu
> Subject: Re: [SC-L] How can we stop the spreading insecure coding
> 	examples	at training classes, etc.?
> To: "Wall, Kevin" <Kevin.Wall at qwest.com>
> Cc: SC-L at securecoding.org
> Message-ID: <1156880897.44f49a01620aa at webmail.purdue.edu>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Quoting "Wall, Kevin" <Kevin.Wall at qwest.com>:
>
>
>   
>> I think that this practice of leaving out the "security
>> details" to just make the demo code short and sweet has got
>> to stop. Or minimally, we have to make the code that people
>> copy-and-paste from have all the proper security checks even
>> if we don't cover them in training. If we're lucky, maybe
>> they won't delete them when the re-use the code.
>>     
>
> I agree, and would like to extend it: security should be discussed *at the same
> time* that a topic is.  Teaching security in a separate class, like I have been
> doing, reaches only a fraction of the audience, and reinforces an attitude of
> security as an afterthought, or security as an option.  Comments in the code
> should explain (or refer to explanations of) why changing or deleting those
> lines is a bad idea.  
>
> However, I'm afraid that it would irritate students, and make security the new
> "grammar and spelling" for which points are deducted from "perfectly valid
> write-ups" (i.e., "it's my ideas that count, not how well I spell").  
The same used to be said about unstructured programming examples 
(computed gotos, spaghetti code, multiple entry and exit points from 
functions, etc).  We got past it.

We need a similar revolution in thought with regard to security, and 
some one to take the lead on providing clear, crisp examples of coding 
style that is more secure by its nature.  I don't have one handy - but 
that's my wish.

Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060830/d6c25b2c/attachment.html 

From tholleb at teknowledge.com  Wed Aug 30 13:23:26 2006
From: tholleb at teknowledge.com (Tim Hollebeek)
Date: Wed, 30 Aug 2006 10:23:26 -0700
Subject: [SC-L] How can we stop the spreading insecure coding examples
	attraining classes, etc.?
In-Reply-To: <CF8B26B8B49184429CB084616B0019300244E8CB@itomae2km05.AD.QINTRA.COM>
Message-ID: <200608301730.k7UHTxtE042126@ratsass.krvw.com>


Really, the root of the problem is the fact that the simple version
is short and easy to understand, and the secure version is five
times longer and completely unreadable.  While there always is some
additional complexity inherent in a secure version, it is nowhere
near as bad as current toolkits make it seem.

Demo code generally demonstrates some fairly powerful capability;
the reason it is often short and sweet is because lots of effort
has gone into making it possible to do useful things with minimal
effort.  Unfortunately, it is often the case that much less effort
has gone into making it possible to do the same thing securely, so
that code is quite a bit longer.  You're right, if there was more
of a pushback against broken demo code, maybe more effort would go
into making it easy to do things securely, instead of insecurely.

I think part of the problem is that people have fallen into the
trap of thinking that security is supposed to be hard and that
checking all your errors is supposed to bloat your code by a factor
of five, instead of wondering why library functions are designed
in such a way that omitting complex logic around them fails in an
insecure way.  Secure code can be short and sweet, too, just not
with most of the languages and tools that are currently popular.

This is an old, old problem.  strcpy is insecure, and any code
involving strncpy or a length check will be longer and/or more
complex.  But this is really just an artifact of the fact that
buffers don't know their own length, making an additional check 
necessary.  There is no reason why the secure version couldn't 
have been just as short and sweet, it just wasn't done.

Tim Hollebeek
Research Scientist
Teknowledge, Corp.



From mshines at purdue.edu  Wed Aug 30 14:07:14 2006
From: mshines at purdue.edu (Michael S Hines)
Date: Wed, 30 Aug 2006 14:07:14 -0400
Subject: [SC-L] Coding with errors in mind - a solution?
In-Reply-To: <44F5C80D.4030804@aesec.com>
Message-ID: <200608301807.k7UI7SVD021973@mailhub128.itcs.purdue.edu>

a simple structure that provides for errors would go a long way... 
 
If - then - else - on error
Do - end - on error
Let x = y - on error
Let x = function() on error
etc...    
 
The problem is writing code without thinking of the possible errors that
might arise.   This forces you to think about the consequences of executing
a command...
 
Where 'error' is doing something intelligent when the original command
doesn't work...    
 
Just a brainstorm....... any merit to it?
 
Mike Hines
mshines at purdue.edu

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Ed Reed (Aesec)
Sent: Wednesday, August 30, 2006 1:17 PM
To: sc-l at securecoding.org
Subject: [SC-L] e: How can we stop the spreading insecure coding examples
at, training classes, etc.?



Message: 1

Date: Tue, 29 Aug 2006 15:48:17 -0400

From: pmeunier at purdue.edu

Subject: Re: [SC-L] How can we stop the spreading insecure coding

	examples	at training classes, etc.?

To: "Wall, Kevin"  <mailto:Kevin.Wall at qwest.com> <Kevin.Wall at qwest.com>

Cc: SC-L at securecoding.org

Message-ID:  <mailto:1156880897.44f49a01620aa at webmail.purdue.edu>
<1156880897.44f49a01620aa at webmail.purdue.edu>

Content-Type: text/plain; charset=ISO-8859-1



Quoting "Wall, Kevin"  <mailto:Kevin.Wall at qwest.com> <Kevin.Wall at qwest.com>:





  

I think that this practice of leaving out the "security

details" to just make the demo code short and sweet has got

to stop. Or minimally, we have to make the code that people

copy-and-paste from have all the proper security checks even

if we don't cover them in training. If we're lucky, maybe

they won't delete them when the re-use the code.

    



I agree, and would like to extend it: security should be discussed *at the
same

time* that a topic is.  Teaching security in a separate class, like I have
been

doing, reaches only a fraction of the audience, and reinforces an attitude
of

security as an afterthought, or security as an option.  Comments in the code

should explain (or refer to explanations of) why changing or deleting those

lines is a bad idea.  



However, I'm afraid that it would irritate students, and make security the
new

"grammar and spelling" for which points are deducted from "perfectly valid

write-ups" (i.e., "it's my ideas that count, not how well I spell").  

The same used to be said about unstructured programming examples (computed
gotos, spaghetti code, multiple entry and exit points from functions, etc).
We got past it.

We need a similar revolution in thought with regard to security, and some
one to take the lead on providing clear, crisp examples of coding style that
is more secure by its nature.  I don't have one handy - but that's my wish.

Ed

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060830/b391a6f1/attachment.html 

From band at acm.org  Wed Aug 30 15:04:32 2006
From: band at acm.org (William L. Anderson)
Date: Wed, 30 Aug 2006 14:04:32 -0500
Subject: [SC-L] Coding with errors in mind - a solution?
In-Reply-To: <200608301807.k7UI7SVD021973@mailhub128.itcs.purdue.edu>
References: <200608301807.k7UI7SVD021973@mailhub128.itcs.purdue.edu>
Message-ID: <44F5E140.9000008@acm.org>

Michael, this is an interesting note. Years ago I had to write a Fortran
program as part of a job interview. The program problem was quite
simple, and I wrote one that checked for as many errors as I could think
of. My interviewer wanted to know what took me so long. I didn't get an
offer.

My 2 cents is that people are not really willing to pay for software
with the kinds of qualities that we talk about in this list (which is
about more than security).

Bill Anderson


Michael S Hines wrote:
> 
> a simple structure that provides for errors would go a long way...
>  
> If - then - else - on error
> Do - end - on error
> Let x = y - on error
> Let x = function() on error
> etc...   
>  
> The problem is writing code without thinking of the possible errors that
> might arise.   This forces you to think about the consequences of
> executing a command...
>  
> Where 'error' is doing something intelligent when the original command
> doesn't work...   
>  
> Just a brainstorm....... any merit to it?
>  
> Mike Hines
> mshines at purdue.edu <mailto:mshines at purdue.edu>
> 
> *From:* sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org] *On Behalf Of *Ed Reed (Aesec)
> *Sent:* Wednesday, August 30, 2006 1:17 PM
> *To:* sc-l at securecoding.org
> *Subject:* [SC-L] e: How can we stop the spreading insecure coding
> examples at, training classes, etc.?
> 
>> Message: 1
>> Date: Tue, 29 Aug 2006 15:48:17 -0400
>> From: pmeunier at purdue.edu <mailto:pmeunier at purdue.edu>
>> Subject: Re: [SC-L] How can we stop the spreading insecure coding
>> 	examples	at training classes, etc.?
>> To: "Wall, Kevin" <Kevin.Wall at qwest.com> <mailto:Kevin.Wall at qwest.com>
>> Cc: SC-L at securecoding.org <mailto:SC-L at securecoding.org>
>> Message-ID: <1156880897.44f49a01620aa at webmail.purdue.edu> <mailto:1156880897.44f49a01620aa at webmail.purdue.edu>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Quoting "Wall, Kevin" <Kevin.Wall at qwest.com> <mailto:Kevin.Wall at qwest.com>:
>>
>>
>>   
>>> I think that this practice of leaving out the "security
>>> details" to just make the demo code short and sweet has got
>>> to stop. Or minimally, we have to make the code that people
>>> copy-and-paste from have all the proper security checks even
>>> if we don't cover them in training. If we're lucky, maybe
>>> they won't delete them when the re-use the code.
>>>     
>> I agree, and would like to extend it: security should be discussed *at the same
>> time* that a topic is.  Teaching security in a separate class, like I have been
>> doing, reaches only a fraction of the audience, and reinforces an attitude of
>> security as an afterthought, or security as an option.  Comments in the code
>> should explain (or refer to explanations of) why changing or deleting those
>> lines is a bad idea.  
>>
>> However, I'm afraid that it would irritate students, and make security the new
>> "grammar and spelling" for which points are deducted from "perfectly valid
>> write-ups" (i.e., "it's my ideas that count, not how well I spell").  
> The same used to be said about unstructured programming examples
> (computed gotos, spaghetti code, multiple entry and exit points from
> functions, etc).  We got past it.
> 
> We need a similar revolution in thought with regard to security, and
> some one to take the lead on providing clear, crisp examples of coding
> style that is more secure by its nature.  I don't have one handy - but
> that's my wish.
> 
> Ed
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php

From tholleb at teknowledge.com  Wed Aug 30 15:46:08 2006
From: tholleb at teknowledge.com (Tim Hollebeek)
Date: Wed, 30 Aug 2006 12:46:08 -0700
Subject: [SC-L] Coding with errors in mind - a solution?
In-Reply-To: <200608301807.k7UI7SVD021973@mailhub128.itcs.purdue.edu>
Message-ID: <200608301952.k7UJq4cM047048@ratsass.krvw.com>


What you've proposed are exceptions.  They do help (some) in separating
the normal logic from error handling, but:

(1) they often leave the job "half done" which has its own risks.
    writing exception safe code can be more of a nightmare than error
checking.

(2) in many languages, you can't retry or resume the faulting code.
    Exceptions are really far less useful in this case.

(3) you usually end up with some "generic" clean up code, which generally
    hides more errors than it solves.

Tim Hollebeek
Research Scientist
Teknowledge, Corp.

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Michael S Hines
> Sent: Wednesday, August 30, 2006 11:07 AM
> To: sc-l at securecoding.org
> Subject: [SC-L] Coding with errors in mind - a solution?
> 
> a simple structure that provides for errors would go a long way... 
>  
> If - then - else - on error
> Do - end - on error
> Let x = y - on error
> Let x = function() on error
> etc...    
>  
> The problem is writing code without thinking of the possible 
> errors that might arise.   This forces you to think about the 
> consequences of executing a command...
>  
> Where 'error' is doing something intelligent when the 
> original command doesn't work...    
>  
> Just a brainstorm....... any merit to it?
>  
> Mike Hines
> mshines at purdue.edu
> 
> ________________________________
> 
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Ed Reed (Aesec)
> Sent: Wednesday, August 30, 2006 1:17 PM
> To: sc-l at securecoding.org
> Subject: [SC-L] e: How can we stop the spreading insecure 
> coding examples at, training classes, etc.?
> 
> 
> 
> 	Message: 1
> 	Date: Tue, 29 Aug 2006 15:48:17 -0400
> 	From: pmeunier at purdue.edu
> 	Subject: Re: [SC-L] How can we stop the spreading 
> insecure coding
> 		examples	at training classes, etc.?
> 	To: "Wall, Kevin" <Kevin.Wall at qwest.com> 
> <mailto:Kevin.Wall at qwest.com> 
> 	Cc: SC-L at securecoding.org
> 	Message-ID: 
> <1156880897.44f49a01620aa at webmail.purdue.edu> 
> <mailto:1156880897.44f49a01620aa at webmail.purdue.edu> 
> 	Content-Type: text/plain; charset=ISO-8859-1
> 	
> 	Quoting "Wall, Kevin" <Kevin.Wall at qwest.com> 
> <mailto:Kevin.Wall at qwest.com> :
> 	
> 	
> 	  
> 
> 		I think that this practice of leaving out the "security
> 		details" to just make the demo code short and 
> sweet has got
> 		to stop. Or minimally, we have to make the code 
> that people
> 		copy-and-paste from have all the proper 
> security checks even
> 		if we don't cover them in training. If we're 
> lucky, maybe
> 		they won't delete them when the re-use the code.
> 		    
> 
> 	
> 	I agree, and would like to extend it: security should 
> be discussed *at the same
> 	time* that a topic is.  Teaching security in a separate 
> class, like I have been
> 	doing, reaches only a fraction of the audience, and 
> reinforces an attitude of
> 	security as an afterthought, or security as an option.  
> Comments in the code
> 	should explain (or refer to explanations of) why 
> changing or deleting those
> 	lines is a bad idea.  
> 	
> 	However, I'm afraid that it would irritate students, 
> and make security the new
> 	"grammar and spelling" for which points are deducted 
> from "perfectly valid
> 	write-ups" (i.e., "it's my ideas that count, not how 
> well I spell").  
> 
> The same used to be said about unstructured programming 
> examples (computed gotos, spaghetti code, multiple entry and 
> exit points from functions, etc).  We got past it.
> 
> We need a similar revolution in thought with regard to 
> security, and some one to take the lead on providing clear, 
> crisp examples of coding style that is more secure by its 
> nature.  I don't have one handy - but that's my wish.
> 
> Ed
> 
> 



From pmeunier at cerias.purdue.edu  Wed Aug 30 16:46:34 2006
From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Wed, 30 Aug 2006 16:46:34 -0400
Subject: [SC-L] Coding with errors in mind - a solution?
In-Reply-To: <200608301807.k7UI7SVD021973@mailhub128.itcs.purdue.edu>
Message-ID: <C11B716A.14D8A%pmeunier@cerias.purdue.edu>

Worse is when it works in unintended ways without producing an error.  The
code has to detect whenever something doesn't match a white list of expected
program states and inputs.  I think that in example code, the detection is
more important than the subsequent handling because the handling will vary
depending on the exact application requirements and framework.  The
detection is where contracts and correctness are verified, and I'd like to
leave the handling of violations to some "law enforcement" module, so to
speak.

Perhaps a "good enough" approach for teaching would be to raise an exception
(or use assert statements for languages that don't have exceptions) whenever
a problem is detected, and leave it at that.  This way, the handling of the
exception (logging, UI, aftermath, etc...) doesn't bloat the code and
distract from the main subject, yet all unsafe conditions and errors would
be highlighted and caught.  It's not revolutionary, but it's better than
what we have now.  Would it be good enough?  I can picture people deleting
those assert statements that just make their programs crash ;)

Pascal Meunier



On 8/30/06 2:07 PM, "Michael S Hines" <mshines at purdue.edu> wrote:

> a simple structure that provides for errors would go a long way...
>  
> If - then - else - on error
> Do - end - on error
> Let x = y - on error
> Let x = function() on error
> etc...    
>  
> The problem is writing code without thinking of the possible errors that
> might arise.   This forces you to think about the consequences of executing
> a command...
>  
> Where 'error' is doing something intelligent when the original command
> doesn't work...  
>  
> Just a brainstorm....... any merit to it?
>  
> Mike Hines
> mshines at purdue.edu
> 
>   _____  
> 
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Ed Reed (Aesec)
> Sent: Wednesday, August 30, 2006 1:17 PM
> To: sc-l at securecoding.org
> Subject: [SC-L] e: How can we stop the spreading insecure coding examples
> at, training classes, etc.?
> 
> 
> 
> Message: 1
> 
> Date: Tue, 29 Aug 2006 15:48:17 -0400
> 
> From: pmeunier at purdue.edu
> 
> Subject: Re: [SC-L] How can we stop the spreading insecure coding
> 
> examples at training classes, etc.?
> 
> To: "Wall, Kevin"  <mailto:Kevin.Wall at qwest.com> <Kevin.Wall at qwest.com>
> 
> Cc: SC-L at securecoding.org
> 
> Message-ID:  <mailto:1156880897.44f49a01620aa at webmail.purdue.edu>
> <1156880897.44f49a01620aa at webmail.purdue.edu>
> 
> Content-Type: text/plain; charset=ISO-8859-1
> 
> 
> 
> Quoting "Wall, Kevin"  <mailto:Kevin.Wall at qwest.com> <Kevin.Wall at qwest.com>:
> 
> 
> 
> 
> 
>   
> 
> I think that this practice of leaving out the "security
> 
> details" to just make the demo code short and sweet has got
> 
> to stop. Or minimally, we have to make the code that people
> 
> copy-and-paste from have all the proper security checks even
> 
> if we don't cover them in training. If we're lucky, maybe
> 
> they won't delete them when the re-use the code.
> 
>     
> 
> 
> 
> I agree, and would like to extend it: security should be discussed *at the
> same
> 
> time* that a topic is.  Teaching security in a separate class, like I have
> been
> 
> doing, reaches only a fraction of the audience, and reinforces an attitude
> of
> 
> security as an afterthought, or security as an option.  Comments in the code
> 
> should explain (or refer to explanations of) why changing or deleting those
> 
> lines is a bad idea.
> 
> 
> 
> However, I'm afraid that it would irritate students, and make security the
> new
> 
> "grammar and spelling" for which points are deducted from "perfectly valid
> 
> write-ups" (i.e., "it's my ideas that count, not how well I spell").
> 
> The same used to be said about unstructured programming examples (computed
> gotos, spaghetti code, multiple entry and exit points from functions, etc).
> We got past it.
> 
> We need a similar revolution in thought with regard to security, and some
> one to take the lead on providing clear, crisp examples of coding style that
> is more secure by its nature.  I don't have one handy - but that's my wish.
> 
> Ed
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php



From secureCoding2dave at davearonson.com  Wed Aug 30 17:52:37 2006
From: secureCoding2dave at davearonson.com (Dave Aronson)
Date: Wed, 30 Aug 2006 17:52:37 -0400
Subject: [SC-L] Coding with errors in mind - a solution?
In-Reply-To: <44F5E140.9000008@acm.org>
References: <200608301807.k7UI7SVD021973@mailhub128.itcs.purdue.edu>
	<44F5E140.9000008@acm.org>
Message-ID: <44F608A5.5020801@davearonson.com>

William L. Anderson wrote:

> Years ago I had to write a Fortran
> program as part of a job interview. The program problem was quite
> simple, and I wrote one that checked for as many errors as I could think
> of. My interviewer wanted to know what took me so long. I didn't get an
> offer.

Years ago (probably not as many), I had to write a C program for a job 
interview.  I also had it test for practically every error I could think 
of, mainly input format errors.  I did get the offer, but I was told 
that the company placed such a premium on performance (it was telephony 
stuff) that I should not be quite so thorough on the errorchecking. 
Silly me, I had thought that they would also value reliability....

> My 2 cents is that people are not really willing to pay for software
> with the kinds of qualities that we talk about in this list (which is
> about more than security).

Well, *most* people anyway.  The avionics, medical, and suchlike fields 
are quite another story.

> Bill Anderson

Is this perchance the Bill Anderson who was my "great grandboss" until 
he left BAE for Cryptek?

-- 
Dave Aronson
http://www.davearonson.com/
"Specialization is for insects." -Heinlein

From Kevin.Wall at qwest.com  Thu Aug 31 00:56:13 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Wed, 30 Aug 2006 23:56:13 -0500
Subject: [SC-L] How can we stop the spreading insecure coding
	examplesattraining classes, etc.?
Message-ID: <CF8B26B8B49184429CB084616B0019300244E8F8@itomae2km05.AD.QINTRA.COM>

Tim Hollebeek writes...

> Really, the root of the problem is the fact that the simple version
> is short and easy to understand, and the secure version is five
> times longer and completely unreadable.  While there always is some
> additional complexity inherent in a secure version, it is nowhere
> near as bad as current toolkits make it seem.

I would say that secure versions that are *not* well thought out
(particularly where security wasn't part of the original design)
may tend to be FIVE times longer, but I don't think that's the
typical case with code that is well designed. These security
checks can be be modularized and reused like most other code.
However, it may very well be that it is five times more
difficult to develop the examples in the first place though,
and THAT'S probably a major reason that we don't see it
more often in example code.

> Demo code generally demonstrates some fairly powerful capability;
> the reason it is often short and sweet is because lots of effort
> has gone into making it possible to do useful things with minimal
> effort.  Unfortunately, it is often the case that much less effort
> has gone into making it possible to do the same thing securely, so
> that code is quite a bit longer.  You're right, if there was more
> of a pushback against broken demo code, maybe more effort would go
> into making it easy to do things securely, instead of insecurely.

Well, I'm going to start pushing back when I can. Tomorrow I get
the chance to bend the ear of some security folks from the
Live.com site.  I'm definitely going to be letting them know
of my dissatisfaction wrt recent MS Atlas training and asking
what I can do about it (other than completing the training
evaluation). Every little bit helps.

As Ed Reed pointed out, as an industry we did manage to get
rid of computed gotos, spaghetti code, etc., so maybe there's
hope. (But the pessimist in me says that it's probably easier
to get people to _stop_ doing some poor practice than to start
doing some good practice. I hope I'm wrong there.)-:

For the moment, perhaps all we can do is try to publically
shame them and bring about peer presure that way. I dunno.
I think it's primarilly a people problem rather than simply
a technological one, which is why it's so hard to solve.
So while doing things like showing people secure coding
idioms and secure design patterns (ala Marcus Schumacher)
will only have minor impact until there is some major
attitude change with both developers and upper management.

> I think part of the problem is that people have fallen into the
> trap of thinking that security is supposed to be hard and that
> checking all your errors is supposed to bloat your code by a factor
> of five, instead of wondering why library functions are designed
> in such a way that omitting complex logic around them fails in an
> insecure way.  Secure code can be short and sweet, too, just not
> with most of the languages and tools that are currently popular.

That's definitely a large part of it. Historically, most
libraries haven't taken much of a security slant unless they've
been crypto related. Most often, they first become well
entrenched, and *then* there's an outpour of security
vulnerabilites discovered as the library usage builds up
a critical mass of usage. E.g., libc was this way. It wasn't
until the Morris Internet worm in 1988 that people really
started paying much attention to libc security issues. By
that time libc was pretty much everywhere and what's worse,
there wasn't really any viable alternative unless you wanted
to roll your own. (That was long before GNU was prevalent.)
And yes, buffer overflows were known very early, before Unix/C
were widespread. But it was a different world then.

> This is an old, old problem.  strcpy is insecure, and any code
> involving strncpy or a length check will be longer and/or more
> complex.  But this is really just an artifact of the fact that
> buffers don't know their own length, making an additional check
> necessary.  There is no reason why the secure version couldn't
> have been just as short and sweet, it just wasn't done.

Or when strcpy() and its ilk were originally written, no one
was concerned about buffer overflows...they were more concerned
with program speed and size. The world changes. IMO, if you
are still writing in a unsafe language like C or C++ when
you don't really have to and are only using it because
that's ALL YOU KNOW, then someone should take away your
keyboard. Obviously there are legitimate reasons for using
C/C++ and other "pointy" languages, but those reasons are
holding less and less water every day. In the security class
I've taught for the past 4.5 yrs or so, one of the things I
tell my students is, "if you have a choice, select a 'safe'
language like Java or C# where you don't need to worry about
buffer overflows or heap corruption. Not only is it safer,
but it is also likely to improve your productivity."

But at this point, I'd be (somewhat) okay with those showing
example code while instructing to show it WITHOUT proper
the security checks AS LONG AS: 
        1) They mention that these checks have been omitted to
	   make the example code simpler to follow in the alotted
	   time and emphasize that if you even think about
	   using any of these examples in production code
           without those security checks then not only are you
	   a fool, but you should have your fingers amputated
           so you can no longer code again. 
        2) The distributed code (whether from a web/ftp site or 
           on a CD/DVD) has ALL the proper security codes checks
           in place and also a comment warning not to remove
           them.  (Gee, could we come up with a version of
	   something like GPL that would prohibit removing
           certain code fragments? Any lawyers out there?)
           For code that is likely to be used within IDEs,
           perhaps "hints" could be given in the code to the
           IDE that allow the code (but not the warning comment)
	   to be hidden via collapsing, etc.

For live instruction, I think that this is a reasonable
compromise. For the most part, that leaves the issue of printed 
matter. Arguably there's merit to both side's argument. There, 
I would propose that the security checks are left in UNLESS 
the example is long and there is demo code WITH the ALL security 
checks on an accompanying CD/DVD at the back of the book...the 
assumption being is that most will copy the code from the CD 
rather than typing it in or scanning it and then using OCR 
to convert it to text. There no doubt would be exceptions to that, 
but I think if everyone practiced this, then it would at least 
get us a lot farther along than we are now. 

Also, perhaps we, as a group could start posting what we consider
to be GOOD (security-worthy) examples and contrasting that with
POOR (insecure) examples. I'm not sure where we'd put them.
We'd need a repository and some way to reasonably search through
them.

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.


From peter.amey at praxis-his.com  Thu Aug 31 03:19:00 2006
From: peter.amey at praxis-his.com (Peter Amey)
Date: Thu, 31 Aug 2006 08:19:00 +0100
Subject: [SC-L] How can we stop the spreading insecure coding
 examplesattraining classes, etc.?
Message-ID: <4BF0455B353E524FBEA15C3A490F7DFE433DEC@EVS01.praxis.local>

 

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Tim Hollebeek
> Sent: 30 August 2006 18:23
> To: 'Wall, Kevin'; SC-L at securecoding.org
> Subject: Re: [SC-L] How can we stop the spreading insecure 
> coding examplesattraining classes, etc.?
> 
> 
> Really, the root of the problem is the fact that the simple 
> version is short and easy to understand, and the secure 
> version is five times longer and completely unreadable.  
> While there always is some additional complexity inherent in 
> a secure version, it is nowhere near as bad as current 
> toolkits make it seem.
> 

No, the root cause of the problem is the use of inadequate notations so
that we have to make secure versions 5 times as long in order to
overcome those inadequacies.  From my experience a typical secure SPARK
implementation (which we have proved to be free from buffer overflow,
numeric range violation etc.) is no longer or more complex than its
simple version.

Peter


**********************************************************************

This email is confidential and intended solely for the use of the individual to whom it is addressed.  If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited.  If you have received this email in error please contact the sender.  Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis High Integrity Systems Ltd (Praxis HIS). 

 Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis HIS or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof.  The IT Department at Praxis HIS can be contacted at it.support at praxis-his.com

**********************************************************************



From gem at cigital.com  Thu Aug 31 08:29:56 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 31 Aug 2006 08:29:56 -0400
Subject: [SC-L] How can we stop the spreading insecure
	codingexamplesattraining classes, etc.?
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB742E0A@va-mail.cigital.com>

>as an industry we did manage to get
>rid of computed gotos, spaghetti code, etc., so maybe there's
>hope.

ever heard of exceptions?  They're basically goto plus limited state.
Spaghetti lives!

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From gem at cigital.com  Thu Aug 31 11:46:07 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 31 Aug 2006 11:46:07 -0400
Subject: [SC-L] How can we stop the spreading insecure
	codingexamplesattraining classes, etc.?
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB742E2D@va-mail.cigital.com>

SYNTAX ERROR ON LINE 0:
> I take exception (haha!) at having them dismissed like this.  It
sounds like
KEYWORD "(haha!)" ILLEGALLY NEGATED
PLEASE RESUBMIT ARTICLE

gem



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From pmeunier at cerias.net  Thu Aug 31 11:39:16 2006
From: pmeunier at cerias.net (Pascal Meunier)
Date: Thu, 31 Aug 2006 11:39:16 -0400
Subject: [SC-L] How can we stop the spreading insecure
 codingexamplesattraining classes, etc.?
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB742E0A@va-mail.cigital.com>
Message-ID: <C11C7AE4.14DB6%pmeunier@cerias.net>

I take exception (haha!) at having them dismissed like this.  It sounds like
you encountered some badly written exception handling code.  Error handling
can also be really bad, where at every call layer the original error gets
filtered or translated to a point where you just know something went wrong
somewhere but have little idea what.  Then you have to trace (yuck) and
waste hours trying to identify the problem.  I'll take limited state over no
state any day (Ruby even tells you which line numbers of which files were
involved).  

Pascal

On 8/31/06 8:29 AM, "Gary McGraw" <gem at cigital.com> wrote:

>> as an industry we did manage to get
>> rid of computed gotos, spaghetti code, etc., so maybe there's
>> hope.
> 
> ever heard of exceptions?  They're basically goto plus limited state.
> Spaghetti lives!
> 
> gem
> 
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> book www.swsec.com
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 



From gem at cigital.com  Thu Aug 31 13:10:31 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 31 Aug 2006 13:10:31 -0400
Subject: [SC-L] (free) Software Security seminar next week in silicon valley
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4214AF@va-mail.cigital.com>

Hi all,

I'm going to be giving a free seminar about software security along with
Greg Rose from Qualcomm in Menlo Park on Thursday.  More about the
seminar here:
http://www.cigital.com/news/cigital_seminar.pdf

If you are in the area and you would like to attend, please drop me a
quick note.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From rcs at cert.org  Thu Aug 31 10:49:49 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Thu, 31 Aug 2006 10:49:49 -0400
Subject: [SC-L] CERT C Programming Language Secure Coding Standard
In-Reply-To: <CF8B26B8B49184429CB084616B0019300244E8CB@itomae2km05.AD.QINTRA.COM>
References: <CF8B26B8B49184429CB084616B0019300244E8CB@itomae2km05.AD.QINTRA.COM>
Message-ID: <44F6F70D.6080509@cert.org>


I would like to suggest an approach to solving Kevin's problem of "How
can we stop the spreading insecure coding examples at training classes,
etc.?"

The CERT/CC has just deployed a new web site dedicated to developing
secure coding standards for the C programming language, C++, and
eventually other programming language.  Each rule and recommendation
contains at least one non-compliant coding example (the sort of thing
you are likely to see in a poor training class) and at least one safe,
secure "compliant solution" that shows how you can do the same thing safely.

We are depending on the active involvement of the secure coding
community (you) and relevant standards bodies to make this effort a
success.  I invite you to participate in this effort by reviewing
content on the web site and providing comments, or by contributing new
rules and recommendations for secure c coding.  These can be sent to me
directly or to secure-coding at cert dot com.

I am attaching a press-release like article we wrote below to announce
the effort.  There is also a rationale section on the web site that
provides more details as to what we are doing and why.

Thanks,
rCs

-------------------

The Carnegie Mellon Software Engineering Institute (SEI) CERT? Program
has deployed a secure coding Web site at www.securecoding.cert.org to
cooperate with the software development community in codifying a
practical and effective set of secure coding practices for popular
programming languages. These coding practices can then be used by
software developers to eliminate vulnerabilities before software is
operationally deployed.

The purpose of this project is that the practices can be used by
developers for professional development and as the basis for
organizational coding standards supporting the quality of their products.

Jeffrey Carpenter, manager of the CERT Coordination Center, says that
the project is part of a larger secure coding initiative within the
CERT/CC to eliminate dangerous coding practices that can result in
exploitable software vulnerabilities.  According to Carpenter, "CERT is
in a unique position to coordinate development of a set of secure coding
practices because of its long history in analyzing and responding to
software vulnerabilities."

CERT's initial efforts are focused on the development of secure coding
practices for the C and C++ programming languages. CERT senior
vulnerability analyst Robert Seacord is leading the secure coding
initiative. Seacord is a leading authority on secure coding, author of
the book Secure Coding in C and C++ [Seacord 05], and technical expert
for the ISO/IEC JTC1/SC22/WG14 international standardization working
group for the programming language C.

"C and C++ were selected because a large percentage of critical
infrastructures are developed and maintained using these programming
languages," Seacord says. "C and C++ are popular and viable languages
although they have characteristics that make them prone to security flaws."

"Today's dependency on networked software systems has been matched by an
increase in the number of attacks against governments, corporations,
educational institutions, and individuals. These attacks result in the
loss and compromise of sensitive data, system damage, lost productivity,
and financial loss," says Seacord. To address this growing threat, the
introduction of software vulnerabilities during development and ongoing
maintenance must be significantly reduced, if not eliminated.

CERT recognizes that there are a number of available resources, both
online and in print, containing coding guidelines, best practices,
suggestions, and tips. The Motor Industry Software Reliability
Association (MISRA) developed guidelines for the use of the C language
in critical systems [MISRA 04], and more recently the U.S. Department of
Homeland Security launched its Build Security In web site
(https://buildsecurityin.us-cert.gov) to promote the codification of
practices and rules. These sources, however, do not provide a
prescriptive set of secure coding practices that can be uniformly
applied in the development of a software system.

"Without secure coding practices, software vulnerability reports are
likely to continue on an upward trend," Seacord says. "At CERT/CC, we
have had nearly 4,000 vulnerabilities reported in the first half of
2006. To stop the threats, we need to develop secure software from the
outset."

The secure coding practices proposed by CERT are based on standard
language versions as defined by official or de facto standards
organizations such as ISO/IEC. CERT is not an internationally recognized
standards body, but plans to work with organizations such as ISO/IEC to
advance the state of the practice in secure coding.  The ISO/IEC
JTC1/SC22 WG14 international standardization working group for the
programming language C, for example, has offered to provide direction in
the development of the C language secure coding practices and to review
and comment on drafts of the informal CERT standard.

According to WG14 convener John Benito, "The secure coding standard is
going in the correct direction, and I have confidence the final product
will be useful to the community."

CERT is also working with standards groups, such as the ISO/IEC working
group on Guidance for Avoiding Vulnerabilities through Language Use
(OWGV).  While the ISO/IEC group is working on providing
language-independent guidance, the CERT effort is working on developing
and consolidating the language-specific guidance that provides the
foundations for the ambitious goals of OWGV.

Jim Moore, convener of OWGV, states that "CERT's efforts in identifying
and documenting secure coding practices for C and C++ will contribute to
the standardization of these practices and advance the goals of the OWGV."

Community Involvement

The success of the secure coding standards depends largely on the active
involvement of members of the secure software and C and C++ development
communities. Rules and recommendations for each coding practice are
solicited from the communities involved in the development and
application of each programming language, including the formal or de
facto standard bodies responsible for the documented standard.

These rules and recommendations are edited by CERT senior members of the
technical staff for content and style, and placed in Secure Coding
Standards Web site for comment and review. The user community is invited
to discuss and comment on the publicly posted content. Once a consensus
develops that the rule or recommendation is appropriate and correct, the
final rule is incorporated into the coding standard.

Once practices are documented, tools can be developed or modified to
verify compliance. Compliant software systems may then be certified as
compliant by a properly authorized certification body. Seacord also
envisions a training and development program to educate software
professionals regarding the appropriate application of secure coding
practices.

The development of secure coding practices is a necessary step to stem
the ever-increasing threat from software vulnerabilities. CERT's goal is
that the enumeration of secure code practices will allow for a common
set of criteria that can be used to measure and evaluate software
development efforts.

The public can review or comment on the existing content at the secure
coding Web site or submit new ideas for secure coding practices by
e-mailing secure-coding at cert.org. Robert Seacord can be reached at
rcs at cert.org.


*******************************
[1] Seacord, R. Secure Coding in C and C++. Addison-Wesley, 2005. See
http://www.cert.org/books/secure-coding for news and errata.

[2] MISRA C: 2004 Guidelines for the use of the C language in Critical
systems. MIRA Limited. Warsickshire, UK. October 2004. ISBN 0 9524156.




-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC

Work: 412-268-7608
FAX: 412-268-6989

From pmeunier at cerias.net  Thu Aug 31 15:43:34 2006
From: pmeunier at cerias.net (Pascal Meunier)
Date: Thu, 31 Aug 2006 15:43:34 -0400
Subject: [SC-L] Coding with errors in mind - a solution?
In-Reply-To: <200608301952.k7UJq4cM047048@ratsass.krvw.com>
Message-ID: <C11CB426.14DCE%pmeunier@cerias.net>




On 8/30/06 3:46 PM, "Tim Hollebeek" <tholleb at teknowledge.com> wrote:

> 
> What you've proposed are exceptions.  They do help (some) in separating
> the normal logic from error handling, but:
> 
> (1) they often leave the job "half done" which has its own risks.
>     writing exception safe code can be more of a nightmare than error
> checking.

I can't help noticing...  In Ruby there's an "ensure" clause that allows you
to bring closure to half-done operations.  Perhaps your point is that some
languages have poor exception support, just like some languages don't
provide safe string handling functions?

> 
> (2) in many languages, you can't retry or resume the faulting code.
>     Exceptions are really far less useful in this case.

See above.  (Yes, Ruby supports retrying).

> 
> (3) you usually end up with some "generic" clean up code, which generally
>     hides more errors than it solves.

I don't think that's fair.  Yes, you can write poor exception handling code,
but it's far easier to simply ignore or overlook errors or write poor error
handling code to the point where the error is effectively ignored (or
"hidden") or the cause of the error becomes unidentifiable.  Exceptions
allow me to reduce code duplication (and lower the chance of inconsistent
treatment and bugs), simplify the code (which makes it easier to understand
and therefore audit) as well as handle problems at an appropriate layer in
the code. 

I'm not saying that exceptions are always the best way to handle things, but
they can be part of good programming practices.

Pascal Meunier

> 
> Tim Hollebeek
> Research Scientist
> Teknowledge, Corp.
> 
>> -----Original Message-----
>> From: sc-l-bounces at securecoding.org
>> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Michael S Hines
>> Sent: Wednesday, August 30, 2006 11:07 AM
>> To: sc-l at securecoding.org
>> Subject: [SC-L] Coding with errors in mind - a solution?
>> 
>> a simple structure that provides for errors would go a long way...
>>  
>> If - then - else - on error
>> Do - end - on error
>> Let x = y - on error
>> Let x = function() on error
>> etc...    
>>  
>> The problem is writing code without thinking of the possible
>> errors that might arise.   This forces you to think about the
>> consequences of executing a command...
>>  
>> Where 'error' is doing something intelligent when the
>> original command doesn't work...
>>  
>> Just a brainstorm....... any merit to it?
>>  
>> Mike Hines
>> mshines at purdue.edu
>> 
>> ________________________________
>> 
>> From: sc-l-bounces at securecoding.org
>> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Ed Reed (Aesec)
>> Sent: Wednesday, August 30, 2006 1:17 PM
>> To: sc-l at securecoding.org
>> Subject: [SC-L] e: How can we stop the spreading insecure
>> coding examples at, training classes, etc.?
>> 
>> 
>> 
>> Message: 1
>> Date: Tue, 29 Aug 2006 15:48:17 -0400
>> From: pmeunier at purdue.edu
>> Subject: Re: [SC-L] How can we stop the spreading
>> insecure coding
>> examples at training classes, etc.?
>> To: "Wall, Kevin" <Kevin.Wall at qwest.com>
>> <mailto:Kevin.Wall at qwest.com>
>> Cc: SC-L at securecoding.org
>> Message-ID: 
>> <1156880897.44f49a01620aa at webmail.purdue.edu>
>> <mailto:1156880897.44f49a01620aa at webmail.purdue.edu>
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> Quoting "Wall, Kevin" <Kevin.Wall at qwest.com>
>> <mailto:Kevin.Wall at qwest.com> :
>> 
>> 
>>  
>> 
>> I think that this practice of leaving out the "security
>> details" to just make the demo code short and
>> sweet has got
>> to stop. Or minimally, we have to make the code
>> that people
>> copy-and-paste from have all the proper
>> security checks even
>> if we don't cover them in training. If we're
>> lucky, maybe
>> they won't delete them when the re-use the code.
>>    
>> 
>> 
>> I agree, and would like to extend it: security should
>> be discussed *at the same
>> time* that a topic is.  Teaching security in a separate
>> class, like I have been
>> doing, reaches only a fraction of the audience, and
>> reinforces an attitude of
>> security as an afterthought, or security as an option.
>> Comments in the code
>> should explain (or refer to explanations of) why
>> changing or deleting those
>> lines is a bad idea.
>> 
>> However, I'm afraid that it would irritate students,
>> and make security the new
>> "grammar and spelling" for which points are deducted
>> from "perfectly valid
>> write-ups" (i.e., "it's my ideas that count, not how
>> well I spell"). 
>> 
>> The same used to be said about unstructured programming
>> examples (computed gotos, spaghetti code, multiple entry and
>> exit points from functions, etc).  We got past it.
>> 
>> We need a similar revolution in thought with regard to
>> security, and some one to take the lead on providing clear,
>> crisp examples of coding style that is more secure by its
>> nature.  I don't have one handy - but that's my wish.
>> 
>> Ed
>> 
>> 
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 



From mouse at Rodents.Montreal.QC.CA  Thu Aug 31 17:44:56 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Thu, 31 Aug 2006 17:44:56 -0400 (EDT)
Subject: [SC-L] How can we stop the spreading insecure
 codingexamplesattraining classes, etc.?
In-Reply-To: <C11C7AE4.14DB6%pmeunier@cerias.net>
References: <C11C7AE4.14DB6%pmeunier@cerias.net>
Message-ID: <200608312151.RAA21113@Sparkle.Rodents.Montreal.QC.CA>

>> ever heard of exceptions?  They're basically goto plus limited
>> state.  Spaghetti lives!

Not at all.  Exceptions are not like gotos; in particular, an exception
cannot be used to jump *into* a construct.  The major problems with
gotos are that they can be used to do branches that are downward or
sideways in the code parse tree (versus "structured" constructs, which
do such branches upward only).  Exceptions are upward-only branches,
and as a result don't have most of the problems gotos do.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From dinis at ddplus.net  Thu Aug 31 18:27:29 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Thu, 31 Aug 2006 18:27:29 -0400
Subject: [SC-L] OWASP Autumn Of Code 2006
Message-ID: <3c2c12adfd974fddb297f48a61827f71@ddplus.net>


		OWASP Autumn Of Code 2006

				London, United Kingdom, August 31, 2006

The Open Web Application Security Project (OWASP) is launching
today a new project aimed at financially sponsoring contributions to OWASP Projects.

The new project, called "OWASP Autumn of Code 2006", aims to
sponsor 8 individuals (4 at $3,500 USD and 4 at $5,000 USD) to work on
existing OWASP Projects. The objective is to improve the selected
projects to a the level of completeness and professionalism required
for its wide use and deployment.

There are no geographical, age or any other form of restrictions
of who can apply for an "OWASP Autumn of Code 2006" sponsorship. The
only requirement is that the candidate shows the potential to
accomplish the project's objectives and the commitment to dedicate the
time required to complete it in the allocated time frame (projects must
be completed by 31st December 2006).

Prospective candidates should visit the page https://www.owasp.org/index.php/Owasp_Autumn_Of_Code_2006 for project ideas, rules and information on how to apply.

				Project Schedule:

				 31th August - 'OWASP Autumn of Code' initiative is officially launched 

				 18th September - Deadline for project proposals

				 25th September - Publish of selected projects

				 1st October - Project starts 

				 15th October - Update of Project status on OWASP Conference in Seattle

				 15th November - Participants and to report on project status 

				 31st December - Project Completion 

The "OWASP Autumn of Code 2006" project leader is Dinis Cruz (based in London, UK) who can be contacted for further details.

				About OWASP

The Open Web Application Security Project (OWASP) is 501c3
not-for-profit foundation dedicated to enabling organizations to
develop, purchase, and maintain applications that can be trusted.
OWASP's open source projects and local chapters produce free, unbiased,
open-source documentation and tools. The OWASP community
also facilitates conferences, local chapters, papers, presentations,
and mailing lists. More information can be found at www.owasp.org.

Contacts

Dinis Cruz, OWASP Autumn of Code Project Leader,

E-mail: dinis.cruz at owasp.net 

Andrew van der Stock, OWASP Executive Director, 

E-mail: vanderaj at owasp.org

Jeff Williams, OWASP Chair (Alternative contact for all OWASP matters), 

E-mail:jeff.williams at owasp.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060831/8aaa3278/attachment.html 

From michaelslists at gmail.com  Thu Aug 31 20:05:32 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Fri, 1 Sep 2006 10:05:32 +1000
Subject: [SC-L] Coding with errors in mind - a solution?
In-Reply-To: <C11CB426.14DCE%pmeunier@cerias.net>
References: <200608301952.k7UJq4cM047048@ratsass.krvw.com>
	<C11CB426.14DCE%pmeunier@cerias.net>
Message-ID: <5e01c29a0608311705j3a2d6f25wc927097513c33790@mail.gmail.com>

On 9/1/06, Pascal Meunier <pmeunier at cerias.net> wrote:
>
>
>
> On 8/30/06 3:46 PM, "Tim Hollebeek" <tholleb at teknowledge.com> wrote:
>
> >
> > What you've proposed are exceptions.  They do help (some) in separating
> > the normal logic from error handling, but:
> >
> > (1) they often leave the job "half done" which has its own risks.
> >     writing exception safe code can be more of a nightmare than error
> > checking.
>
> I can't help noticing...  In Ruby there's an "ensure" clause that allows you
> to bring closure to half-done operations.  Perhaps your point is that some
> languages have poor exception support, just like some languages don't
> provide safe string handling functions?

His point, I think, is that if you wrap a series of statements in an
try/catch block, you might not roll back every statement you needed
to, or checked appropriate conditions.

For example:
try {
 openFile();
 getData();
 writeToFile();
 setSomeFlag()
 moveFile();
 deleteTempThings();
} catch(Exception e){
 ...
}

Now obviously that's a statement that could be written far better, but
the point is that with the lazy/bad/accidental-bug-producing
programmer it might be common.


> >
> > (2) in many languages, you can't retry or resume the faulting code.
> >     Exceptions are really far less useful in this case.
>
> See above.  (Yes, Ruby supports retrying).
>
> >
> > (3) you usually end up with some "generic" clean up code, which generally
> >     hides more errors than it solves.
>
> I don't think that's fair.  Yes, you can write poor exception handling code,
> but it's far easier to simply ignore or overlook errors or write poor error
> handling code to the point where the error is effectively ignored (or
> "hidden") or the cause of the error becomes unidentifiable.  Exceptions
> allow me to reduce code duplication (and lower the chance of inconsistent
> treatment and bugs), simplify the code (which makes it easier to understand
> and therefore audit) as well as handle problems at an appropriate layer in
> the code.

Exceptions simplify the code? I don't think so. They also don't reduce
code duplication [per se] you need to add extra functions, etc, to do
that.


> I'm not saying that exceptions are always the best way to handle things, but
> they can be part of good programming practices.

They _can_ be, but often aren't.


> Pascal Meunier

-- mic

From pmeunier at cerias.net  Fri Sep  1 10:41:23 2006
From: pmeunier at cerias.net (Pascal Meunier)
Date: Fri, 01 Sep 2006 10:41:23 -0400
Subject: [SC-L] Coding with errors in mind - a solution?
In-Reply-To: <5e01c29a0608311705j3a2d6f25wc927097513c33790@mail.gmail.com>
Message-ID: <C11DBED3.14E01%pmeunier@cerias.net>




On 8/31/06 8:05 PM, "mikeiscool" <michaelslists at gmail.com> wrote:

> On 9/1/06, Pascal Meunier <pmeunier at cerias.net> wrote:
>> 
>> 
>> 
>> On 8/30/06 3:46 PM, "Tim Hollebeek" <tholleb at teknowledge.com> wrote:
>> 
>>> 
>>> What you've proposed are exceptions.  They do help (some) in separating
>>> the normal logic from error handling, but:
>>> 
>>> (1) they often leave the job "half done" which has its own risks.
>>>     writing exception safe code can be more of a nightmare than error
>>> checking.
>> 
>> I can't help noticing...  In Ruby there's an "ensure" clause that allows you
>> to bring closure to half-done operations.  Perhaps your point is that some
>> languages have poor exception support, just like some languages don't
>> provide safe string handling functions?
> 
> His point, I think, is that if you wrap a series of statements in an
> try/catch block, you might not roll back every statement you needed
> to, or checked appropriate conditions.
> 
> For example:
> try {
>  openFile();
>  getData();
>  writeToFile();
>  setSomeFlag()
>  moveFile();
>  deleteTempThings();
> } catch(Exception e){
>  ...
> }
> 
> Now obviously that's a statement that could be written far better, but
> the point is that with the lazy/bad/accidental-bug-producing
> programmer it might be common.

Ah, yes, I can see a bad (or under pressure) programmer lumping together the
handling of exceptions that should be handled separately, or making just one
giant try block so when there's an exception, even if you specify the type
there's still ambiguity as to where it came from and therefore can't handle
it properly.  That could be quite a mess.  Thanks.

>Exceptions simplify the code? I don't think so. They also don't reduce
>code duplication [per se] you need to add extra functions, etc, to do
>that.

They can simplify the code because
-as previously mentioned by Tim, they separate error handling from normal
logic, so the code is easier to read (it is simpler from a human reader's
perspective).  I have found bugs in my own code by going from error handling
to exceptions -- it made the mistake plain to see.

-if an exception is handled several call layers above, you don't have to
copy/translate and relay the error at each layer, with the attached loss of
context and possible translation mistakes (error #3 in one layer/module may
mean something different in another...).  So, there's less (duplicated)
code.

-It is common (and bad, IMO) practice for errors to be signified to callers
by returning an out of range or different type (or null) value when
something else is semantically expected.  The result is that if the caller
forgets to check for errors, a bad value is used by the remaining code.  If
the caller checks for errors, an often used way to do this is to tuck the
assignment inside an if statement.  Then, even if the error is checked for,
subsequent code may assume that the assigned variable still contains a
semantically correct value (e.g., the previous value) which causes bugs and
possibly vulnerabilities (I remember seeing an instance of this).  So (and
for additional reasons that could be chalked up to coding style
preferences), a good practice is to decouple the error channel from the data
channel (e.g., pass additional variables by reference or use exceptions as
the error channel).  By passing a variable by reference, its value can be
left intact if there's an error in the called function (I *really* like to
have variables that always contain a semantically correct, or valid, range
and type).  Obviously passing additional variables by reference up and down
calling chains complicates the code, whereas exceptions are transparent.

As with most everything else, all this (simplifying the code and reducing
code duplication) depends on having a programmer with coding style and
skills that can take advantage of the provided opportunities.

Pascal



From dcrocker at eschertech.com  Fri Sep  1 15:29:11 2006
From: dcrocker at eschertech.com (David Crocker)
Date: Fri, 1 Sep 2006 20:29:11 +0100
Subject: [SC-L] How can we stop the spreading insecure
	codingexamplesattraining classes, etc.?
In-Reply-To: <200608312151.RAA21113@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <017101c6cdfc$e8f7bb80$cb00000a@escheradmin>

Also, exceptions (unlike gotos) cannot be used to jump backward, thereby
creating hidden loops.

Used correctly, exceptions eliminate large amounts of code that would otherwise
be required to handle unexpected failures at every level in a function call
stack and propagate such failures upwards by way of return codes etc. to a point
at which some remedial action can be taken. Exceptions can certainly be misused,
but they are much better than the alternatives in many situations.

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com



-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On
Behalf Of der Mouse
Sent: 31 August 2006 22:45
To: SC-L at securecoding.org
Subject: Re: [SC-L] How can we stop the spreading insecure
codingexamplesattraining classes, etc.?


>> ever heard of exceptions?  They're basically goto plus limited state.  
>> Spaghetti lives!

Not at all.  Exceptions are not like gotos; in particular, an exception cannot
be used to jump *into* a construct.  The major problems with gotos are that they
can be used to do branches that are downward or sideways in the code parse tree
(versus "structured" constructs, which do such branches upward only).
Exceptions are upward-only branches, and as a result don't have most of the
problems gotos do.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php



From jleffler at us.ibm.com  Fri Sep  1 15:44:15 2006
From: jleffler at us.ibm.com (Jonathan Leffler)
Date: Fri, 1 Sep 2006 12:44:15 -0700
Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
In-Reply-To: <mailman.68.1157068726.4113.sc-l@securecoding.org>
Message-ID: <OF48F012A1.EB653DD3-ON882571DC.006963E5-882571DC.006C6BE8@us.ibm.com>

Pascal Meunier <pmeunier at cerias.net> wrote:
>Tim Hollebeek <tholleb at teknowledge.com> wrote:
>> (2) in many languages, you can't retry or resume the faulting code.
>>     Exceptions are really far less useful in this case.
>
>See above.  (Yes, Ruby supports retrying).

Bjorn Stroustrup discusses retrying exceptions in "Design and Evolution of 
C++" (http://www.research.att.com/~bs/dne.html).  In particular, he 
described one system where the language supported exceptions, and after 
some number of years, a code review found that there was only one 
retryable exception left - and IIRC the code review decided they were 
better off without it.  How much are retryable exceptions really used, in 
Ruby or anywhere else that supports them?

-- 
Jonathan Leffler (jleffler at us.ibm.com) 
STSM, Informix Database Engineering, IBM Information Management Division 
4100 Bohannon Drive, Menlo Park, CA 94025-1013 
Tel: +1 650-926-6921     Tie-Line: 630-6921 
          "I don't suffer from insanity; I enjoy every minute of it!" 




From leichter_jerrold at emc.com  Fri Sep  1 17:05:17 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Fri, 1 Sep 2006 17:05:17 -0400 (EDT)
Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
In-Reply-To: <OF48F012A1.EB653DD3-ON882571DC.006963E5-882571DC.006C6BE8@us.ibm.com>
References: <OF48F012A1.EB653DD3-ON882571DC.006963E5-882571DC.006C6BE8@us.ibm.com>
Message-ID: <Pine.SOL.4.61.0609011647230.8182@mental>

On Fri, 1 Sep 2006, Jonathan Leffler wrote:
| Pascal Meunier <pmeunier at cerias.net> wrote:
| >Tim Hollebeek <tholleb at teknowledge.com> wrote:
| >> (2) in many languages, you can't retry or resume the faulting code.
| >>     Exceptions are really far less useful in this case.
| >
| >See above.  (Yes, Ruby supports retrying).
| 
| Bjorn Stroustrup discusses retrying exceptions in "Design and Evolution of 
| C++" (http://www.research.att.com/~bs/dne.html).  In particular, he 
| described one system where the language supported exceptions, and after 
| some number of years, a code review found that there was only one 
| retryable exception left - and IIRC the code review decided they were 
| better off without it.  
This is an over-simplification of the story.  I may get some of the
details wrong, but....  This dates back to work done at Xerox PARC in
the late 70's-early 80's - about the same time that Smalltalk was being
developed.  There was a separate group that developed system programming
languages and workstation OS's built on them.  For a number of years,
they worked on and with a language named Mesa.  Mesa had extensive
support for exceptions, including a resumption semantics.  If you think
of exceptions as a kind of software analogue to a hardware interrupt,
then you can see why you'd expect to need resumption.  And, indeed, the
OS that they built initially used resumption in a number of places.

What was observed by the guys working on the system was that the number
of uses of resumption was declining over time.  In fact, I vaguely
remember that when they decided to go and look, they were using
resumption in exactly two places in their entire code base - OS,
compilers, windowing system, various tools.  (Exceptions were used
extensively - but resumption hardly at all.)

It's not that anyone deliberately set out to remove uses of resumption.
Rather, as the code was maintained, it repeatedly turned out that
resumption was simply the wrong semantics.  It just did not lead to
reliable code; there were better, more understandable, more robust
ways to do things that, over time and without plan, came to dominate.

Somewhere, I still have - if I could ever find it in my garage - the
paper that described this.  (It was a retrospective on the effort,
almost certainly published as one of the PARC tech reports.)

Mesa was replaced by Cedar, which was a simpler language.  (Another
lesson was that many of the very complex coercion and automatic
conversion mechanisms that Mesa weren't needed.)  I think Cedar
discarded Mesa's exception resumption semantics.  Many of the people
involved in these projects later moved to DEC SRC, where they used
the ideas from Mesa and Cedar in Modula2+ and later Modula3 - a
dramatically simpler language than its older Xerox forbearers.  It
also used exceptions heavily - but never had resumption semantics.
Much of the basic design of Java and C# goes back to Modula3.

|			  How much are retryable exceptions really used, in 
| Ruby or anywhere else that supports them?
Not only how much are they used, but how well do they work?  Remember,
if you'd look at *early* instances of Mesa code, you might well have
concluded that they were an important idea.  It may well be that for
quick one-off solutions, resumption is handy - e.g., for building
"advise"-like mechanisms to add special cases to existing code.  But as
we should all know by now, what works in-the-small and in-the-quick is
not necessarily what works when you need security/reliability/
maintainability/supportability.
							-- Jerry

From mshines at purdue.edu  Tue Sep  5 08:25:42 2006
From: mshines at purdue.edu (Michael S Hines)
Date: Tue, 5 Sep 2006 08:25:42 -0400
Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
In-Reply-To: <OF48F012A1.EB653DD3-ON882571DC.006963E5-882571DC.006C6BE8@us.ibm.com>
Message-ID: <200609051226.k85CQ0fY025937@mailhub131.itcs.purdue.edu>

That's a rather pragmatic view, isn't it?

Perhaps if other language constructs are not used, they should be removed?

OTOH - perhaps the fault is not the language but the coder of the language?

  - lack of knowledge
  - pressure to complete lines of code
  - lack of [management] focus on security
  - or 100s of other reasons not to do the right thing...

Sort of like life, isn't it?

Mike Hines

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Jonathan Leffler
Sent: Friday, September 01, 2006 3:44 PM
To: sc-l at securecoding.org
Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind'

Pascal Meunier <pmeunier at cerias.net> wrote:
>Tim Hollebeek <tholleb at teknowledge.com> wrote:
>> (2) in many languages, you can't retry or resume the faulting code.
>>     Exceptions are really far less useful in this case.
>
>See above.  (Yes, Ruby supports retrying).

Bjorn Stroustrup discusses retrying exceptions in "Design and Evolution of
C++" (http://www.research.att.com/~bs/dne.html).  In particular, he
described one system where the language supported exceptions, and after some
number of years, a code review found that there was only one retryable
exception left - and IIRC the code review decided they were better off
without it.  How much are retryable exceptions really used, in Ruby or
anywhere else that supports them?

--
Jonathan Leffler (jleffler at us.ibm.com)
STSM, Informix Database Engineering, IBM Information Management Division
4100 Bohannon Drive, Menlo Park, CA 94025-1013
Tel: +1 650-926-6921     Tie-Line: 630-6921
          "I don't suffer from insanity; I enjoy every minute of it!"



_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php



From leichter_jerrold at emc.com  Tue Sep  5 11:54:16 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Tue, 5 Sep 2006 11:54:16 -0400 (EDT)
Subject: [SC-L] Coding with errors in mind - a solution?
In-Reply-To: <C11DBED3.14E01%pmeunier@cerias.net>
References: <C11DBED3.14E01%pmeunier@cerias.net>
Message-ID: <Pine.SOL.4.61.0609051117320.17711@mental>

[Picking out one minor point:]
| [Exceptions] can simplify the code because
| -as previously mentioned by Tim, they separate error handling from normal
| logic, so the code is easier to read (it is simpler from a human reader's
| perspective).  I have found bugs in my own code by going from error handling
| to exceptions -- it made the mistake plain to see.
I agree with this ... but:

	- Many years ago, I worked in a language called BASIC PLUS.
		(This was an extension to BASIC that DEC bought along
		with the RSTS operating system.  It was actually a
		surprisingly productive environment.  But the details
		aren't really relevant here.)

	  BASIC PLUS had a simple "exception handling" approach:  You
		specified "ON ERROR <statement>", which requested that
		if any system-detected error occurred (and, in modern
		terms, BASIC PLUS was a "safe" language, so *all* errors
		were detected by the run-time system) then the given
		statement was to be executed.  Almost universally,
		<statement> was a GOTO to a particular line number.
		At that line, you had access to the particular error
		that occurred (and error number); the line number on
		which it occurred; the current state of any variables;
		and the ability to resume execution (with some funny
		limitations).  This provided exactly the separation
		of normal code flow from error handling that seems
		like a fine idea ... until you try to do anything with
		it other than logging the error and aborting at some
		high level of abstraction.

	  I wrote an incredibly hacky error handler and a function called
		FNSET() that was used essentially as follows:

		IF (FNSET(errs))
		THEN	<normal code>
		ELSE	<error path>

	  "errs" encoded the error numbers that would be handled by
		<error path>; any errors not on the list took the
		usual log-and-abort route.

	  So ... this was essentially a try/catch block (which I don't
		think I'd seen - this was in 1976 or thereabouts),
		with the odd filip that you declared the error
		conditions you handled in the "try" rather than in
		the "catch".  It worked very well, and supplanted
		the old monolithic error handlers that preceded it.

	  But notice that it moved the error handlers right up close
		to the normal operational code.  Yes, it's not as
		close as a test after every call - *some* degree of
		separation is good.  Really, what I think matters
		is that the error handling code live at the right
		semantic level relative to the code that it's
		covering.  It's fine for the try/catch to be three
		levels of call up from where the throw occurs *if
		it the semantics it reflects are those of the code
		explicitly in its try block, not the semantics
		three levels down*.  This is also what goes wrong
		with a try block containing 5 calls, whose catch
		block is then stuck with figuring out how far into
		the block we got in order to understand how to unwind
		properly.  *Those 5 calls together* form the semantic
		unit being protected, and the catch should be written
		at that level.  If it can't be, the organization of
		the code needs to be re-thought.  (Notice that in
		this case you can end up with a try/catch per function
		call.  That's a bad result:  Returning a status
		value and testing it would probably be more readable
		than all those individual try/catches!)

	- On a much broader level:  Consider the traditional place
		where "exceptions" and "errors" occur - on an assembly
		line, where the process has "bugs", which are detected
		by QA inspections (software analogue:  Assertions) which
		then lead to rework (exception handling).  In the
		manufacturing world, the lesson of the past 50 years
		or so is that *this approach is fundamentally flawed*.
		You shouldn't allow failures and then catch them later;
		you should work to make failures impossible.

	  Too much of our software effort is directed at better
		expression (try/catch) and implementation (safe
		languages, assertions, contract checking) of the
		"assume it will fail, send it back for rework"
		approach.  Much, much better is to aim for designs
		that make failure impossible to begin with.

	  Consider all the blood spilled over buffer overflows that
		occur because buffers don't know their own sizes.
		After much pain, we're fixing that ... but in many
		cases what we do is change an unchecked assertion
		(which ends up being "checked" by unrelated code
		whose invariants get tromped on) into a checked one.
		But then what do we do when the checked assertion is
		triggered?  Wouldn't it be better to grow the buffer
		dynamically so that no failure is possible at all?

	  Yes, there are always edge cases, like running out of
		memory to expand the buffer.  But (a) those (b) many
		can be very, very rare, so handled by catch-alls;
		of them can be avoided by proper design to begin
		with.  The way to handled running out of memory
		because a hacked field in a message indicates
		that some object is of a huge length is not to
		worry about elegant ways to handle out-of-memory
		conditions - it's to enforce constraints in the
		message definition and the implementation of the
		code that handles such messages.

I'm not arguing that error checking, error handling, and such are not
important.  They are and always will be.  I'm arguing that error
*prevention* - by design, by implementation of error *amelioration*
at the earliest and most appropriate semantic level - is a much
better approach.  And, yes, we need libraries and languages and tools
to support this approach - libraries and languages and tools that
don't really exist today.
							-- Jerry

From tholleb at teknowledge.com  Tue Sep  5 14:10:51 2006
From: tholleb at teknowledge.com (Tim Hollebeek)
Date: Tue, 5 Sep 2006 11:10:51 -0700
Subject: [SC-L] Coding with errors in mind - a solution?
In-Reply-To: <C11DBED3.14E01%pmeunier@cerias.net>
Message-ID: <200609051818.k85IInxq057601@ratsass.krvw.com>

 

> -----Original Message-----
> From: Pascal Meunier [mailto:pmeunier at cerias.net] 
> Sent: Friday, September 01, 2006 7:41 AM
> To: michaelslists at gmail.com
> Cc: Tim Hollebeek; sc-l at securecoding.org
> Subject: Re: [SC-L] Coding with errors in mind - a solution?
> 
> On 8/31/06 8:05 PM, "mikeiscool" <michaelslists at gmail.com> wrote:
> 
> > His point, I think, is that if you wrap a series of 
> statements in an 
> > try/catch block, you might not roll back every statement you needed 
> > to, or checked appropriate conditions.
> > 
> > For example:
> > try {
> >  openFile();
> >  getData();
> >  writeToFile();
> >  setSomeFlag()
> >  moveFile();
> >  deleteTempThings();
> > } catch(Exception e){
> >  ...
> > }
> 
> [...]
>
> Ah, yes, I can see a bad (or under pressure) programmer 
> lumping together the handling of exceptions that should be 
> handled separately, or making just one giant try block so 
> when there's an exception, even if you specify the type 
> there's still ambiguity as to where it came from and 
> therefore can't handle it properly.  That could be quite a 
> mess.  Thanks.
> 
> >Exceptions simplify the code? I don't think so. They also 
> don't reduce 
> >code duplication [per se] you need to add extra functions, 
> etc, to do 
> >that.
> 
> They can simplify the code because
> -as previously mentioned by Tim, they separate error handling 
> from normal logic, so the code is easier to read (it is 
> simpler from a human reader's perspective).

But they only really "separate" the error handling if you have
one big try block, and that can make proper diagnosis difficult.
For example, in the above case, if you get a FileNotFound exception,
did it come from openFile or moveFile?  It may be possible to
figure that out, but the extra logic will be more than you would
have had if you had just checked the return value of the call.

> -if an exception is handled several call layers above, you 
> don't have to copy/translate and relay the error at each 
> layer, with the attached loss of context and possible 
> translation mistakes (error #3 in one layer/module may mean 
> something different in another...).  So, there's less 
> (duplicated) code.

But the intervening stack frames have to be (painfully) aware of
the fact that they might terminate abruptly.  Experience has shown
that getting this right is very hard, offsetting the benefits of
being able to quickly pop back up to a frame where the error can
be handled.

> -It is common (and bad, IMO) practice for errors to be 
> signified to callers by returning an out of range or 
> different type (or null) value when something else is 
> semantically expected.

This is especially true when there is only one value available
for all errors (like zero).  GetLastError/errno is a silly
substitute for not having another 'out' parameter, justified
on the basis that sometimes you don't care what the error was.
Except that you should!

Exceptions can be useful, but they really aren't what you want for
error handling, and are often cause as many problems as they cause.

What you really want is for all the (partial) side effects of a
function to disappear when it unrolls, but that's hard to do.
Even cleanup code is tough to get right due to the fact that
(A)(B)(A^-1) != B    
(can we reboot the universe with that feature disabled?  
It causes problems all over the place ...)

That said, Windows Vista will have transactions for file system/
registry modifications, so perhaps that will make life a bit easier...

-Tim



From mouse at Rodents.Montreal.QC.CA  Tue Sep  5 14:50:46 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Tue, 5 Sep 2006 14:50:46 -0400 (EDT)
Subject: [SC-L] Coding with errors in mind - a solution?
In-Reply-To: <200609051818.k85IInxq057601@ratsass.krvw.com>
References: <200609051818.k85IInxq057601@ratsass.krvw.com>
Message-ID: <200609051854.OAA17613@Sparkle.Rodents.Montreal.QC.CA>

>> if an exception is handled several call layers above, you don't have
>> to copy/translate and relay the error at each layer, [...]
> But the intervening stack frames have to be (painfully) aware of the
> fact that they might terminate abruptly.

That's what unwind-protect is for.

What, you don't have unwind-protect?  Perhaps you need to fix that
first. :-)

Actually, I have found it not all that difficult.  I have (ab?)used
gcc's nested-function nonlocal-goto support as an error-handling
throw facility relatively often, and I've run into very few cases where
intervening stack frames have to be aware of the throw-through-them
potential, and none where I would say it was painful.  Perhaps that's
just an artifact of how I design my code....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From gunnar at arctecgroup.net  Tue Sep  5 17:29:06 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue,  5 Sep 2006 16:29:06 -0500
Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
In-Reply-To: <200609051226.k85CQ0fY025937@mailhub131.itcs.purdue.edu>
References: <200609051226.k85CQ0fY025937@mailhub131.itcs.purdue.edu>
Message-ID: <1157491746.44fdec225c315@my.visi.com>

I can't say enough good things about this interview:

Conversation with Bruce Lindsay
Design For Failure
http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=233

<snip>
BL: There are two classes of detection. One is that I looked at my own guts and
they didn?t look right, and so I say this is an error situation. The other is I
called some other component that failed to perform as requested. In either case,
I?m faced with a detected error. The first thing to do is fold your tent?that
is, put the state back so that the state that you manage is coherent. Then you
report to the guy who called you, possibly making some dumps along the way, or
you can attempt alternate logic to circumvent the exception.

In our database projects, what typically happens is it gets reported up, up, up
the chain until you get to some very high level that then says, ?Oh, I see this
as one of those really bad ones. I?m going to initiate the massive dumping now.?
When you report an error, you should classify it. You should give it a name. If
you?re a component that reports errors, there should be an exhaustive list of
the errors that you would report.

That?s one of the real problems in today?s programming language architecture for
exception handling. Each component should list the exceptions that were raised:
typically if I call you and you say that you can raise A, B, and C, but you can
call Joe who can raise D, E, and F, and you ignore D, E, and F, then I?m
suddenly faced with D, E, and F at my level and there?s nothing in your
interface that said D, E, and F errors were things you caused. That seems to be
ubiquitous in the programming and the language facilities. You are never
required to say these are all the errors that might escape from a call to me.
And that?s because you?re allowed to ignore errors. I?ve sometimes advocated
that, no, you?re not allowed to ignore any error. You can reclassify an error
and report it back up, but you?ve got to get it in the loop.
</snip>

-gp


Quoting Michael S Hines <mshines at purdue.edu>:

> That's a rather pragmatic view, isn't it?
>
> Perhaps if other language constructs are not used, they should be removed?
>
> OTOH - perhaps the fault is not the language but the coder of the language?
>
>   - lack of knowledge
>   - pressure to complete lines of code
>   - lack of [management] focus on security
>   - or 100s of other reasons not to do the right thing...
>
> Sort of like life, isn't it?
>
> Mike Hines
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Jonathan Leffler
> Sent: Friday, September 01, 2006 3:44 PM
> To: sc-l at securecoding.org
> Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
>
> Pascal Meunier <pmeunier at cerias.net> wrote:
> >Tim Hollebeek <tholleb at teknowledge.com> wrote:
> >> (2) in many languages, you can't retry or resume the faulting code.
> >>     Exceptions are really far less useful in this case.
> >
> >See above.  (Yes, Ruby supports retrying).
>
> Bjorn Stroustrup discusses retrying exceptions in "Design and Evolution of
> C++" (http://www.research.att.com/~bs/dne.html).  In particular, he
> described one system where the language supported exceptions, and after some
> number of years, a code review found that there was only one retryable
> exception left - and IIRC the code review decided they were better off
> without it.  How much are retryable exceptions really used, in Ruby or
> anywhere else that supports them?
>
> --
> Jonathan Leffler (jleffler at us.ibm.com)
> STSM, Informix Database Engineering, IBM Information Management Division
> 4100 Bohannon Drive, Menlo Park, CA 94025-1013
> Tel: +1 650-926-6921     Tie-Line: 630-6921
>           "I don't suffer from insanity; I enjoy every minute of it!"
>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>


From dave.wichers at aspectsecurity.com  Tue Sep  5 21:58:57 2006
From: dave.wichers at aspectsecurity.com (Dave Wichers)
Date: Tue, 5 Sep 2006 21:58:57 -0400
Subject: [SC-L] Reminder: 3rd Annual US OWASP AppSec Conference - Oct 16-18
	2006 - Seattle, WA
Message-ID: <B9A412898630124ABE8350F4EBD32E8411E422@mymail.aspectsecurity.com>

A reminder to everyone that early registration for the OWASP conference
in Seattle next month ends on September 21st. There is a $50 discount
for early registration.

More importantly, the block of rooms and rates at the conference hotels
are only guaranteed to be held until around that same date. After that,
the rooms and/or the conference rates may not be available.

Registration for the conference is available at:
http://guest.cvent.com/i.aspx?4W,M3,57a181da-f20b-40fb-80ef-472a647bce7b

The agenda for the conference is pretty much set at this point. Please
check it out. I hope to see many of you there. This year there are two
panels, 3 tutorials prior to the conference, and a host of new speakers
on many interesting and up and coming topics in application security.
This is the first OWASP conference to be held on the West Coast so I
hope to see lots of new faces, and many repeat attendees.

The full conference description is available at:
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006

Please contact me with any questions. Looking forward to seeing you all
there!

Thanks, Dave

p.s. I'd encourage everyone to sign up for the dinner event on Tuesday
night. These dinners are always a great way to meet lots of people
attending the conference. If you've already registered for the
conference, you can always go back and add that to your registration.

Dave Wichers, OWASP Conferences Chair
The OWASP Foundation
http://www.owasp.org 



From mshines at purdue.edu  Wed Sep  6 07:42:08 2006
From: mshines at purdue.edu (Michael S Hines)
Date: Wed, 6 Sep 2006 07:42:08 -0400
Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
In-Reply-To: <1157491746.44fdec225c315@my.visi.com>
Message-ID: <200609061142.k86BgQnQ027647@mailhub131.itcs.purdue.edu>

Oh, you mean like the calling conventions on the IBM Mainframe where a dump
produces a trace back up the call chain to the calling program(s)?  Not to
mention the trace stack kept within the OS itself for problem solving
(including system calls or SVC's as we call them on the mainframe).   And
when all else fails, there is the stand alone dump program to dump the whole
system?

Mainframes have been around for years.  It's interesting to see "open
systems" take on mainframe characteristics after all this time....

Mike Hines
Mainframe Systems Programmer

-----Original Message-----
From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
Sent: Tuesday, September 05, 2006 5:29 PM
To: Hines, Michael S.
Cc: sc-l at securecoding.org
Subject: Re: [SC-L] Retrying exceptions - was 'Coding with errors in mind'

I can't say enough good things about this interview:

Conversation with Bruce Lindsay
Design For Failure
http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=233

<snip>
BL: There are two classes of detection. One is that I looked at my own guts
and they didn't look right, and so I say this is an error situation. The
other is I called some other component that failed to perform as requested.
In either case, I'm faced with a detected error. The first thing to do is
fold your tent-that is, put the state back so that the state that you manage
is coherent. Then you report to the guy who called you, possibly making some
dumps along the way, or you can attempt alternate logic to circumvent the
exception.

In our database projects, what typically happens is it gets reported up, up,
up the chain until you get to some very high level that then says, "Oh, I
see this as one of those really bad ones. I'm going to initiate the massive
dumping now."
When you report an error, you should classify it. You should give it a name.
If you're a component that reports errors, there should be an exhaustive
list of the errors that you would report.

That's one of the real problems in today's programming language architecture
for exception handling. Each component should list the exceptions that were
raised:
typically if I call you and you say that you can raise A, B, and C, but you
can call Joe who can raise D, E, and F, and you ignore D, E, and F, then I'm
suddenly faced with D, E, and F at my level and there's nothing in your
interface that said D, E, and F errors were things you caused. That seems to
be ubiquitous in the programming and the language facilities. You are never
required to say these are all the errors that might escape from a call to
me.
And that's because you're allowed to ignore errors. I've sometimes advocated
that, no, you're not allowed to ignore any error. You can reclassify an
error and report it back up, but you've got to get it in the loop.
</snip>

-gp


Quoting Michael S Hines <mshines at purdue.edu>:

> That's a rather pragmatic view, isn't it?
>
> Perhaps if other language constructs are not used, they should be removed?
>
> OTOH - perhaps the fault is not the language but the coder of the
language?
>
>   - lack of knowledge
>   - pressure to complete lines of code
>   - lack of [management] focus on security
>   - or 100s of other reasons not to do the right thing...
>
> Sort of like life, isn't it?
>
> Mike Hines
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Jonathan Leffler
> Sent: Friday, September 01, 2006 3:44 PM
> To: sc-l at securecoding.org
> Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
>
> Pascal Meunier <pmeunier at cerias.net> wrote:
> >Tim Hollebeek <tholleb at teknowledge.com> wrote:
> >> (2) in many languages, you can't retry or resume the faulting code.
> >>     Exceptions are really far less useful in this case.
> >
> >See above.  (Yes, Ruby supports retrying).
>
> Bjorn Stroustrup discusses retrying exceptions in "Design and
> Evolution of
> C++" (http://www.research.att.com/~bs/dne.html).  In particular, he
> described one system where the language supported exceptions, and
> after some number of years, a code review found that there was only
> one retryable exception left - and IIRC the code review decided they
> were better off without it.  How much are retryable exceptions really
> used, in Ruby or anywhere else that supports them?
>
> --
> Jonathan Leffler (jleffler at us.ibm.com) STSM, Informix Database
> Engineering, IBM Information Management Division 4100 Bohannon Drive,
> Menlo Park, CA 94025-1013
> Tel: +1 650-926-6921     Tie-Line: 630-6921
>           "I don't suffer from insanity; I enjoy every minute of it!"
>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at -
> http://www.securecoding.org/list/charter.php
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>



From leichter_jerrold at emc.com  Wed Sep  6 10:07:17 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Wed, 6 Sep 2006 10:07:17 -0400 (EDT)
Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
In-Reply-To: <200609061142.k86BgQnQ027647@mailhub131.itcs.purdue.edu>
References: <200609061142.k86BgQnQ027647@mailhub131.itcs.purdue.edu>
Message-ID: <Pine.SOL.4.61.0609060939340.970@mental>

| Oh, you mean like the calling conventions on the IBM Mainframe where a dump
| produces a trace back up the call chain to the calling program(s)?  Not to
| mention the trace stack kept within the OS itself for problem solving
| (including system calls or SVC's as we call them on the mainframe).   And
| when all else fails, there is the stand alone dump program to dump the whole
| system?
| 
| Mainframes have been around for years.  It's interesting to see "open
| systems" take on mainframe characteristics after all this time....
All these obsolete ideas.  Stack tracebacks.  Feh!

Years back at Smarts, a company since acquired by the "EMC" you see in
my email address, one of the things I added to the system was a set of
signal handlers which would print a stack trace.  The way to do this was
very non-uniform:  On Solaris, you had to spawn a standalong program
(but you got a stack trace of all threads).  On HPUX, there was a
function you could call in a system library.  On AIX (you'd think IBM,
of all vendors, would do better!) and Windows, we had to write this
ourselves, with varying degrees of OS support.  We also dump - shock!
horror! - the values in all the registers.  And we (try to) produce a
core dump.

My experience has been that of crashes in the field, 90% can be fully
analyzed based on what we've written to the log file.  Of the rest, some
percentage - this is harder to estimate because the numbers are lower; -
can be fully analyzed using the core dump.  The rest basically can't be
analyzed without luck and repetition.  (I used to say 80-90% for "can be
analyzed from core file", but the number is way down now because (a)
we've gotten better at getting information into and out of the log files
- e.g., we now keep a circular buffer of messages, including those at
too low a severity level to be written to the log, and dump that as
part of the failure output); (b) the remaining problems are exactly the
ones that the current techniques fail to handle - we've fixed the
others!)
							-- Jerry


From crispin at novell.com  Wed Sep  6 18:12:07 2006
From: crispin at novell.com (Crispin Cowan)
Date: Wed, 06 Sep 2006 15:12:07 -0700
Subject: [SC-L] NDSS CFP Due September 10th
Message-ID: <44FF47B7.9000505@novell.com>

Security researchers with new results may be interested to know that the
CFP deadline for NDSS is this Sunday September 10th
http://www.isoc.org/isoc/conferences/ndss/07/cfp.shtml

NDSS is a high quality academic peer reviewed conference in computer
security. Traditionally focused on network security, NDSS now covers all
aspects of computer security. This year we have a special interest in
practical security issues, and we will be interleaving the peer reviewed
technical papers with invited talk presentations from the "hacker"
community on the leading edge of security attacks. We expect the
blending of the (largely defense oriented) academic security community
with the (often attack oriented) hacker community to produce both
interesting presentations and interesting "hall track" conversations.

Please consider submitting your papers by this Sunday, and also consider
attending NDSS next February 28th - March 2nd in San Diego.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From gem at cigital.com  Thu Sep  7 13:19:14 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 7 Sep 2006 13:19:14 -0400
Subject: [SC-L] Silver Bullet: Ranum revisited
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4214B7@va-mail.cigital.com>

Hi all,

The silver bullet security podcast episode with Marcus Ranum has been
transcribed for publication in the Nov/Dec issue of IEEE S&P magazine.
You can find the pdf here:

http://www.cigital.com/silverbullet/shows/silverbullet-003-mranum.pdf

To subscribe to the magazine (without even joining the IEEE), use this
URL:

www.computer.org/services/nonmem/spbnr

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From gem at cigital.com  Thu Sep  7 15:44:13 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 7 Sep 2006 15:44:13 -0400
Subject: [SC-L] Darkreading: epassport and evoting
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4214B8@va-mail.cigital.com>

Hi all,

The latest installment of my column on darkreading went up today.  This
one is titled "Keep Your Laws off my Security."  It's about what happens
when people in power pay little or no attention to warnings by security
engineers.

http://www.darkreading.com/document.asp?doc_id=103078&WT.svl=column1_1

Since we're all "technology insiders" here on sc-l, I think it behooves
us to get involved in these issues.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From gem at cigital.com  Sat Sep  9 14:47:15 2006
From: gem at cigital.com (Gary McGraw)
Date: Sat, 9 Sep 2006 14:47:15 -0400
Subject: [SC-L] What happens when security engineering gets ignored
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB4214B9@va-mail.cigital.com>

Hi all,

My latest column on darkreading shows what can happen when security
engineers and technologists are ignored in the rush to embrace hot new
technology.  Many of us have warned over and over about RFID security
and eVoting security, but with very little impact on government
behavior.

See the article here:
http://www.darkreading.com/document.asp?doc_id=103078&WT.svl=column1_1

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ken at krvw.com  Mon Sep 11 01:42:52 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Mon, 11 Sep 2006 01:42:52 -0400
Subject: [SC-L] Fwd: There's More than One Monoculture
Message-ID: <F32AE7E6-E66B-42EC-86AF-015A9A75CEEF@krvw.com>

Greetings SC-L,

Check out Peter Coffee's latest column at:
http://www.eweek.com/article2/0,1895,2014207,00.asp

It's a follow-up to Dan Geer's (et al's) now famous monoculture  
paper, three years after the paper was published.  Among other  
things, Coffee makes some interesting comparisons to the Internet  
monoculture situation that existed in November 1988 when Robert  
Morris unleashed his Internet worm program.  Interesting reading, IMHO.

Cheers,

Ken
-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060911/a0482050/attachment.html 

From gem at cigital.com  Tue Sep 12 10:36:29 2006
From: gem at cigital.com (Gary McGraw)
Date: Tue, 12 Sep 2006 10:36:29 -0400
Subject: [SC-L] Security testing
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB743061@va-mail.cigital.com>


Hi all,

In this podcast interview (the first from sticky minds) I discuss the important differences between security testing and standard functional testing...among other things.  Lots of software security stuff in here:

http://www.stickyminds.com/Resources/Podcasts.asp

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 



Sent from my treo.


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From Ken at krvw.com  Wed Sep 27 09:39:32 2006
From: Ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 27 Sep 2006 09:39:32 -0400
Subject: [SC-L] IEEE Security and Privacy article on software security
	training
Message-ID: <0C7E516F-BEFE-4EE3-982D-558A4F35B3C2@krvw.com>

Wow, it's sure been a quiet few days out here on SC-L.  Summer  
vacations are over, I suppose...

In any case, I thought that I'd post a link to a new IEEE Security &  
Privacy article on training for software security engineers.  It was  
written by Cigital's John Steven and yours truly, and can be found via:

http://www.computer.org/portal/site/security

Enjoy.

Cheers,

Ken
-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20060927/ef85dd5b/attachment.bin 

From gem at cigital.com  Thu Sep 28 16:36:38 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 28 Sep 2006 16:36:38 -0400
Subject: [SC-L] Silver Bullet 6: Michael Howard
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7433DE@va-mail.cigital.com>

Hi all,

You'll probably like this one.  The latest installment of the Silver
Bullet Security Podcast is an interview with Michael Howard.  Do we talk
about software security?  Well, whatddaya think?!

http://www.cigital.com/silverbullet/

The Silver Bullet Security Podcast with Gary McGraw is co-sponsored by
Cigital and IEEE Security & Privacy magazine.  

gem

company www.cigital.com
book www.swsec.com


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From dinis at ddplus.net  Sat Sep 30 11:02:04 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Sat, 30 Sep 2006 16:02:04 +0100
Subject: [SC-L] Call for panelists: "The role of frameworks (e.g., .Net, Java,
	Enterprise Library, Struts,
	JaCorb) in 'forcing' developers to create and deploy 'secure'
	applications" panel in the next OWASP Conference
Message-ID: <701fd6b60609300802w5627343cia4e92cd7b7fc2a15@mail.gmail.com>

Ok, First a quick apology for sending this request 18 days before the event
(too busy, lack of sleep, charging kids nappies (or diapers for the US
crowd), etc... :)

In the next OWASP conference in Seattle, which will happen on the 17th and
18th of October 2006 (see
http://www.owasp.org/index.php/OWASP_AppSec_Seattle_2006/Agenda) I managed
to convince the organizers (thx Dave) to add the following panel to the line
up

Thursday 17th,  16:50-18:00 : "The role of frameworks (e.g., .Net, Java,
Enterprise Library, Struts, JaCorb) in 'forcing' developers to create and
deploy 'secure' applications. Moderator: TBD Panelists: Dinis Cruz,
OWASP.Net Project Lead and others
TBD "

The problem is in that last line: "Moderator: TBD Panelists: Dinis Cruz,
OWASP .Net Project Lead and others TBD" since at the moment it is only me :)


So I am doing this public call for panelists in the hope that I will find
the right ones.

Ideally I would like a strong representative from the following camps:

   - .Net CLR guru (with strong background on CAS (Code Access Security))

   - Java JVM  guru (with strong background on the Java Security Manager)
   - Struts guru (with a focus on Struts as a security layer), or other
   'developer focused' frameworks
   - Web Application Security Consultant (somebody focused in 'breaking
   applications')
   - Business manager (somebody whose job is to create/deliver
   applications, and will bring to the table the 'business mind' point of view)

To finish off this email here is a quick abstract of what I want to discuss
in this panel:

"The role of frameworks (e.g., .Net, Java, Enterprise Library, Struts,
JaCorb) in 'forcing' developers to create and deploy 'secure' applications

>From a security point of view, the current development paradigms are mainly
based on the concept of 'making no errors'. I.e. if only the developers (and
the Software development Livecycle that is supporting them) are able to
program 'securely'  (what ever that might mean), the security
vulnerabilities that we have today will cease to exit. Basically it is the
concept of the 'Big Wall of china'. There are some efforts in 'defense in
depth', which most of the time are either: a) not implemented, b) only
designed to protect the server and not the assets (for example the idea of
executing the code under a non-admin account) or c) too complex.

This creates an environment where the application asset's CIA
(Confidentiality, Integrity and Confidentiality) can be compromised via one
single mistake (created accidentally, by lack of knowledge or
'deliberately' ), such as: SQL Injection (the buffer overflows of Web Apps
:) ), Authorization/Authentication blind spot, Application logic or
malicious file upload/execution.

Part of the problem is that this requirement ('make no mistakes') applies to
100% of the code, since all code is executed under the same privileges (from
the point of view of the assets). This means that we (the developers and
security good guys) need to protect and worry about 100% of the code base
(which given a large enough application is just impossible). Basically, we
need to be able to "security and safely handle malicious code or benign code
manipulated in a malicious way"

For me the solution is to create a development model where 85% or 95% of the
code base is executed in an environment that doesn't have major security
implications). In this world, the exploit vector would have to be in the
remaining 15% or 5%, which would be the code base that would be audited,
closely analysed and in some cases certified.

My view is that this world would deliver secure applications (and an
environment where it would be commercially viable to do so), because most
developers would be focused on what they are good at and are paid for ( i.e.
features, performance and user experience) and only a small number of
developers would be involved in security related activities.

And of course, the way to create this world is by using development
frameworks that 'force' the developer(s) to program is such a way' (and
having enough enough commercial preasure).

So what I what to talk about in this panel, is how to we get there (and 'are
development frameworks a big part of the solution?').

Currently there are two main approaches to solve this problem: There is the
'Operating System' camp, and the 'Managed Environment' camp

Examples of the 'Operating System' camp are Microsoft's Vista, SELinux and
AppArmour

Examples of the 'Managed Environment' camp are the .Net Framework (or mono)
and Java

The only one that has any real momentum today is the  'Operating System'
camp, and in the 'Managed Environment' camp most of the code (probably 99%)
is executed in an 'unmanaged environment' (Full Trust in .Net or with the
Security Manager/Verifier disabled in Java).

Unfortunately, due to the enormous attack surface and the fact that most of
the assets are located at the user/identity layer, the  'Operating System'
camp is fighting a lost battle (look at Vista's UAC mess and
reimplementation of CAS (Code Access Security) at the OS level (best example
of this reimplementation is the new Vista Network permissions for processes
(which will not work as expected, ironically mainly because of the problems
that CAS has today: Policy, Complexity, Perceived value and ultimately Lack
Effectiveness))

As you can see in my previous posts, I put more faith in the 'Managed
Environment' camp, but at the moment there is no major focus in this
direction. My view is that we will have to wait 1 or 2 more years until
Vista, Mac Os and Linux show how their are not able to sustain 'unmanaged'
malicious code.

So, if you have strong opinions on this and have an active role in either
camp, join me on this panel at the next OWASP conference."

Best regards

Dinis Cruz
OWASP Autumn of Code 2006, http://www.owasp.org/index.php/OAC
OWASP .Net Project, http://www.owasp.org/index.php/.Net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060930/d7635957/attachment.html 

From ge at linuxbox.org  Thu Oct  5 12:58:18 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Thu, 5 Oct 2006 11:58:18 -0500 (CDT)
Subject: [SC-L] (no subject)
Message-ID: <Pine.LNX.4.21.0610051157050.18741-100000@linuxbox.org>

playing with Google Code Search, as Lev Toger just wrote:

Google released a code search engine to catch up with Krugle, Koders, and
Codease.

Like most of the other Google?s tools it can be easily abused for hacking
:)

To find undisclosed vulnerabilities pass over this code:

http://www.google.com/codesearch?q=ugly%7Chack%7Cfixme

Or some other interesting combination (Use your favorite ugly code
comment). 
-----

http://blogs.securiteam.com/index.php/archives/659

SO... ugly? dirty hack?

	Gadi.


From ge at linuxbox.org  Thu Oct  5 20:45:52 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Thu, 5 Oct 2006 19:45:52 -0500 (CDT)
Subject: [SC-L] Google code search games
In-Reply-To: <Pine.LNX.4.21.0610051157050.18741-100000@linuxbox.org>
Message-ID: <Pine.LNX.4.21.0610051945240.11807-100000@linuxbox.org>

Another guy just wrote some more fun keyw ords to search for:
http://blogs.securiteam.com/index.php/archives/661

On Thu, 5 Oct 2006, Gadi Evron wrote:

> playing with Google Code Search, as Lev Toger just wrote:
> 
> Google released a code search engine to catch up with Krugle, Koders, and
> Codease.
> 
> Like most of the other Google?s tools it can be easily abused for hacking
> :)
> 
> To find undisclosed vulnerabilities pass over this code:
> 
> http://www.google.com/codesearch?q=ugly%7Chack%7Cfixme
> 
> Or some other interesting combination (Use your favorite ugly code
> comment). 
> -----
> 
> http://blogs.securiteam.com/index.php/archives/659
> 
> SO... ugly? dirty hack?
> 
> 	Gadi.
> 
> 


From stephen at corsaire.com  Fri Oct  6 00:52:51 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Fri, 6 Oct 2006 11:52:51 +0700
Subject: [SC-L] Google code search games
In-Reply-To: <Pine.LNX.4.21.0610051945240.11807-100000@linuxbox.org>
References: <Pine.LNX.4.21.0610051945240.11807-100000@linuxbox.org>
Message-ID: <EA594E27-853B-4F2D-9737-2014827F84A1@corsaire.com>


Also:

XSS in Java apps
http://www.google.com/codesearch?hl=en&lr=&q=%3C%25% 
3D.*getParameter&btnG=Search

(Obvious) SQL Injection in Java apps:
http://www.google.com/codesearch? 
hl=en&lr=&q=executeQuery.*getParameter&btnG=Search

XSS in code from O'Reilly and Sun:
http://www.google.com/codesearch?hl=en&lr=&q=%3C%25%3D.*getParameter 
+package%3A%28oreilly.com%7Csun.com%29&btnG=Search


El 6 Oct 2006, a las 07:45, Gadi Evron escribi?:

> Another guy just wrote some more fun keyw ords to search for:
> http://blogs.securiteam.com/index.php/archives/661
>
> On Thu, 5 Oct 2006, Gadi Evron wrote:
>
>> playing with Google Code Search, as Lev Toger just wrote:
>>
>> Google released a code search engine to catch up with Krugle,  
>> Koders, and
>> Codease.
>>
>> Like most of the other Google?s tools it can be easily abused for  
>> hacking
>> :)
>>
>> To find undisclosed vulnerabilities pass over this code:
>>
>> http://www.google.com/codesearch?q=ugly%7Chack%7Cfixme
>>
>> Or some other interesting combination (Use your favorite ugly code
>> comment).
>> -----
>>
>> http://blogs.securiteam.com/index.php/archives/659
>>
>> SO... ugly? dirty hack?
>>
>> 	Gadi.
>>
>>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/ 
> listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/ 
> charter.php

-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com






From rcs at cert.org  Fri Oct  6 03:14:06 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Fri, 06 Oct 2006 03:14:06 -0400
Subject: [SC-L] Google code search games
In-Reply-To: <Pine.LNX.4.21.0610051945240.11807-100000@linuxbox.org>
References: <Pine.LNX.4.21.0610051945240.11807-100000@linuxbox.org>
Message-ID: <4526023E.2000908@cert.org>

Gadi,

Here are some searches from Derek Jones:

The new Google source code search page has opened up
some interesting research possibilities.

How many instances of:

if (...) ;

are there out there (skip the first half dozen unusual macro uses)?

http://www.google.com/codesearch?hl=en&lr=&q=++%5Csif%5C(%5B%5E)%5D*%5C)%3B+lang%3Ac%2B%2B&btnG=Search


Security holes in PHP web applications:

http://www.google.com/codesearch?hl=en&lr=&q=Where+%5C%24_POST+-addslashes+lang%3Aphp


Back door passwords :-)

http://www.google.com/codesearch?q=+%22backdoor+password

rCs


From rcs at cert.org  Fri Oct  6 21:36:36 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Fri, 06 Oct 2006 21:36:36 -0400
Subject: [SC-L] Static code analysis via Google code search
Message-ID: <452704A4.8060401@cert.org>


people are having way too much fun with this:

http://asert.arbornetworks.com/2006/10/static-code-analysis-using-google-code-search/

rCs

From gunnar at arctecgroup.net  Fri Oct  6 18:05:33 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Fri, 06 Oct 2006 17:05:33 -0500
Subject: [SC-L] Google code search games
In-Reply-To: <4526023E.2000908@cert.org>
Message-ID: <C14C3D5D.2CD1%gunnar@arctecgroup.net>

DTDs
http://www.google.com/codesearch?hl=en&lr=&q=file%3Adtd&btnG=Search

-gp


On 10/6/06 2:14 AM, "Robert C. Seacord" <rcs at cert.org> wrote:

> Gadi,
> 
> Here are some searches from Derek Jones:
> 
> The new Google source code search page has opened up
> some interesting research possibilities.
> 
> How many instances of:
> 
> if (...) ;
> 
> are there out there (skip the first half dozen unusual macro uses)?
> 
> http://www.google.com/codesearch?hl=en&lr=&q=++%5Csif%5C(%5B%5E)%5D*%5C)%3B+la
> ng%3Ac%2B%2B&btnG=Search
> 
> 
> Security holes in PHP web applications:
> 
> http://www.google.com/codesearch?hl=en&lr=&q=Where+%5C%24_POST+-addslashes+lan
> g%3Aphp
> 
> 
> Back door passwords :-)
> 
> http://www.google.com/codesearch?q=+%22backdoor+password
> 
> rCs
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php



From itripn at gmail.com  Sun Oct  8 10:04:54 2006
From: itripn at gmail.com (Ron Forrester)
Date: Sun, 8 Oct 2006 07:04:54 -0700
Subject: [SC-L] Google code search games
In-Reply-To: <Pine.LNX.4.21.0610051945240.11807-100000@linuxbox.org>
References: <Pine.LNX.4.21.0610051157050.18741-100000@linuxbox.org>
	<Pine.LNX.4.21.0610051945240.11807-100000@linuxbox.org>
Message-ID: <b5f570110610080704r6a349af3y4a518c9928e0c50e@mail.gmail.com>

WSDL:

http://www.google.com/codesearch?hl=en&lr=&q=file%3A.wsdl%24+transfer&btnG=Search


On 10/5/06, Gadi Evron <ge at linuxbox.org> wrote:
> > playing with Google Code Search, as Lev Toger just wrote:
> >
> > Google released a code search engine to catch up with Krugle, Koders, and
> > Codease.
> >
> > Like most of the other Google?s tools it can be easily abused for hacking
> > :)


-- 
rjf&

From ge at linuxbox.org  Sun Oct  8 10:58:01 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Sun, 8 Oct 2006 09:58:01 -0500 (CDT)
Subject: [SC-L] Google code search games
In-Reply-To: <b5f570110610080704r6a349af3y4a518c9928e0c50e@mail.gmail.com>
Message-ID: <Pine.LNX.4.21.0610080956280.25392-100000@linuxbox.org>

On Sun, 8 Oct 2006, Ron Forrester wrote:
> WSDL:
> 
> http://www.google.com/codesearch?hl=en&lr=&q=file%3A.wsdl%24+transfer&btnG=Search

I am still updating the main post with new search regex as I find them,
all the time:
http://blogs.securiteam.com/index.php/archives/663

Some other fun was noted on the daily WTF, where the do more funny
searches:
http://thedailywtf.com/forums/thread/94630.aspx


> 
> 
> On 10/5/06, Gadi Evron <ge at linuxbox.org> wrote:
> > > playing with Google Code Search, as Lev Toger just wrote:
> > >
> > > Google released a code search engine to catch up with Krugle, Koders, and
> > > Codease.
> > >
> > > Like most of the other Google?s tools it can be easily abused for hacking
> > > :)
> 
> 
> -- 
> rjf&
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 


From gem at cigital.com  Mon Oct  9 12:19:13 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 9 Oct 2006 12:19:13 -0400
Subject: [SC-L] darkreading: voting machines
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6FEBA3@va-mail.cigital.com>

Hi all,

I'm sure that many of you saw the "Ed Felten and friends break Diebold
machines" story a couple of weeks ago...maybe in DDJ or on /..  I wrote
a piece about the crack for darkreading, which you can find here:

http://www.darkreading.com/document.asp?doc_id=105188&WT.svl=column1_1

The most interesting thing from an sc-l perspective about this column is
that it emphasizes a client need we're often forced to address---the
need for a demo exploit.  Sometimes those on the receiving end of a
software security vulnerability don't believe that findings are real.
An often-repeated excuse for doing nothing is "well, that's just a
theoretical attack and it's too academic to matter."  I can't tell you
how many times I've heard that refrain.

When that happens, building an exploit is often the only clear next
step.  And yet we all know how expensive and hard exploit development
is.  

In this case, Diebold consistently downplay'ed Avi Rubin's results as
"academic" or "theoretical."  Ed upped the ante.  Think it'll work??

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From jeff.williams at aspectsecurity.com  Mon Oct  9 23:34:50 2006
From: jeff.williams at aspectsecurity.com (Jeff Williams)
Date: Mon, 9 Oct 2006 23:34:50 -0400
Subject: [SC-L] OWASP webappsec mailing list
Message-ID: <B9A412898630124ABE8350F4EBD32E84176CBF@mymail.aspectsecurity.com>

Hi,

 

I'd like to invite you to join (or rejoin) the OWASP
<http://www.owasp.org/>  webappsec mailing list. We started this mailing
list almost 5 years ago and it has spawned great discussion of
application security issues. We're moving the list from its current home
to a server controlled by OWASP. This will allow us to provide the high
quality moderation the list deserves.

 


You can join (or rejoin) us on the webappsec list by clicking here...

 

  <http://lists.owasp.org/mailman/listinfo/webappsec> 

http://lists.owasp.org/mailman/listinfo/webappsec

 

 

If you haven't visited OWASP in a while, please come check out what's
going on. The OWASP standard tools, like WebScarab
<http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project>  and 
WebGoat <http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project>
have all been improving steadily over time.  And we have tons of new
projects, content, and tools, including:

 

-          OWASP AJAX Security Project
<http://www.owasp.org/index.php/Category:OWASP_AJAX_Security_Project>  -
investigating security of AJAX enabled applications 

-          OWASP CAL9000 Project
<http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project>  - a
JavaScript based web application security testing suite 

-          OWASP Code Review Project
<http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project>  - a
new project to capture best practices for reviewing code 

-          OWASP Honeycomb Project
<http://www.owasp.org/index.php/Category:OWASP_Honeycomb_Project>  - a
guide to the building blocks of application security 

-          OWASP LAPSE Project
<http://www.owasp.org/index.php/Category:OWASP_LAPSE_Project>  - an
Eclipse-based source static analysis tool for Java 

-          OWASP Live CD Project
<http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project>  - a CD
will application security analysis and testing tools 

-          OWASP Orizon Project
<http://www.owasp.org/index.php/Category:OWASP_Orizon_Project>  - a
flexible code review engine 

-          OWASP Pantera Web Assessment Studio Project
<http://www.owasp.org/index.php/Category:OWASP_Pantera_Web_Assessment_St
udio_Project>  - a hybrid testing approach 

-          OWASP PHP Project
<http://www.owasp.org/index.php/Category:OWASP_PHP_Project>  - helping
PHP developers build secure applications 

-          OWASP Java Project
<http://www.owasp.org/index.php/Category:OWASP_Java_Project>  - helping
Java and J2EE developers build secure applications 

-          OWASP SQLiX Project
<http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project>  - a full
perl-based SQL scanner 

-          OWASP Testing Project
<http://www.owasp.org/index.php/Category:OWASP_Testing_Project>  -
application security testing procedures and checklists 

-          OWASP Validation Project
<http://www.owasp.org/index.php/Category:OWASP_Validation_Project>  - a
project that provides guidance and tools related to validation.

 

As always, OWASP is free and open for everyone.  Please forward this
message to anyone who is interested in application security. Thanks for
your support.

 

--Jeff

 

Jeff Williams, Chair

The OWASP Foundation <http://www.owasp.org/> 

 

"Dedicated to finding and fighting the causes of insecure software"

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061009/b2cce75c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1656 bytes
Desc: image001.jpg
Url : http://krvw.com/pipermail/sc-l/attachments/20061009/b2cce75c/attachment-0001.jpe 

From Ken at krvw.com  Tue Oct 10 12:02:10 2006
From: Ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 10 Oct 2006 12:02:10 -0400
Subject: [SC-L] Insecurity in Open Source
Message-ID: <FDDE3569-FED9-452F-9F40-53317542256D@KRvW.com>

FYI, there's an interesting opinion article in Business Week by  
Coverity's CTO, Ben Chelf (see link below).  In it, he discusses the  
results of their scanning of a significant sampling of both open- and  
closed-source projects.

Chelf compares some special purpose proprietary software security/ 
quality with the best of what's out in the open source world.   
Further, he opines that the open source guys need to adopt far more  
rigorous QA testing in order to compete with the best of the  
proprietary source world.

I'm passing this along not to launch into the invariable religious  
debates of closed- vs. open-source, but to encourage discussion about  
Chelf's claims with regards to rigorous QA testing.  Anyway, here's  
the article.

http://www.businessweek.com/technology/content/oct2006/ 
tc20061006_394140.htm?campaign_id=bier_tco.g3a.rss1007

Cheers,

Ken
-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061010/08e8c1b6/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20061010/08e8c1b6/attachment.bin 

From jeremy.epstein at webmethods.com  Tue Oct 10 12:44:28 2006
From: jeremy.epstein at webmethods.com (Jeremy Epstein)
Date: Tue, 10 Oct 2006 12:44:28 -0400
Subject: [SC-L] darkreading: voting machines
Message-ID: <C4B880098AA68B4CB4A0B82B1419A460021D4C76@mailva>

Gary,

Interesting point.  I'm on the Virginia state commission charged with making
recommendations around voting systems, and we watched the Princeton video as
part of our most recent meeting.  The reaction from the election officials
was amusing and scary: "if this is so real, why don't you hack a real
election instead of this pretend stuff in the lab".  Pointing out that it
would (most likely) be a felony, and people like Rubin, Felten, and others
are trying to help security not go to jail didn't seem to impress them.
Also pointing out that the Rubin & Felten examples used out-of-date code
because vendors won't share anything up-to-date doesn't seem to impress
them.  [This in response to Diebold's claim that they were looking at old
code, and the problems are all "fixed".]

I frankly don't think anything is going to impress the election officials
(and some of the elected officials) short of incontrovertible evidence of a
DRE meltdown - and of course, we know that there could well be a failure
(and may have been failures) that are unproveable thanks to the nature of
software.

--Jeremy

P.S. One of the elected officials on the commision insisted that Felten
couldn't possibly have done his demo exploit without source code, because
"everyone" knows you can't do an exploit without the source.  Unfortunately,
the level of education that needs to be provided to someone like that is
more than I can provide in a Q&A format.  I tried giving as an example that
around 50% of the Microsoft updates are due to flaws found by people without
source, but he wouldn't buy it.... (he was using a Windows laptop, but
doesn't seem to understand where the fixes come from).

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw
> Sent: Monday, October 09, 2006 12:19 PM
> To: SC-L at securecoding.org
> Cc: dwallach at cs.rice.edu; felten at princeton.edu; rubin at jhu.edu
> Subject: [SC-L] darkreading: voting machines
> 
> Hi all,
> 
> I'm sure that many of you saw the "Ed Felten and friends 
> break Diebold machines" story a couple of weeks ago...maybe 
> in DDJ or on /..  I wrote a piece about the crack for 
> darkreading, which you can find here:
> 
> http://www.darkreading.com/document.asp?doc_id=105188&WT.svl=column1_1
> 
> The most interesting thing from an sc-l perspective about 
> this column is that it emphasizes a client need we're often 
> forced to address---the need for a demo exploit.  Sometimes 
> those on the receiving end of a software security 
> vulnerability don't believe that findings are real.
> An often-repeated excuse for doing nothing is "well, that's 
> just a theoretical attack and it's too academic to matter."  
> I can't tell you how many times I've heard that refrain.
> 
> When that happens, building an exploit is often the only 
> clear next step.  And yet we all know how expensive and hard 
> exploit development is.  
> 
> In this case, Diebold consistently downplay'ed Avi Rubin's 
> results as "academic" or "theoretical."  Ed upped the ante.  
> Think it'll work??
> 
> gem
> 
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> book www.swsec.com 
> 
> 
> --------------------------------------------------------------
> --------------
> This electronic message transmission contains information 
> that may be confidential or privileged.  The information 
> contained herein is intended solely for the recipient and use 
> by any other party is not authorized.  If you are not the 
> intended recipient (or otherwise authorized to receive this 
> message by the intended recipient), any disclosure, copying, 
> distribution or use of the contents of the information is 
> prohibited.  If you have received this electronic message 
> transmission in error, please contact the sender by reply 
> email and delete all copies of this message.  Cigital, Inc. 
> accepts no responsibility for any loss or damage resulting 
> directly or indirectly from the use of this email or its contents.
> Thank You.
> --------------------------------------------------------------
> --------------
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - 
> http://www.securecoding.org/list/charter.php
> 

From Ken at krvw.com  Wed Oct 11 10:37:50 2006
From: Ken at krvw.com (Kenneth Van Wyk)
Date: Wed, 11 Oct 2006 10:37:50 -0400
Subject: [SC-L] A banner year for software bugs | Tech News on ZDNet
Message-ID: <DFF12728-6FA2-4500-BAE4-986703775AF8@KRvW.com>

So here's a lovely statistic for the software community to hang its  
hat on:

http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed

Among other things, the article says, "Atlanta-based ISS, which is  
being acquired by IBM, predicts there will be a 41 percent increase  
in confirmed security faults in software compared with 2005. That  
year, in its own turn, saw a 37 percent rise over 2004."

Of course, the real losers in this are the software users, who have  
to deal with the never ending onslaught of bugs and patches from  
their vendors.  We've just _got_ to do better, IMHO, and automating  
the patch process is not the answer.

Cheers,

Ken
-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20061011/3e8c4d85/attachment.bin 

From c.mccown at intel.com  Wed Oct 11 12:32:00 2006
From: c.mccown at intel.com (McCown, Christian M)
Date: Wed, 11 Oct 2006 09:32:00 -0700
Subject: [SC-L] A banner year for software bugs | Tech News on ZDNet
Message-ID: <E47BF8624D32E7409D03C3CBB65D8A9401470360@fmsmsx419.amr.corp.intel.com>

It's probably worth mentioning that the statistics are for OTS software.
What keeps me awake at night (other than the usual trivialities) is the
volume and severity of flaws/bugs in software that companies have
developed or customized in-house/internally.  It gets more complicated
when these apps are public-facing.  Yikes.

/cm

-----Original Message-----
From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk
Sent: Wednesday, October 11, 2006 7:38 AM
To: Secure Coding
Subject: [SC-L] A banner year for software bugs | Tech News on ZDNet

So here's a lovely statistic for the software community to hang its  
hat on:

http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed

Among other things, the article says, "Atlanta-based ISS, which is  
being acquired by IBM, predicts there will be a 41 percent increase  
in confirmed security faults in software compared with 2005. That  
year, in its own turn, saw a 37 percent rise over 2004."

Of course, the real losers in this are the software users, who have  
to deal with the never ending onslaught of bugs and patches from  
their vendors.  We've just _got_ to do better, IMHO, and automating  
the patch process is not the answer.

Cheers,

Ken
-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




From mshines at purdue.edu  Wed Oct 11 10:51:54 2006
From: mshines at purdue.edu (Michael S Hines)
Date: Wed, 11 Oct 2006 10:51:54 -0400
Subject: [SC-L] A banner year for software bugs | Tech News on ZDNet
In-Reply-To: <DFF12728-6FA2-4500-BAE4-986703775AF8@KRvW.com>
Message-ID: <200610111452.k9BEqVRk028058@mailhub130.itcs.purdue.edu>

... the patch process is not the answer....

And neither is adding new features when the old ones don't work.
It's time to major on the majors, and quit messing with the minors.
Give us features that work (do what they should do, and don't do what they
should not do) - not just more features.

Who cares if your icons have round or square corners - if someone else can
take over your machine?

Mike Hines
mshines at purdue.edu

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Kenneth Van Wyk
Sent: Wednesday, October 11, 2006 10:38 AM
To: Secure Coding
Subject: [SC-L] A banner year for software bugs | Tech News on ZDNet

So here's a lovely statistic for the software community to hang its hat on:

http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed

Among other things, the article says, "Atlanta-based ISS, which is being
acquired by IBM, predicts there will be a 41 percent increase in confirmed
security faults in software compared with 2005. That year, in its own turn,
saw a 37 percent rise over 2004."

Of course, the real losers in this are the software users, who have to deal
with the never ending onslaught of bugs and patches from their vendors.
We've just _got_ to do better, IMHO, and automating the patch process is not
the answer.

Cheers,

Ken
-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com







From gem at cigital.com  Wed Oct 11 16:26:52 2006
From: gem at cigital.com (Gary McGraw)
Date: Wed, 11 Oct 2006 16:26:52 -0400
Subject: [SC-L] Google code search: good or bad?
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB4EC@va-mail.cigital.com>

Hi all,

I spoke to Dennis Fisher about the Google code searching stuff that's
been floating around on the list for a few weeks (since the original
Bugle posting).  Here's the resulting article:

http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1
222898,00.html

BTW, I wrote about this idea in my own article on darkreading back in
August:

http://www.darkreading.com/document.asp?doc_id=100643

What do you guys think about the capability?  Is it good or is it bad?

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From dwheeler at ida.org  Wed Oct 11 17:20:08 2006
From: dwheeler at ida.org (David A. Wheeler)
Date: Wed, 11 Oct 2006 17:20:08 -0400
Subject: [SC-L] darkreading: voting machines
References: <mailman.1.1160582401.38342.sc-l@securecoding.org>
Message-ID: <452D6008.9010301@ida.org>

Jeremy Epstein:
> Interesting point.  I'm on the Virginia state commission charged with making
> recommendations around voting systems, and we watched the Princeton video as
> part of our most recent meeting.  The reaction from the election officials
> was amusing and scary: "if this is so real, why don't you hack a real
> election instead of this pretend stuff in the lab".  Pointing out that it
> would (most likely) be a felony, and people like Rubin, Felten, and others
> are trying to help security not go to jail didn't seem to impress them.
> Also pointing out that the Rubin & Felten examples used out-of-date code
> because vendors won't share anything up-to-date doesn't seem to impress
> them.  [This in response to Diebold's claim that they were looking at old
> code, and the problems are all "fixed".]

I'm willing to believe that the ELECTIONS are fixed.   Since they lack a
voter-verifiable paper trail, _no_ DRE can be trusted.  Period.

I used to do magic tricks, and they all work the same way - misdirect
the viewer, so that what they think they see is not the same as reality.
Many magic tricks depend on rigged props, where what you see is NOT the whole
story.  DREs are the ultimate illusion - the naive
THINK they know what's doing, but in fact they have no
way to know what's really going on.  There's no way to even SEE the
trap door under the box, as it were... DREs are a great prop for the illusion.
Printing "zero" totals and other stuff looks just like a magic show to me -
it has lots of pizazz, and it distracts the viewer from the fact that
they have NO idea what's really going on.

> I frankly don't think anything is going to impress the election officials
> (and some of the elected officials) short of incontrovertible evidence of a
> DRE meltdown - and of course, we know that there could well be a failure
> (and may have been failures) that are unproveable thanks to the nature of
> software.

I'm of the opinion that elections using DREs have ALREADY been manipulated.
No, I can't prove that an election HAS been manipulated, and I certainly
can't point to a specific manufacturer or election.  And I sincerely
hope that no elections HAVE been manipulated.  But there's a LOT of money
riding on big elections, and a small fraction of that would be enough
to tempt someone to do it.  And many people STRONGLY believe in their
cause/party, and might manipulate an election on the grounds that it's
for the "greater good" - it need not be about money at all.

It's crazy to assume that no one's done it,
when it's so easy and the systems are KNOWN to be weak. The whole problem
is that DRE designs make it essentially impossible to detect
massive fraud, almost impossible to find the perpetrator even if
you detected it, and allow a SINGLE person to control an entire election
(so there's little risk of a "squeeler" as there is with other frauds).
And if an unethical person knows they won't be caught,
it INCREASES the probability of them doing it.
Anyone who thinks that all candidates and parties are too honest to do this
need to discover the newspaper and history books.  Ballot-stuffing
is at least as ancient as ancient Greece, and as modern as Right Now.

These voting systems and their surrounding processes
would not meet the criteria for an electronic one-armed bandit
in Las Vegas.  Yet there's more at stake.

The state commissions cannot provide any justifiable evidence
that votes are protected from compromise if they use DREs.
And that is their job.

DREs are unfit for use in elections that matter.  They should
be decommissioned with prejudice, and frankly,
I'd like to see laws requiring vendors to take them back and give
their purchasers a refund, or add voter-verified paper systems acceptable
to the customer at no charge.
(The paper needs to meet some standard too, so that you can use counting
machines from different manufacturers to prevent collusion.)
At no time was this DRE technology appropriate
for use in voting, and the companies selling them would have known better
had they done any examination of their real requirements.
The voters were given a lemon, and they should have the right to get
their money back.

--- David A. Wheeler



From michaelslists at gmail.com  Wed Oct 11 16:49:52 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Thu, 12 Oct 2006 06:49:52 +1000
Subject: [SC-L] Google code search: good or bad?
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB4EC@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB4EC@va-mail.cigital.com>
Message-ID: <5e01c29a0610111349k56299ddevd87a03c72a4c4198@mail.gmail.com>

good or bad, it's quite old. www.koders.com has been doing it for
years. considering the source is available for anyone to download
anyway, and investigate themselves, i don't see the big deal. the
engines just let you search a whole bunch at once, and why would any
one company/product care about that? if you want to target them, you
do. if you just want to find a bug in any given open source product,
then one of these may be slightly useful.

if the main concern is that code can accidently get online, well that
problem has been around forever and will never go away. better to
expose it and have it dealt with, really.

all in all, no big deal. jmho.

-- mic


On 10/12/06, Gary McGraw <gem at cigital.com> wrote:
> Hi all,
>
> I spoke to Dennis Fisher about the Google code searching stuff that's
> been floating around on the list for a few weeks (since the original
> Bugle posting).  Here's the resulting article:
>
> http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1
> 222898,00.html
>
> BTW, I wrote about this idea in my own article on darkreading back in
> August:
>
> http://www.darkreading.com/document.asp?doc_id=100643
>
> What do you guys think about the capability?  Is it good or is it bad?
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> book www.swsec.com

From gem at cigital.com  Wed Oct 11 16:55:42 2006
From: gem at cigital.com (Gary McGraw)
Date: Wed, 11 Oct 2006 16:55:42 -0400
Subject: [SC-L] Google code search: good or bad?
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB4F6@va-mail.cigital.com>

Fair enough.  It's pretty darn fun to search for silly things.  My
favorite so far is to search for "**cker" (you fill in the blanks
yourself).  Surprising how many people curse in their comments.

Given the importance of config files for most modern frameworks,
searching for XML config foo is interesting as well.

gem  

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com

-----Original Message-----
From: mikeiscool [mailto:michaelslists at gmail.com] 
Sent: Wednesday, October 11, 2006 4:50 PM
To: Gary McGraw
Cc: SC-L at securecoding.org; Neil Daswani
Subject: Re: [SC-L] Google code search: good or bad?

good or bad, it's quite old. www.koders.com has been doing it for
years. considering the source is available for anyone to download
anyway, and investigate themselves, i don't see the big deal. the
engines just let you search a whole bunch at once, and why would any
one company/product care about that? if you want to target them, you
do. if you just want to find a bug in any given open source product,
then one of these may be slightly useful.

if the main concern is that code can accidently get online, well that
problem has been around forever and will never go away. better to
expose it and have it dealt with, really.

all in all, no big deal. jmho.

-- mic


On 10/12/06, Gary McGraw <gem at cigital.com> wrote:
> Hi all,
>
> I spoke to Dennis Fisher about the Google code searching stuff that's
> been floating around on the list for a few weeks (since the original
> Bugle posting).  Here's the resulting article:
>
>
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1
> 222898,00.html
>
> BTW, I wrote about this idea in my own article on darkreading back in
> August:
>
> http://www.darkreading.com/document.asp?doc_id=100643
>
> What do you guys think about the capability?  Is it good or is it bad?
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> book www.swsec.com



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ge at linuxbox.org  Wed Oct 11 20:50:02 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Wed, 11 Oct 2006 19:50:02 -0500 (CDT)
Subject: [SC-L] re-writing college books [was: Re: A banner year for
 software bugs | Tech News on ZDNet]
In-Reply-To: <DFF12728-6FA2-4500-BAE4-986703775AF8@KRvW.com>
Message-ID: <Pine.LNX.4.21.0610111948260.17257-100000@linuxbox.org>

So, how can we edit current basic programming college books to present
secure code, a couple of words of the correct way of doing things, and a
whole new chapter on secure coding (which may be redudndent?)

How do we start?

Some Whiley book for introduction to CS?

Any volunteers to get this on the road?

	Gadi.

On Wed, 11 Oct 2006, Kenneth Van Wyk wrote:

> So here's a lovely statistic for the software community to hang its  
> hat on:
> 
> http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed
> 
> Among other things, the article says, "Atlanta-based ISS, which is  
> being acquired by IBM, predicts there will be a 41 percent increase  
> in confirmed security faults in software compared with 2005. That  
> year, in its own turn, saw a 37 percent rise over 2004."
> 
> Of course, the real losers in this are the software users, who have  
> to deal with the never ending onslaught of bugs and patches from  
> their vendors.  We've just _got_ to do better, IMHO, and automating  
> the patch process is not the answer.
> 
> Cheers,
> 
> Ken
> -----
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> 


From michaelslists at gmail.com  Wed Oct 11 21:03:25 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Thu, 12 Oct 2006 11:03:25 +1000
Subject: [SC-L] re-writing college books [was: Re: A banner year for
	software bugs | Tech News on ZDNet]
In-Reply-To: <Pine.LNX.4.21.0610111948260.17257-100000@linuxbox.org>
References: <DFF12728-6FA2-4500-BAE4-986703775AF8@KRvW.com>
	<Pine.LNX.4.21.0610111948260.17257-100000@linuxbox.org>
Message-ID: <5e01c29a0610111803l59bf89eam939727a12fdced19@mail.gmail.com>

On 10/12/06, Gadi Evron <ge at linuxbox.org> wrote:
> So, how can we edit current basic programming college books to present
> secure code, a couple of words of the correct way of doing things, and a
> whole new chapter on secure coding (which may be redudndent?)
>
> How do we start?
>
> Some Whiley book for introduction to CS?
>
> Any volunteers to get this on the road?

Secure programming is good programming. Most books teach good
programming. People just don't care.


>         Gadi.

-- mic

From gem at cigital.com  Wed Oct 11 21:25:29 2006
From: gem at cigital.com (Gary McGraw)
Date: Wed, 11 Oct 2006 21:25:29 -0400
Subject: [SC-L] re-writing college books [was: Re: A banner year for
	software bugs | Tech News on ZDNet]
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E790F@va-mail.cigital.com>

We're working on it!  The problem is not simply a book.

gem

 -----Original Message-----
From: 	Gadi Evron [mailto:ge at linuxbox.org]
Sent:	Wed Oct 11 20:58:12 2006
To:	Kenneth Van Wyk
Cc:	Secure Coding
Subject:	[SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]

So, how can we edit current basic programming college books to present
secure code, a couple of words of the correct way of doing things, and a
whole new chapter on secure coding (which may be redudndent?)

How do we start?

Some Whiley book for introduction to CS?

Any volunteers to get this on the road?

	Gadi.

On Wed, 11 Oct 2006, Kenneth Van Wyk wrote:

> So here's a lovely statistic for the software community to hang its  
> hat on:
> 
> http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed
> 
> Among other things, the article says, "Atlanta-based ISS, which is  
> being acquired by IBM, predicts there will be a 41 percent increase  
> in confirmed security faults in software compared with 2005. That  
> year, in its own turn, saw a 37 percent rise over 2004."
> 
> Of course, the real losers in this are the software users, who have  
> to deal with the never ending onslaught of bugs and patches from  
> their vendors.  We've just _got_ to do better, IMHO, and automating  
> the patch process is not the answer.
> 
> Cheers,
> 
> Ken
> -----
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> 

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ge at linuxbox.org  Wed Oct 11 21:28:52 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Wed, 11 Oct 2006 20:28:52 -0500 (CDT)
Subject: [SC-L] re-writing college books [was: Re: A banner year for
 software bugs | Tech News on ZDNet]
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E790F@va-mail.cigital.com>
Message-ID: <Pine.LNX.4.21.0610112027520.17257-100000@linuxbox.org>

On Wed, 11 Oct 2006, Gary McGraw wrote:
> We're working on it!  The problem is not simply a book.

Great! What are you guys doing? What more can be done? There are quite a
few of us willing to help, and I figure, starting with the books future
programmers learn from is not a bad idea.

This community is perfect for this job.

	Gadi.

> 
> gem
> 
>  -----Original Message-----
> From: 	Gadi Evron [mailto:ge at linuxbox.org]
> Sent:	Wed Oct 11 20:58:12 2006
> To:	Kenneth Van Wyk
> Cc:	Secure Coding
> Subject:	[SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
> 
> So, how can we edit current basic programming college books to present
> secure code, a couple of words of the correct way of doing things, and a
> whole new chapter on secure coding (which may be redudndent?)
> 
> How do we start?
> 
> Some Whiley book for introduction to CS?
> 
> Any volunteers to get this on the road?
> 
> 	Gadi.
> 
> On Wed, 11 Oct 2006, Kenneth Van Wyk wrote:
> 
> > So here's a lovely statistic for the software community to hang its  
> > hat on:
> > 
> > http://news.zdnet.com/2100-1009_22-6124541.html?tag=zdfd.newsfeed
> > 
> > Among other things, the article says, "Atlanta-based ISS, which is  
> > being acquired by IBM, predicts there will be a 41 percent increase  
> > in confirmed security faults in software compared with 2005. That  
> > year, in its own turn, saw a 37 percent rise over 2004."
> > 
> > Of course, the real losers in this are the software users, who have  
> > to deal with the never ending onslaught of bugs and patches from  
> > their vendors.  We've just _got_ to do better, IMHO, and automating  
> > the patch process is not the answer.
> > 
> > Cheers,
> > 
> > Ken
> > -----
> > Kenneth R. van Wyk
> > KRvW Associates, LLC
> > http://www.KRvW.com
> > 
> > 
> > 
> > 
> > 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
> 


From rcs at cert.org  Thu Oct 12 09:20:22 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Thu, 12 Oct 2006 09:20:22 -0400
Subject: [SC-L] re-writing college books [was: Re: A banner year for
 software bugs | Tech News on ZDNet]
In-Reply-To: <Pine.LNX.4.21.0610112027520.17257-100000@linuxbox.org>
References: <Pine.LNX.4.21.0610112027520.17257-100000@linuxbox.org>
Message-ID: <452E4116.6020101@cert.org>


Gadi,

I sort of agree with mic that the problem is poor programming.  My last
manager liked to pick up C text books at random and point out all the
vulnerabilities in the code examples that are being used to teach the
next generation of programmers (how to write vulnerabilities).

> This community is perfect for this job.

If the community is bored right now ;^) we are looking for community
help to build up our knowledge of secure coding rules and
recommendations for the C and C++ programming languages:

www.securecoding.cert.org

I'm also teaching a course at CMU in the spring on Secure Coding in C
and C++.  I'm hoping to take this material and incorporate it into the
course.  Once I get some experience teaching the material, I could help
turn it into a college text.  (I've written three books already, so I'm
a proven threat. 8^)

Thanks,
rCs


-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC

Work: 412-268-7608
FAX: 412-268-6989

From ljknews at mac.com  Thu Oct 12 10:03:39 2006
From: ljknews at mac.com (ljknews)
Date: Thu, 12 Oct 2006 10:03:39 -0400
Subject: [SC-L] re-writing college books [was: Re: A banner year for
 software bugs | Tech News on ZDNet]
In-Reply-To: <452E4116.6020101@cert.org>
References: <Pine.LNX.4.21.0610112027520.17257-100000@linuxbox.org>
	<452E4116.6020101@cert.org>
Message-ID: <p05200f04c153fa95cffd@[192.168.1.254]>

At 9:20 AM -0400 10/12/06, Robert C. Seacord wrote:

> I'm also teaching a course at CMU in the spring on Secure Coding in C
> and C++.

Is there participation on this list from the (hopefully larger number of)
CMU instructors who are teaching people to use safer languages in the first
place ?
-- 
Larry Kilgallen

From dwheeler at ida.org  Thu Oct 12 11:44:56 2006
From: dwheeler at ida.org (David A. Wheeler)
Date: Thu, 12 Oct 2006 11:44:56 -0400
Subject: [SC-L] Secure programming is NOT just good programming
References: <mailman.194.1160651617.4113.sc-l@securecoding.org>
Message-ID: <452E62F8.3050209@ida.org>

mikeiscool claimed:
> Secure programming is good programming.
 > Most books teach good programming.

I strongly disagree with you, on both counts.
At the least, those who say they practice good programming
practices, and books that say they teach good programming
practices, are GROSSLY INADEQUATE for developing secure programs.

First, "Secure programming is good programming":
Most people and organizations who claim that they perform
good programming practices do NOT perform practices
necessary for security.  You could argue that therefore they
aren't really doing "good programming", but that doesn't
help fix anything. And organizations STILL generally
place features over security, and when there's a perceived
conflict, security almost always loses... and they'll STILL
say that they practice "good programming" practices (they just
happen to correctly implement insecure programs).

Here are some practices you should typically be doing
if you're worried about security, and note that many are
typically NOT considered "good programming"
by the general community of software developers:
* You need to identify your threats that you'll counter (as requirements)
* Design so that the threats are countered, e.g., mutually
   suspicious processes, small trusted computer base (TCB), etc.
* Choose programming languages where you're less likely to
   have security flaws, and where you can't (e.g., must use C/C++), use extra
   security scanning tools and warning flags to reduce the risk.
* Train on the specific common SECURITY failures of that
   language, so you can avoid them. (E.G., gets() is verbotin.)
* Have peer reviews of the code, so that others can help find
   problems/vulnerabilities.
* Test specifically for security properties, and use fuzz testing
   rigged to test for them.
Few of these are done, particularly the first two. I'll concede
that many open source software projects do peer reviews, but you
really want ALL of these practices.

Next, "Most books teach good programming." Pooey, though I wish they did.
I still find buffer overflows in examples inside books on C/C++.
I know the first version of K&R used scanf("...%s..."..) without noting
that you could NEVER use this on untrusted input; I think the
second edition used gets() without commenting on its security problems.
A typical PHP book is littered with examples that are XSS disasters.

The "Software Engineering Body of Knowledge" is supposed to
summarize all you need to know to develop big projects.. yet
it says essentially NOTHING about secure programming
(it presumes that all programs are stand-alone, and never connect
to an Internet or use data from an Internet - a ludicrous assumption).
(P.S. I understand that it's being updated, hopefully it'll correct this.)

I'd agree that "check your inputs" is a good programming
practice, and is also critically important to secure programming.
But it's not enough, and what people think of when you say
"check your inputs" is VERY different when you talk to security-minded
people vs. the general public.

One well-known book (I think it was "Joel on Software") has some
nice suggestions, but strongly argues that you should accept
data from anywhere and just run it (i.e., that you shouldn't
treat data and code as something separate). It claimed that sandboxing
is a waste of time, and not worthwhile, even when running code from
arbitrary locations... just ask the user if it's okay or not
(we know that users always say "yes"). When that author thinks
"check your inputs", he's thinking "check the syntax" -
not "prevent damage".  This is NOT a matter of "didn't implement it
right" - the program is working AS DESIGNED.  These programs
are SPECIALLY DESIGNED to be insecure.  And this was strongly
argued as a GOOD programming practice.

 > People just don't care.

There, unfortunately, we agree.  Though there's hope for the future.

--- David A. Wheeler



From leichter_jerrold at emc.com  Thu Oct 12 15:19:07 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Thu, 12 Oct 2006 15:19:07 -0400 (EDT)
Subject: [SC-L] Secure programming is NOT just good programming
In-Reply-To: <452E62F8.3050209@ida.org>
References: <mailman.194.1160651617.4113.sc-l@securecoding.org>
	<452E62F8.3050209@ida.org>
Message-ID: <Pine.SOL.4.61.0610121504170.2822@mental>

| Here are some practices you should typically be doing
| if you're worried about security, and note that many are
| typically NOT considered "good programming"
| by the general community of software developers:
| * You need to identify your threats that you'll counter (as requirements)
| * Design so that the threats are countered, e.g., mutually
|    suspicious processes, small trusted computer base (TCB), etc.
| * Choose programming languages where you're less likely to
|    have security flaws, and where you can't (e.g., must use C/C++), use extra
|    security scanning tools and warning flags to reduce the risk.
| * Train on the specific common SECURITY failures of that
|    language, so you can avoid them. (E.G., gets() is verbotin.)
| * Have peer reviews of the code, so that others can help find
|    problems/vulnerabilities.
| * Test specifically for security properties, and use fuzz testing
|    rigged to test for them.
| Few of these are done, particularly the first two. I'll concede
| that many open source software projects do peer reviews, 
Actually, I wouldn't even concede that.  Checking for security properties
is not the same thing as checking for correct implementation of the
intended functionality (unless your spec of the intended functionality
is extraordinarly good).  It takes practice to even know what to look
for in a security-oriented peer review.  To take one trivial example:
Since there is never enough time to do a really complete review, most
reviewers will naturally emphasize the paths executed in the common
use cases.  They will de-emphasize, and often outright ignore, the
rare cases and even more so the error paths.  Unfortunately, it's
exactly in those rare or "can't happen" or "bad error" paths that
most security bugs lie.

|							   but you
| really want ALL of these practices.
| 
| Next, "Most books teach good programming." Pooey, though I wish they did.
| I still find buffer overflows in examples inside books on C/C++.
| I know the first version of K&R used scanf("...%s..."..) without noting
| that you could NEVER use this on untrusted input; I think the
| second edition used gets() without commenting on its security problems.
| A typical PHP book is littered with examples that are XSS disasters.
I agree 100% here.  At best, you'll get one example of how you should
"test your inputs for reasonable values".

| The "Software Engineering Body of Knowledge" is supposed to
| summarize all you need to know to develop big projects.. yet
| it says essentially NOTHING about secure programming
| (it presumes that all programs are stand-alone, and never connect
| to an Internet or use data from an Internet - a ludicrous assumption).
| (P.S. I understand that it's being updated, hopefully it'll correct this.)
| 
| I'd agree that "check your inputs" is a good programming
| practice, and is also critically important to secure programming.
| But it's not enough, and what people think of when you say
| "check your inputs" is VERY different when you talk to security-minded
| people vs. the general public.
| 
| One well-known book (I think it was "Joel on Software") has some
| nice suggestions, but strongly argues that you should accept
| data from anywhere and just run it (i.e., that you shouldn't
| treat data and code as something separate). It claimed that sandboxing
| is a waste of time, and not worthwhile, even when running code from
| arbitrary locations... just ask the user if it's okay or not
| (we know that users always say "yes"). When that author thinks
| "check your inputs", he's thinking "check the syntax" -
| not "prevent damage".  This is NOT a matter of "didn't implement it
| right" - the program is working AS DESIGNED.  These programs
| are SPECIALLY DESIGNED to be insecure.  And this was strongly
| argued as a GOOD programming practice.
The classic example of checking inputs you find in beginner's texts is
for a program that computes the area of a triangle given its three
sides.  The "careful" program checks that the three sides do, indeed,
describe a triangle!  OK - but I have yet to see a worked version of
this problem that checks for overflows.  And once that example is past,
all the rest of the examples "focus on the issue at hand", and ignore
the messy realities of data validation, errors, and so on.

|  > People just don't care.
| 
| There, unfortunately, we agree.  Though there's hope for the future.
Trying to get people to write safe code, or check for safety properties,
is not a practical solution.  In the languages we have, *some* people
can do it *some* of the time.  But it's simply not the kind of thing
that people are good at:  It requires close concentration on "irrelevant"
details.  You can't get tired; you can't get distracted.  Assuming
this kind of thing simply reveals a complete misunderstanding of the
way the human mind works.

The only way forward is by having the *computer* do this kind of
thing for us.  The requirements of the task are very much like those
of low-level code optimization:  We leave that to the compilers today,
because hardly anyone can do it well at all, much less competitively
with decent code generators, except in very special circumstances.
Code inspection tools are a necessary transitional step - just as
Purify-like tools are an essential transitional step to find memory
leaks in code that does manual storage management.  But until we can
figure out how to create safer *languages* - doing for security what
garbage collection does for memory management - we'll always be
several steps behind.
							-- Jerry


From gem at cigital.com  Thu Oct 12 16:32:46 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 12 Oct 2006 16:32:46 -0400
Subject: [SC-L] Secure programming is NOT just good programming
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E7925@va-mail.cigital.com>

I suppose now is as good a time as any to say that everything david is talking about here is described in great detail in the HOW TO book that I released last february.   If you're reading this list, you really should read that book.  It's called "software security".   

Ken and I have trained thousands of developers using the book as a guide with some success.  Cigital has a number of very large-scale software security initiatives underway at various customers that leverage that training.  But more importantly, good programs instill and measure the kinds of best practices (called touchpoints in the book) that are certainly not part of standard good coding practice.

See www.swsec.com for more.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 

 -----Original Message-----
From: 	Leichter, Jerry [mailto:leichter_jerrold at emc.com]
Sent:	Thu Oct 12 16:24:35 2006
To:	David A. Wheeler
Cc:	sc-l at securecoding.org
Subject:	Re: [SC-L] Secure programming is NOT just good programming

| Here are some practices you should typically be doing
| if you're worried about security, and note that many are
| typically NOT considered "good programming"
| by the general community of software developers:
| * You need to identify your threats that you'll counter (as requirements)
| * Design so that the threats are countered, e.g., mutually
|    suspicious processes, small trusted computer base (TCB), etc.
| * Choose programming languages where you're less likely to
|    have security flaws, and where you can't (e.g., must use C/C++), use extra
|    security scanning tools and warning flags to reduce the risk.
| * Train on the specific common SECURITY failures of that
|    language, so you can avoid them. (E.G., gets() is verbotin.)
| * Have peer reviews of the code, so that others can help find
|    problems/vulnerabilities.
| * Test specifically for security properties, and use fuzz testing
|    rigged to test for them.
| Few of these are done, particularly the first two. I'll concede
| that many open source software projects do peer reviews, 
Actually, I wouldn't even concede that.  Checking for security properties
is not the same thing as checking for correct implementation of the
intended functionality (unless your spec of the intended functionality
is extraordinarly good).  It takes practice to even know what to look
for in a security-oriented peer review.  To take one trivial example:
Since there is never enough time to do a really complete review, most
reviewers will naturally emphasize the paths executed in the common
use cases.  They will de-emphasize, and often outright ignore, the
rare cases and even more so the error paths.  Unfortunately, it's
exactly in those rare or "can't happen" or "bad error" paths that
most security bugs lie.

|							   but you
| really want ALL of these practices.
| 
| Next, "Most books teach good programming." Pooey, though I wish they did.
| I still find buffer overflows in examples inside books on C/C++.
| I know the first version of K&R used scanf("...%s..."..) without noting
| that you could NEVER use this on untrusted input; I think the
| second edition used gets() without commenting on its security problems.
| A typical PHP book is littered with examples that are XSS disasters.
I agree 100% here.  At best, you'll get one example of how you should
"test your inputs for reasonable values".

| The "Software Engineering Body of Knowledge" is supposed to
| summarize all you need to know to develop big projects.. yet
| it says essentially NOTHING about secure programming
| (it presumes that all programs are stand-alone, and never connect
| to an Internet or use data from an Internet - a ludicrous assumption).
| (P.S. I understand that it's being updated, hopefully it'll correct this.)
| 
| I'd agree that "check your inputs" is a good programming
| practice, and is also critically important to secure programming.
| But it's not enough, and what people think of when you say
| "check your inputs" is VERY different when you talk to security-minded
| people vs. the general public.
| 
| One well-known book (I think it was "Joel on Software") has some
| nice suggestions, but strongly argues that you should accept
| data from anywhere and just run it (i.e., that you shouldn't
| treat data and code as something separate). It claimed that sandboxing
| is a waste of time, and not worthwhile, even when running code from
| arbitrary locations... just ask the user if it's okay or not
| (we know that users always say "yes"). When that author thinks
| "check your inputs", he's thinking "check the syntax" -
| not "prevent damage".  This is NOT a matter of "didn't implement it
| right" - the program is working AS DESIGNED.  These programs
| are SPECIALLY DESIGNED to be insecure.  And this was strongly
| argued as a GOOD programming practice.
The classic example of checking inputs you find in beginner's texts is
for a program that computes the area of a triangle given its three
sides.  The "careful" program checks that the three sides do, indeed,
describe a triangle!  OK - but I have yet to see a worked version of
this problem that checks for overflows.  And once that example is past,
all the rest of the examples "focus on the issue at hand", and ignore
the messy realities of data validation, errors, and so on.

|  > People just don't care.
| 
| There, unfortunately, we agree.  Though there's hope for the future.
Trying to get people to write safe code, or check for safety properties,
is not a practical solution.  In the languages we have, *some* people
can do it *some* of the time.  But it's simply not the kind of thing
that people are good at:  It requires close concentration on "irrelevant"
details.  You can't get tired; you can't get distracted.  Assuming
this kind of thing simply reveals a complete misunderstanding of the
way the human mind works.

The only way forward is by having the *computer* do this kind of
thing for us.  The requirements of the task are very much like those
of low-level code optimization:  We leave that to the compilers today,
because hardly anyone can do it well at all, much less competitively
with decent code generators, except in very special circumstances.
Code inspection tools are a necessary transitional step - just as
Purify-like tools are an essential transitional step to find memory
leaks in code that does manual storage management.  But until we can
figure out how to create safer *languages* - doing for security what
garbage collection does for memory management - we'll always be
several steps behind.
							-- Jerry

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ljknews at mac.com  Thu Oct 12 16:42:09 2006
From: ljknews at mac.com (ljknews)
Date: Thu, 12 Oct 2006 16:42:09 -0400
Subject: [SC-L] Secure programming is NOT just good programming
In-Reply-To: <Pine.SOL.4.61.0610121504170.2822@mental>
References: <mailman.194.1160651617.4113.sc-l@securecoding.org>
	<452E62F8.3050209@ida.org> <Pine.SOL.4.61.0610121504170.2822@mental>
Message-ID: <p05200f08c154587ee058@[192.168.1.254]>

At 3:19 PM -0400 10/12/06, Leichter, Jerry wrote:

> The only way forward is by having the *computer* do this kind of
> thing for us.  The requirements of the task are very much like those
> of low-level code optimization:  We leave that to the compilers today,
> because hardly anyone can do it well at all, much less competitively
> with decent code generators, except in very special circumstances.
> Code inspection tools are a necessary transitional step - just as
> Purify-like tools are an essential transitional step to find memory
> leaks in code that does manual storage management.  But until we can
> figure out how to create safer *languages* - doing for security what
> garbage collection does for memory management - we'll always be
> several steps behind.

It is not adequate to *create* safer languages - it is necessary to
have developers *use* those languages.  Given the emphasis on C and
C++ within posts on this list, that seems a long way off.
-- 
Larry Kilgallen

From ken at krvw.com  Thu Oct 12 16:59:46 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 12 Oct 2006 16:59:46 -0400
Subject: [SC-L] Secure programming is NOT just good programming
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E7925@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E7925@va-mail.cigital.com>
Message-ID: <87B47C12-572A-4363-8496-C62A6D79E682@krvw.com>

On Oct 12, 2006, at 4:32 PM, Gary McGraw wrote:
> I suppose now is as good a time as any to say that everything david  
> is talking about here is described in great detail in the HOW TO  
> book that I released last february.   If you're reading this list,  
> you really should read that book.  It's called "software security".
>
> Ken and I have trained thousands of developers using the book as a  
> guide with some success.  Cigital has a number of very large-scale  
> software security initiatives underway at various customers that  
> leverage that training.  But more importantly, good programs  
> instill and measure the kinds of best practices (called touchpoints  
> in the book) that are certainly not part of standard good coding  
> practice.

Presuming you meant "now part of..." and not "not part of..."

In any case, another great source of information on the touchpoint  
processes in Gary's book is the DHS-sponsored Build Security In  
portal at http://BuildSecurityIn.us-cert.gov.  It's still a work in  
progress, but there are a bunch of in-depth articles explaining all  
of Gary's touchpoint activities and such.  Plus, several new articles  
will be appearing there over the next few months, so keep checking in  
for updates.  The site is free and open to the public.  (Full  
disclosure: as one of the BSI authors, I'm certainly not unbiased,  
but I still believe it's a valuable resource for those who are  
interested in learning more about the touchpoints Gary cited.)

Cheers,

Ken
-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20061012/03ac81d7/attachment-0001.bin 

From leichter_jerrold at emc.com  Thu Oct 12 17:15:26 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Thu, 12 Oct 2006 17:15:26 -0400 (EDT)
Subject: [SC-L] Secure programming is NOT just good programming
In-Reply-To: <p05200f08c154587ee058@[192.168.1.254]>
References: <mailman.194.1160651617.4113.sc-l@securecoding.org>
	<452E62F8.3050209@ida.org> <Pine.SOL.4.61.0610121504170.2822@mental>
	<p05200f08c154587ee058@[192.168.1.254]>
Message-ID: <Pine.SOL.4.61.0610121659420.2822@mental>

| > The only way forward is by having the *computer* do this kind of
| > thing for us.  The requirements of the task are very much like those
| > of low-level code optimization:  We leave that to the compilers today,
| > because hardly anyone can do it well at all, much less competitively
| > with decent code generators, except in very special circumstances.
| > Code inspection tools are a necessary transitional step - just as
| > Purify-like tools are an essential transitional step to find memory
| > leaks in code that does manual storage management.  But until we can
| > figure out how to create safer *languages* - doing for security what
| > garbage collection does for memory management - we'll always be
| > several steps behind.
| 
| It is not adequate to *create* safer languages - it is necessary to
| have developers *use* those languages.  Given the emphasis on C and
| C++ within posts on this list, that seems a long way off.
Fifteen years ago, the idea that a huge portion of new software would be
developed in garbage-collected languages with safe memory semantics
would have seemed a far-off dream.  But in fact we are there today,
with Java and C#, not to mention even higher-level from Python to Ruby.
(Of course, then you can go to PHP.  We know how secure that's turned
out to be... though that's not really a fair attack:  The attacks against
PHP are "new style" - directory traversals, XSS - and nothing out there
provides any inherent protection against them either.)

Yes, there is still *tons* of C and C++ code out there, and more is still
being developed.  But there are many places where you have to justify
using C++ rather than Java.  (There are good reasons, because neither
Java no C# are really quite there yet for many applications.)  

In any case, language is to a degree a misdirection on my part.  What
matters is not just the language, but the libraries and development
methodologies and the entire development environment.  Just as security
properties are *system* properties of the full system, "good for
development of secure systems" is a system property of the entire
development methodology/mechanism/environment.  C/C++ plus static
analysis plus Purify over test runs with good code coverage plus
automated "fuzz" generation/testing would probably be close to as good
as you can get today - not that any such integrated system exists
anywhere I know of.  Replacing some of the C/C++ libraries with
inherently safer versions could only help.

It's not that training in secure coding practices isn't important.
We're starting from such a low level today that this kind of low-lying
fruit must be picked.  I'm looking out beyond that.  I think security
awareness, on its own, will only get us so far - and it's not nearly
far enough.
							-- Jerry


From michaelslists at gmail.com  Thu Oct 12 19:13:48 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Fri, 13 Oct 2006 09:13:48 +1000
Subject: [SC-L] Secure programming is NOT just good programming
In-Reply-To: <452E62F8.3050209@ida.org>
References: <mailman.194.1160651617.4113.sc-l@securecoding.org>
	<452E62F8.3050209@ida.org>
Message-ID: <5e01c29a0610121613s15438d1dq624a2339e1ef9806@mail.gmail.com>

On 10/13/06, David A. Wheeler <dwheeler at ida.org> wrote:
> mikeiscool claimed:
> > Secure programming is good programming.
>  > Most books teach good programming.
>
> I strongly disagree with you, on both counts.

As is your right :)


> At the least, those who say they practice good programming
> practices, and books that say they teach good programming
> practices, are GROSSLY INADEQUATE for developing secure programs.

Sure.


> First, "Secure programming is good programming":
> Most people and organizations who claim that they perform
> good programming practices do NOT perform practices
> necessary for security.  You could argue that therefore they
> aren't really doing "good programming", but that doesn't
> help fix anything.

That's not an argument against it. I believe it will help, anyway, if
you can say to the public: "this program is written badly" instead of
"this program is written unsecurely". Almost everyone doesn't want to
hear the second version. If they ask why, well you can explain. But
keep it simple.


> And organizations STILL generally
> place features over security, and when there's a perceived
> conflict, security almost always loses... and they'll STILL
> say that they practice "good programming" practices (they just
> happen to correctly implement insecure programs).

You can design an insecure program that is coded well, and hence only
insecure in the ways you wish. You are mixing secure/good programming
with secure/good design.


> Here are some practices you should typically be doing
> if you're worried about security, and note that many are
> typically NOT considered "good programming"
> by the general community of software developers:
> * You need to identify your threats that you'll counter (as requirements)
> * Design so that the threats are countered, e.g., mutually
>    suspicious processes, small trusted computer base (TCB), etc.
> * Choose programming languages where you're less likely to
>    have security flaws, and where you can't (e.g., must use C/C++), use extra
>    security scanning tools and warning flags to reduce the risk.
> * Train on the specific common SECURITY failures of that
>    language, so you can avoid them. (E.G., gets() is verbotin.)
> * Have peer reviews of the code, so that others can help find
>    problems/vulnerabilities.
> * Test specifically for security properties, and use fuzz testing
>    rigged to test for them.
> Few of these are done, particularly the first two. I'll concede
> that many open source software projects do peer reviews, but you
> really want ALL of these practices.

Yep.


> Next, "Most books teach good programming." Pooey, though I wish they did.

Okay that was wishful thinking.


> I still find buffer overflows in examples inside books on C/C++.
> I know the first version of K&R used scanf("...%s..."..) without noting
> that you could NEVER use this on untrusted input; I think the
> second edition used gets() without commenting on its security problems.
> A typical PHP book is littered with examples that are XSS disasters.

Fair enough.


> The "Software Engineering Body of Knowledge" is supposed to
> summarize all you need to know to develop big projects.. yet
> it says essentially NOTHING about secure programming
> (it presumes that all programs are stand-alone, and never connect
> to an Internet or use data from an Internet - a ludicrous assumption).
> (P.S. I understand that it's being updated, hopefully it'll correct this.)
>
> I'd agree that "check your inputs" is a good programming
> practice, and is also critically important to secure programming.
> But it's not enough, and what people think of when you say
> "check your inputs" is VERY different when you talk to security-minded
> people vs. the general public.

Yep.


> One well-known book (I think it was "Joel on Software") has some
> nice suggestions, but strongly argues that you should accept
> data from anywhere and just run it (i.e., that you shouldn't
> treat data and code as something separate). It claimed that sandboxing
> is a waste of time, and not worthwhile, even when running code from
> arbitrary locations... just ask the user if it's okay or not
> (we know that users always say "yes"). When that author thinks
> "check your inputs", he's thinking "check the syntax" -
> not "prevent damage".  This is NOT a matter of "didn't implement it
> right" - the program is working AS DESIGNED.  These programs
> are SPECIALLY DESIGNED to be insecure.  And this was strongly
> argued as a GOOD programming practice.

Which is clearly wrong.


>  > People just don't care.
>
> There, unfortunately, we agree.  Though there's hope for the future.
>
> --- David A. Wheeler

-- mic

From cew at ACM.ORG  Thu Oct 12 21:14:26 2006
From: cew at ACM.ORG (Craig E. Ward)
Date: Thu, 12 Oct 2006 18:14:26 -0700
Subject: [SC-L] re-writing college books [was: Re: A banner year for
 software bugs | Tech News on ZDNet]
In-Reply-To: <p05200f04c153fa95cffd@[192.168.1.254]>
References: <Pine.LNX.4.21.0610112027520.17257-100000@linuxbox.org>
	<452E4116.6020101@cert.org> <p05200f04c153fa95cffd@[192.168.1.254]>
Message-ID: <p06230901c15496113992@[192.168.123.172]>

At 10:03 AM -0400 10/12/06, ljknews wrote:
>At 9:20 AM -0400 10/12/06, Robert C. Seacord wrote:
>
>>  I'm also teaching a course at CMU in the spring on Secure Coding in C
>>  and C++.
>
>Is there participation on this list from the (hopefully larger number of)
>CMU instructors who are teaching people to use safer languages in the first
>place ?
>--
>Larry Kilgallen


I don't think saying "use safer languages" is a good way to say it. 
It would help conditions significantly if greater care were taken to 
match the choice of programming language to the problem to be solved 
or application to be created. If a language like C is most 
appropriate, then use it, just be sure to take the extra steps needed 
to develop it securely.

The problem is so much the programming languages as it is the way 
they are used.

Craig
-- 
Internet: cew at ACM.ORG
"If a program has not been specified, it cannot be incorrect; it can 
only be surprising." (Young, Boebert, and Kain)

From weld at vulnwatch.org  Fri Oct 13 00:03:50 2006
From: weld at vulnwatch.org (Chris Wysopal)
Date: Thu, 12 Oct 2006 23:03:50 -0500 (EST)
Subject: [SC-L] darkreading: voting machines
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6FEBA3@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB6FEBA3@va-mail.cigital.com>
Message-ID: <Pine.BSO.4.55.0610122257510.27980@vikki.vulnwatch.org>



On Mon, 9 Oct 2006, Gary McGraw wrote:

> The most interesting thing from an sc-l perspective about this column is
> that it emphasizes a client need we're often forced to address---the
> need for a demo exploit.  Sometimes those on the receiving end of a
> software security vulnerability don't believe that findings are real.
> An often-repeated excuse for doing nothing is "well, that's just a
> theoretical attack and it's too academic to matter."  I can't tell you
> how many times I've heard that refrain.

In 1998 we put a slogan on the L0pht.com web page.

   "That vulnerability is theoretical." -Microsoft

   L0pht - making the theoretical practical since 1992.

Microsoft doesn't say that line any more.  I guess a few worms can change
your tune.  It seems that you need to get bitten a few times before you
automatically put on the bug spray before heading down to the swamp.

-Chris

From weld at vulnwatch.org  Fri Oct 13 00:24:22 2006
From: weld at vulnwatch.org (Chris Wysopal)
Date: Thu, 12 Oct 2006 23:24:22 -0500 (EST)
Subject: [SC-L] darkreading: voting machines
In-Reply-To: <C4B880098AA68B4CB4A0B82B1419A460021D4C76@mailva>
References: <C4B880098AA68B4CB4A0B82B1419A460021D4C76@mailva>
Message-ID: <Pine.BSO.4.55.0610122311190.27980@vikki.vulnwatch.org>


I think there is an easy solution to this.  It is called a 3rd party
audit.  This is done all the time in the financial community.  Software
vendors fork over their latest product version and sometimes source code
and a credible 3rd party looks for holes.  It is sometimes paid for by the
customer and sometimes the customer makes it a requirement of purchase so
it is paid for by the vendor.  We did many of these at @stake.

Why do banks do this?  Some say it is because they don't like to go to
jail or be fined for not following the nebulous "reasonable care"
provisions of the regulations they are required to follow.  It is more
likely they don't want to tarnish their trusted brand image.

A voting commission has neither of these motivations.  No one gets fined
or fired or put in jail for fielding a system that ends up being used for
voter fraud.  There is no trusted image to protect.

The "pretend stuff in the lab" comment is especially discouraging because
what Rubin and Felten are doing in the lab is EXACTLY what Diebold should
be doing in their testing lab.  A product that has security requirements
is not fit to be fielded until security testing has been performed.

-Chris

-= The Art of Software Security Testing: Identifying Software Security
-= Flaws by Chris Wysopal, Lucas Nelson, Dino Dai Zovi, and Elfriede
-= Dustin, Available Nov 27, 2006

On Tue, 10 Oct 2006, Jeremy Epstein wrote:

> Gary,
>
> Interesting point.  I'm on the Virginia state commission charged with making
> recommendations around voting systems, and we watched the Princeton video as
> part of our most recent meeting.  The reaction from the election officials
> was amusing and scary: "if this is so real, why don't you hack a real
> election instead of this pretend stuff in the lab".  Pointing out that it
> would (most likely) be a felony, and people like Rubin, Felten, and others
> are trying to help security not go to jail didn't seem to impress them.
> Also pointing out that the Rubin & Felten examples used out-of-date code
> because vendors won't share anything up-to-date doesn't seem to impress
> them.  [This in response to Diebold's claim that they were looking at old
> code, and the problems are all "fixed".]
>
> I frankly don't think anything is going to impress the election officials
> (and some of the elected officials) short of incontrovertible evidence of a
> DRE meltdown - and of course, we know that there could well be a failure
> (and may have been failures) that are unproveable thanks to the nature of
> software.
>
> --Jeremy
>
> P.S. One of the elected officials on the commision insisted that Felten
> couldn't possibly have done his demo exploit without source code, because
> "everyone" knows you can't do an exploit without the source.  Unfortunately,
> the level of education that needs to be provided to someone like that is
> more than I can provide in a Q&A format.  I tried giving as an example that
> around 50% of the Microsoft updates are due to flaws found by people without
> source, but he wouldn't buy it.... (he was using a Windows laptop, but
> doesn't seem to understand where the fixes come from).
>
> > -----Original Message-----
> > From: sc-l-bounces at securecoding.org
> > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Gary McGraw
> > Sent: Monday, October 09, 2006 12:19 PM
> > To: SC-L at securecoding.org
> > Cc: dwallach at cs.rice.edu; felten at princeton.edu; rubin at jhu.edu
> > Subject: [SC-L] darkreading: voting machines
> >
> > Hi all,
> >
> > I'm sure that many of you saw the "Ed Felten and friends
> > break Diebold machines" story a couple of weeks ago...maybe
> > in DDJ or on /..  I wrote a piece about the crack for
> > darkreading, which you can find here:
> >
> > http://www.darkreading.com/document.asp?doc_id=105188&WT.svl=column1_1
> >
> > The most interesting thing from an sc-l perspective about
> > this column is that it emphasizes a client need we're often
> > forced to address---the need for a demo exploit.  Sometimes
> > those on the receiving end of a software security
> > vulnerability don't believe that findings are real.
> > An often-repeated excuse for doing nothing is "well, that's
> > just a theoretical attack and it's too academic to matter."
> > I can't tell you how many times I've heard that refrain.
> >
> > When that happens, building an exploit is often the only
> > clear next step.  And yet we all know how expensive and hard
> > exploit development is.
> >
> > In this case, Diebold consistently downplay'ed Avi Rubin's
> > results as "academic" or "theoretical."  Ed upped the ante.
> > Think it'll work??
> >
> > gem
> >
> > company www.cigital.com
> > podcast www.cigital.com/silverbullet
> > book www.swsec.com
> >
> >
> > --------------------------------------------------------------
> > --------------
> > This electronic message transmission contains information
> > that may be confidential or privileged.  The information
> > contained herein is intended solely for the recipient and use
> > by any other party is not authorized.  If you are not the
> > intended recipient (or otherwise authorized to receive this
> > message by the intended recipient), any disclosure, copying,
> > distribution or use of the contents of the information is
> > prohibited.  If you have received this electronic message
> > transmission in error, please contact the sender by reply
> > email and delete all copies of this message.  Cigital, Inc.
> > accepts no responsibility for any loss or damage resulting
> > directly or indirectly from the use of this email or its contents.
> > Thank You.
> > --------------------------------------------------------------
> > --------------
> >
> > _______________________________________________
> > Secure Coding mailing list (SC-L)
> > SC-L at securecoding.org
> > List information, subscriptions, etc -
> > http://krvw.com/mailman/listinfo/sc-l
> > List charter available at -
> > http://www.securecoding.org/list/charter.php
> >
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>

From michaelslists at gmail.com  Fri Oct 13 07:02:23 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Fri, 13 Oct 2006 21:02:23 +1000
Subject: [SC-L] re-writing college books [was: Re: A banner year for
	software bugs | Tech News on ZDNet]
In-Reply-To: <p06230901c15496113992@192.168.123.172>
References: <Pine.LNX.4.21.0610112027520.17257-100000@linuxbox.org>
	<452E4116.6020101@cert.org> <p05200f04c153fa95cffd@192.168.1.254>
	<p06230901c15496113992@192.168.123.172>
Message-ID: <5e01c29a0610130402y7e6ae0b0ufb197d9481a1f960@mail.gmail.com>

On 10/13/06, Craig E. Ward <cew at acm.org> wrote:
> At 10:03 AM -0400 10/12/06, ljknews wrote:
> >At 9:20 AM -0400 10/12/06, Robert C. Seacord wrote:
> >
> >>  I'm also teaching a course at CMU in the spring on Secure Coding in C
> >>  and C++.
> >
> >Is there participation on this list from the (hopefully larger number of)
> >CMU instructors who are teaching people to use safer languages in the first
> >place ?
> >--
> >Larry Kilgallen
>
>
> I don't think saying "use safer languages" is a good way to say it.
> It would help conditions significantly if greater care were taken to
> match the choice of programming language to the problem to be solved
> or application to be created. If a language like C is most
> appropriate, then use it, just be sure to take the extra steps needed
> to develop it securely.
>
> The problem is so much the programming languages as it is the way
> they are used.

Well, programming languages can go a long way to helping solve the
problem, and it can be reasonably grey as to where to use what. Should
I use php or ror? or python? or c#? I'd say there is a very
appropriate and open space for nice "secure" languages to live and
develop.


> Craig

-- mic

From james.walden at gmail.com  Fri Oct 13 12:11:43 2006
From: james.walden at gmail.com (James Walden)
Date: Fri, 13 Oct 2006 12:11:43 -0400
Subject: [SC-L] re-writing college books [was: Re: A banner year for
	software bugs | Tech News on ZDNet]
In-Reply-To: <p06230901c15496113992@192.168.123.172>
References: <Pine.LNX.4.21.0610112027520.17257-100000@linuxbox.org>
	<452E4116.6020101@cert.org> <p05200f04c153fa95cffd@192.168.1.254>
	<p06230901c15496113992@192.168.123.172>
Message-ID: <21c655860610130911m1fb19856t2f54c417cf2dcfc9@mail.gmail.com>

On 10/12/06, Craig E. Ward <cew at acm.org> wrote:

> I don't think saying "use safer languages" is a good way to say it.
> It would help conditions significantly if greater care were taken to
> match the choice of programming language to the problem to be solved
> or application to be created. If a language like C is most
> appropriate, then use it, just be sure to take the extra steps needed
> to develop it securely.


I agree that the programming language should be chosen to match the problem,
though it's worth pointing out that security is typically part of the
problem to be solved.  There are safer systems programming languages than C,
such as D and Cyclone.  If you've considered the alternatives and you really
have to use C because it's the only thing that will do, then yes, use it and
be sure to use it securely and verify that fact with static analysis tools
and code reviews.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061013/d5fe3658/attachment.html 

From cew at ACM.ORG  Fri Oct 13 20:32:59 2006
From: cew at ACM.ORG (Craig E. Ward)
Date: Fri, 13 Oct 2006 17:32:59 -0700
Subject: [SC-L] re-writing college books [was: Re: A banner year for
 software bugs | Tech News on ZDNet]
In-Reply-To: <5e01c29a0610130402y7e6ae0b0ufb197d9481a1f960@mail.gmail.com>
References: <Pine.LNX.4.21.0610112027520.17257-100000@linuxbox.org>	
	<452E4116.6020101@cert.org> <p05200f04c153fa95cffd@192.168.1.254>	
	<p06230901c15496113992@192.168.123.172>
	<5e01c29a0610130402y7e6ae0b0ufb197d9481a1f960@mail.gmail.com>
Message-ID: <p06230900c155def43546@[192.168.123.172]>

At 9:02 PM +1000 10/13/06, mikeiscool wrote:
>On 10/13/06, Craig E. Ward <cew at acm.org> wrote:
>>At 10:03 AM -0400 10/12/06, ljknews wrote:
>>>At 9:20 AM -0400 10/12/06, Robert C. Seacord wrote:
>>>
>>>>   I'm also teaching a course at CMU in the spring on Secure Coding in C
>>>>   and C++.
>>>
>>>Is there participation on this list from the (hopefully larger number of)
>>>CMU instructors who are teaching people to use safer languages in the first
>>>place ?
>>>--
>>>Larry Kilgallen
>>
>>
>>I don't think saying "use safer languages" is a good way to say it.
>>It would help conditions significantly if greater care were taken to
>>match the choice of programming language to the problem to be solved
>>or application to be created. If a language like C is most
>>appropriate, then use it, just be sure to take the extra steps needed
>>to develop it securely.
>>
>>The problem is so much the programming languages as it is the way
>>they are used.
>
>Well, programming languages can go a long way to helping solve the
>problem, and it can be reasonably grey as to where to use what. Should
>I use php or ror? or python? or c#? I'd say there is a very
>appropriate and open space for nice "secure" languages to live and
>develop.

I think that's what I was trying to say. The last sentence of my note 
has an error. I meant to write "The problem is not so much the 
programming languages as it is the way they are used."

Sorry for the bad proof reading.

Also, in the IEEE Software July/August 2006 issue in the "Tools of 
the Trade" department, Diomidis Spinellis discusses several factors 
to consider when selecting a programming language for a particular 
project. Those plus security make for some reasonable criteria to use.

Craig
-- 
Internet: cew at ACM.ORG
"If a program has not been specified, it cannot be incorrect; it can 
only be surprising." (Young, Boebert, and Kain)

From Holger.Peine at iese.fraunhofer.de  Mon Oct 16 06:42:04 2006
From: Holger.Peine at iese.fraunhofer.de (Holger.Peine at iese.fraunhofer.de)
Date: Mon, 16 Oct 2006 12:42:04 +0200
Subject: [SC-L] Need a few slides/data on surging importance of security and
	source code security
Message-ID: <687F148231CEBF449E6206E3FA7AAC3F20C191@hermes.iese.fhg.de>

I am sure that quite a few of you already have done or know
who has done this non-technical, "mundane" job: I need a few
slides with data (e.g. numbers, or maybe historic examples) to 
convince a management-level audience of a manufacturer of networked 
appliances who has only a dim view of security of two things:

- security is a problem for anybody developing software running 
  on networked hardware, and it is a rapidly growing problem with
  a clear economic impact

- a large part of vulnerabilities stems from bad coding practices,
  and there are companies that actively and successfully combat this

Pointers to relevant web pages would be nearly as nice as finished
Powerpoint slides.

(Aside: You shouldn't view my request like that of a student asking for
someone to steal his homework from: Everyone in our community needs 
such data in some form or other at some time, and we should all
contribute
to making everyone in the community look as good as possible in this
respect in, to advance our common cause of more secure software. I have
contributed to the community, too.)

Thanks for your input,
Holger Peine

-- 
Dr. Holger Peine, Security and Safety
Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
Phone +49-631-6800-2134, Fax -1899 (shared)
PGP key via http://pgp.mit.edu ; fingerprint is 1BFA 30CB E3ED BA99 E7AE
2BBB C126 A592 48EA F9F8


From ljknews at mac.com  Tue Oct 17 12:43:49 2006
From: ljknews at mac.com (ljknews)
Date: Tue, 17 Oct 2006 12:43:49 -0400
Subject: [SC-L] re-writing college books [was: Re: A banner year for
 software bugs | Tech News on ZDNet]
In-Reply-To: <21c655860610130911m1fb19856t2f54c417cf2dcfc9@mail.gmail.com>
References: <Pine.LNX.4.21.0610112027520.17257-100000@linuxbox.org>
	<452E4116.6020101@cert.org> <p05200f04c153fa95cffd@192.168.1.254>
	<p06230901c15496113992@192.168.123.172>
	<21c655860610130911m1fb19856t2f54c417cf2dcfc9@mail.gmail.com>
Message-ID: <p05200f05c15ab879e8ad@[192.168.1.254]>

At 12:11 PM -0400 10/13/06, James Walden wrote:

> you really have to use C because it's the only thing that will do,

That seems extremely improbable.
-- 
Larry Kilgallen

From rcs at cert.org  Tue Oct 17 13:51:57 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Tue, 17 Oct 2006 13:51:57 -0400
Subject: [SC-L] Need a few slides/data on surging importance of security
 and	source code security
In-Reply-To: <687F148231CEBF449E6206E3FA7AAC3F20C191@hermes.iese.fhg.de>
References: <687F148231CEBF449E6206E3FA7AAC3F20C191@hermes.iese.fhg.de>
Message-ID: <4535183D.5010509@cert.org>

Holger,

There are a bunch of slide sets on the CERT web site at:

http://www.cert.org/nav/present.html

The one labeled "Home Computer and Internet User Security (ppt)" might
be close to what you need.

I have some slide sets up there as well, but my stuff is too detailed
for a management audience.

rCs



> I am sure that quite a few of you already have done or know
> who has done this non-technical, "mundane" job: I need a few
> slides with data (e.g. numbers, or maybe historic examples) to 
> convince a management-level audience of a manufacturer of networked 
> appliances who has only a dim view of security of two things:
> 
> - security is a problem for anybody developing software running 
>   on networked hardware, and it is a rapidly growing problem with
>   a clear economic impact
> 
> - a large part of vulnerabilities stems from bad coding practices,
>   and there are companies that actively and successfully combat this
> 
> Pointers to relevant web pages would be nearly as nice as finished
> Powerpoint slides.
> 
> (Aside: You shouldn't view my request like that of a student asking for
> someone to steal his homework from: Everyone in our community needs 
> such data in some form or other at some time, and we should all
> contribute
> to making everyone in the community look as good as possible in this
> respect in, to advance our common cause of more secure software. I have
> contributed to the community, too.)
> 
> Thanks for your input,
> Holger Peine
> 


-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC

Work: 412-268-7608
FAX: 412-268-6989

From gbuday at gmail.com  Wed Oct 18 03:48:30 2006
From: gbuday at gmail.com (Gergely Buday)
Date: Wed, 18 Oct 2006 09:48:30 +0200
Subject: [SC-L] re-writing college books [was: Re: A banner year for
	software bugs | Tech News on ZDNet]
In-Reply-To: <p05200f04c153fa95cffd@192.168.1.254>
References: <Pine.LNX.4.21.0610112027520.17257-100000@linuxbox.org>
	<452E4116.6020101@cert.org> <p05200f04c153fa95cffd@192.168.1.254>
Message-ID: <90d975d30610180048v3ca371fcmea2541120956d629@mail.gmail.com>

Larry Kilgallen wrote:

> Is there participation on this list from the (hopefully larger number of)
> CMU instructors who are teaching people to use safer languages in the first
> place ?

May anybody not from CMU enter the discussion about safer languages? ;-)

I'm in favor of SML, as it has a number of implementations (some of
them comparable to C in speed)  and a formal definition ("well-typed
programs do not go wrong") + a standard library.

But I do see it's hard to push it in industry. Managers like "industry
best practice" so that they need not take risk. Or, better say, they
take the risks everybody else takes just probably are not aware of
this.

>From the human resources point of view it's not that easy to find
experienced sml programmers as there are very few companies who employ
such creatures. Vicious circle, you know.

Regarding the programming environment and libraries: it's just not a
research act to develop such things for sml anymore, so academics will
not pursue it. I've heard of an NSF infrastructure grant to develop
eclipse plugin for sml, though. Industry has not catched upon yet, nor
the OSS community.

And, just as an aside: I've heard a story that some cs celebrity
(Dijkstra?) once coined some conditions for a programming language to
be successful. The last clause was "IBM should love it". Yep, we've
seen this with Java. Anybody from IBM?

- Gergely

From Holger.Peine at iese.fraunhofer.de  Wed Oct 18 07:57:35 2006
From: Holger.Peine at iese.fraunhofer.de (Holger.Peine at iese.fraunhofer.de)
Date: Wed, 18 Oct 2006 13:57:35 +0200
Subject: [SC-L] [WEB SECURITY] Need a few slides/data on surging
	importance of security and source code security
Message-ID: <687F148231CEBF449E6206E3FA7AAC3F20C224@hermes.iese.fhg.de>

Thanks to all who replied to my request; I attach the three
slides that I finally produced for your perusal.

Kind regards,
Holger Peine

-- 
Dr. Holger Peine, Security and Safety
Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
Phone +49-631-6800-2134, Fax -1899 (shared)
PGP key via http://pgp.mit.edu ; fingerprint is 1BFA 30CB E3ED BA99 E7AE
2BBB C126 A592 48EA F9F8 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data-arguing-for-software-security_2006.ppt
Type: application/vnd.ms-powerpoint
Size: 89600 bytes
Desc: data-arguing-for-software-security_2006.ppt
Url : http://krvw.com/pipermail/sc-l/attachments/20061018/a2942d87/attachment-0001.ppt 

From paco at cigital.com  Thu Oct 19 15:49:41 2006
From: paco at cigital.com (Paco Hope)
Date: Thu, 19 Oct 2006 15:49:41 -0400
Subject: [SC-L] Need a few slides/data on surging importance of security
	and source code security
In-Reply-To: <C15A87FD.91E8%paco@cigital.com>
Message-ID: <C15D4F15.9271%paco@cigital.com>

For reasons that are not worth getting into, my two cents didn't make it to
the list. I've now invested 4 cents in getting this to everyone. :)

On 10/16/06 6:42 AM, "Holger.Peine at iese.fraunhofer.de"
<Holger.Peine at iese.fraunhofer.de> wrote:

> I am sure that quite a few of you already have done or know who has done this
> non-technical, "mundane" job: I need a few slides with data (e.g. numbers, or
> maybe historic examples) to convince a management-level audience

Attached is a timeline I created from publically available data at
http://www.attrition.org/. It depicts credit card account number
compromises. It tells you who had the data, when it was compromised, and how
many accounts were lost. It is somewhat related to your need, although it
does not speak to the source code issue.

The one thing to note is that this timeline does not show the different ways
credit card accounts were compromised. Some of these were "hacks" where a
web site or online system was compromised. Some were theft of a device (like
a laptop) and some were lost backup tapes and similar failures.

I think the picture is pretty compelling and shows just how many accounts
have been compromised (that we know about) and how often it happens.

Regards,
Paco
-- 
Paco Hope, CISSP
Technical Manager, Cigital, Inc
http://www.cigital.com/ ? +1.703.585.7868
Software Confidence. Achieved.



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061019/62c10861/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CreditCardCompromises.jpg
Type: application/octet-stream
Size: 322664 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20061019/62c10861/attachment-0001.obj 

From crispin at novell.com  Tue Oct 24 15:30:44 2006
From: crispin at novell.com (Crispin Cowan)
Date: Tue, 24 Oct 2006 12:30:44 -0700
Subject: [SC-L] re-writing college books [was: Re: A banner year
 for	software bugs | Tech News on ZDNet]
In-Reply-To: <90d975d30610180048v3ca371fcmea2541120956d629@mail.gmail.com>
References: <Pine.LNX.4.21.0610112027520.17257-100000@linuxbox.org>	<452E4116.6020101@cert.org>
	<p05200f04c153fa95cffd@192.168.1.254>
	<90d975d30610180048v3ca371fcmea2541120956d629@mail.gmail.com>
Message-ID: <453E69E4.80300@novell.com>

Gergely Buday wrote:
> Larry Kilgallen wrote:
>   
>> Is there participation on this list from the (hopefully larger number of)
>> CMU instructors who are teaching people to use safer languages in the first
>> place ?
>>     
> May anybody not from CMU enter the discussion about safer languages? ;-)
>
> I'm in favor of SML, as it has a number of implementations (some of
> them comparable to C in speed)  and a formal definition ("well-typed
> programs do not go wrong") + a standard library.
>   
SML is a nice & clean type safe language, and I don't mean to criticize
it. However, if the goal is to be ale to use industry-popular languages
that are safe, it seems to me that we have entered a bright new phase of
history. Python, Ruby, Java, and C# are all broadly popular in industry,
and are all type safe. Java and C# are statically type safe. So why not
use them?

For me, the enemy in the room is C++. It gives you the safety of C with
the performance of SmallTalk. There is no excuse at all to be writing
anything in C++ yet vastly too many applications are written in C++
anyway. Instead of trying to coax developers to switch from C++ to
something "weird" like SML, lets encourage them to switch to Java or C#,
which are closer to their experience.

Sure, there are likely to be ways in which SML is better than C# or
Java. However, in security, the perfect is all to often the enemy of the
good-enough. The big community hears security people talk about the high
security approach that security geeks really want, consider the costs,
and go back to doing things the old way, and ignore the security people.
If security people instead pitch something that is feasible and makes
the situation better, instead of asking for the moon, we will make more
progress.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes



From gem at cigital.com  Wed Oct 25 11:23:19 2006
From: gem at cigital.com (Gary McGraw)
Date: Wed, 25 Oct 2006 11:23:19 -0400
Subject: [SC-L] Silver Bullet #7: John Stewart
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB665@va-mail.cigital.com>

Hi all,

We just released the 7th Silver Bullet Security Podcast today.  This one
features John Stewart, the CSO of Cisco.  As has become a custom, we
briefly discuss software security in this interview, this time with a
focus on what Cisco is doing.

http://www.cigital.com/silverbullet/show-007/

Happy listening!

gem

company www.cigital.com
book www.swsec.com


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ge at linuxbox.org  Sat Oct 28 01:41:59 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Sat, 28 Oct 2006 00:41:59 -0500 (CDT)
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <453E69E4.80300@novell.com>
Message-ID: <Pine.LNX.4.21.0610280039300.14421-100000@linuxbox.org>

On Tue, 24 Oct 2006, Crispin Cowan wrote:
> Sure, there are likely to be ways in which SML is better than C# or
> Java. However, in security, the perfect is all to often the enemy of the
> good-enough. The big community hears security people talk about the high
> security approach that security geeks really want, consider the costs,
> and go back to doing things the old way, and ignore the security people.
> If security people instead pitch something that is feasible and makes
> the situation better, instead of asking for the moon, we will make more
> progress.
> 
> Crispin

(not directed at you, Crispin)

So, "dump C", "Use SML", "What secure coding classes are you doing?" and
"we are already doing it!!" are the responses I got when I started this
thread.

Can someone mention again why re-writing the main often-used and probably
less than 3 mostly-used basic programming books is a bad idea?

All of us will still have a job in 5 years if we do this, even in 25. I
promise.

	Gadi.


From crispin at novell.com  Sat Oct 28 04:07:23 2006
From: crispin at novell.com (Crispin Cowan)
Date: Sat, 28 Oct 2006 01:07:23 -0700
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <Pine.LNX.4.21.0610280039300.14421-100000@linuxbox.org>
References: <Pine.LNX.4.21.0610280039300.14421-100000@linuxbox.org>
Message-ID: <45430FBB.8080108@novell.com>

Gadi Evron wrote:
> So, "dump C", "Use SML", "What secure coding classes are you doing?" and
> "we are already doing it!!" are the responses I got when I started this
> thread.
>   
What did you expect from whining about the generally poor quality of
software? :)

> Can someone mention again why re-writing the main often-used and probably
> less than 3 mostly-used basic programming books is a bad idea?
>   
Uh ... 'cause I question the assertion that there are 3 mostly-used
basic programming books. I suspect it is more like 78 mostly used books.
More importantly, if there are 3 mostly used books, then there are 78
more behind them vying for those 3 slots, and they all have the same
problems. If you write a new book, then you just join the pool of 78,
and you have the impact of a drop in the bucket.

Worse, we are talking about correctness here. Correctness is hard, and
correctness on a large scale is harder. I doubt that even a concerted
effort at a "correct" book on intro to programming would manage to
actually be correct any time before the 3rd edition, 10 years from now.

Seeking perfect correctness as an approach to security is a fool's
errand. Security is designing systems that can tolerate imperfect software.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From ge at linuxbox.org  Sun Oct 29 04:07:37 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Sun, 29 Oct 2006 03:07:37 -0600 (CST)
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <4543BDFF.3020204@novell.com>
Message-ID: <Pine.LNX.4.21.0610290305510.30647-100000@linuxbox.org>

On Sat, 28 Oct 2006, Crispin Cowan wrote:
> Gadi Evron wrote:
> > Nothing is ever easy, but we have to start somewhere. I don't see why this
> > is a bad idea. Yes, it takes time. Yes, it will have a much bigger impact.
> >   
> It is not a bad idea. But it clearly is not sufficient. Why are you

Now we're talking.

Not sufficient I am game with. Nothing ever is, it is one more thing to
do.

> assuming that it is not already being tried? The problem is that
it is

I am assuming most higher education institutions in the world do not have
it done.

> being tried with the usual degree of effectiveness, i.e. unevenly.
> Saying "lets try it" is redundant, because that is already going on,
> just not enough. To make it more, one would have to convince the people
> who are currently not doing it, or doing it badly, to do better, and
> they (by definition) are not listening.

Okay, than let's make some progress:
1. Where and who is currently involved with doing this?
2. What are they doing?
3. Can we use their experience to make it a larger success?
4. How do we begin doing something large-scale?

	Gadi.

> 
> Crispin
> 
> -- 
> Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
> Director of Software Engineering, Novell  http://novell.com
>      Hack: adroit engineering solution to an unanticipated problem
>      Hacker: one who is adroit at pounding round pegs into square holes
> 


From dcrocker at eschertech.com  Sat Oct 28 05:47:28 2006
From: dcrocker at eschertech.com (David Crocker)
Date: Sat, 28 Oct 2006 10:47:28 +0100
Subject: [SC-L] re-writing college books [was: Re: A banner year
	for	software bugs | Tech News on ZDNet]
In-Reply-To: <453E69E4.80300@novell.com>
Message-ID: <01de01c6fa76$1512db00$cb00000a@escheradmin>

Crispin Cowan wrote:

>>
For me, the enemy in the room is C++. It gives you the safety of C with the
performance of SmallTalk. There is no excuse at all to be writing anything in
C++ yet vastly too many applications are written in C++ anyway. Instead of
trying to coax developers to switch from C++ to something "weird" like SML, lets
encourage them to switch to Java or C#, which are closer to their experience.
<<

Unfortunately, there are at least two situations in which C++ is a more suitable
alternative to Java and C#:

- Where performance is critical. Run time of C# code (using the faster .NET 2.0
runtime) can be as much as double the run time of a C++ version of the same
algorithm. Try telling a large company that it must double the size of its
compute farms so you can switch to a "better" programming language!

- In hard real-time applications where garbage collection pauses cannot be
tolerated.

However, I suspect that most security-critical programs do not fall into either
of these categories, so C# or Java would indeed be a better choice than C++ for
those programs.

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com




From ge at linuxbox.org  Sat Oct 28 08:17:29 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Sat, 28 Oct 2006 07:17:29 -0500 (CDT)
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <45430FBB.8080108@novell.com>
Message-ID: <Pine.LNX.4.21.0610280716190.32453-100000@linuxbox.org>

On Sat, 28 Oct 2006, Crispin Cowan wrote:
> Gadi Evron wrote:
> > So, "dump C", "Use SML", "What secure coding classes are you doing?" and
> > "we are already doing it!!" are the responses I got when I started this
> > thread.
> >   
> What did you expect from whining about the generally poor quality of
> software? :)
> 
> > Can someone mention again why re-writing the main often-used and probably
> > less than 3 mostly-used basic programming books is a bad idea?
> >   
> Uh ... 'cause I question the assertion that there are 3 mostly-used
> basic programming books. I suspect it is more like 78 mostly used books.
> More importantly, if there are 3 mostly used books, then there are 78
> more behind them vying for those 3 slots, and they all have the same
> problems. If you write a new book, then you just join the pool of 78,
> and you have the impact of a drop in the bucket.
> 
> Worse, we are talking about correctness here. Correctness is hard, and
> correctness on a large scale is harder. I doubt that even a concerted
> effort at a "correct" book on intro to programming would manage to
> actually be correct any time before the 3rd edition, 10 years from now.
> 
> Seeking perfect correctness as an approach to security is a fool's
> errand. Security is designing systems that can tolerate imperfect software.

For argument sake, let's assume there are 100.

How about campaigning for a secure coding chapter to be added to these
semester, erm, world-wide?

Nothing is ever easy, but we have to start somewhere. I don't see why this
is a bad idea. Yes, it takes time. Yes, it will have a much bigger impact.

	Gadi.

> 
> Crispin
> 
> -- 
> Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
> Director of Software Engineering, Novell  http://novell.com
>      Hack: adroit engineering solution to an unanticipated problem
>      Hacker: one who is adroit at pounding round pegs into square holes
> 


From rcs at cert.org  Sat Oct 28 09:43:58 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Sat, 28 Oct 2006 09:43:58 -0400
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <45430FBB.8080108@novell.com>
References: <Pine.LNX.4.21.0610280039300.14421-100000@linuxbox.org>
	<45430FBB.8080108@novell.com>
Message-ID: <45435E9E.805@cert.org>

Crispin,

I think you may have over spoken below:

> Seeking perfect correctness as an approach to security is a fool's
> errand. Security is designing systems that can tolerate imperfect software.

I could go along with "achieving perfect correctness as an approach to
security is a fool's belief" but I believe the desire to achieve
correctness is a prerequisite for security.

More specifically, I have found that systematic schemes for providing
software security (such as memory protection, canaries, etc.) are
generally ineffective once a coding error (such as a buffer overflow)
allows an attacker to penetrate the peripheral defense of code
correctness.  Given the current state of software security, I don't
think any security "best" practice can abandoned and that
defense-in-depth is a practical necessity.

Also, back on the book topic, I recently heard of an older but
successful book that did nothing but take examples from other books and
show in detail how they were incorrect.  Perhaps such a "supplemental"
text could be developed for commonly used text books.

rCs


From crispin at novell.com  Sat Oct 28 16:30:55 2006
From: crispin at novell.com (Crispin Cowan)
Date: Sat, 28 Oct 2006 13:30:55 -0700
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <Pine.LNX.4.21.0610280716190.32453-100000@linuxbox.org>
References: <Pine.LNX.4.21.0610280716190.32453-100000@linuxbox.org>
Message-ID: <4543BDFF.3020204@novell.com>

Gadi Evron wrote:
> For argument sake, let's assume there are 100.
>
> How about campaigning for a secure coding chapter to be added to these
> semester, erm, world-wide?
>
> Nothing is ever easy, but we have to start somewhere. I don't see why this
> is a bad idea. Yes, it takes time. Yes, it will have a much bigger impact.
>   
It is not a bad idea. But it clearly is not sufficient. Why are you
assuming that it is not already being tried? The problem is that it is
being tried with the usual degree of effectiveness, i.e. unevenly.
Saying "lets try it" is redundant, because that is already going on,
just not enough. To make it more, one would have to convince the people
who are currently not doing it, or doing it badly, to do better, and
they (by definition) are not listening.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From crispin at novell.com  Sat Oct 28 16:37:01 2006
From: crispin at novell.com (Crispin Cowan)
Date: Sat, 28 Oct 2006 13:37:01 -0700
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <45435E9E.805@cert.org>
References: <Pine.LNX.4.21.0610280039300.14421-100000@linuxbox.org>
	<45430FBB.8080108@novell.com> <45435E9E.805@cert.org>
Message-ID: <4543BF6D.7000800@novell.com>

Robert C. Seacord wrote:
>> Seeking perfect correctness as an approach to security is a fool's
>> errand. Security is designing systems that can tolerate imperfect software.
>>     
> I could go along with "achieving perfect correctness as an approach to
> security is a fool's belief" but I believe the desire to achieve
> correctness is a prerequisite for security.
>
> More specifically, I have found that systematic schemes for providing
> software security (such as memory protection, canaries, etc.) are
> generally ineffective once a coding error (such as a buffer overflow)
> allows an attacker to penetrate the peripheral defense of code
> correctness.  Given the current state of software security, I don't
> think any security "best" practice can abandoned and that
> defense-in-depth is a practical necessity.
>   
I don't think we disagree. When I said that seeking correctness is a
fool's errand, I meant (more precisely) that *depending on achieving*
correctness is a fool's errand. You must always assume the presence of
imperfect software, and then design in defense in depth to tolerate
that. Using other software engineering techniques (secure coding, the
occasional topic of this mailing list :) certainly helps, but cannot be
the whole approach to security.

> Also, back on the book topic, I recently heard of an older but
> successful book that did nothing but take examples from other books and
> show in detail how they were incorrect.  Perhaps such a "supplemental"
> text could be developed for commonly used text books.
>   
I like it! Bugtraq for books :) My engineers are quite fond of The
*Daily WTF* <http://thedailywtf.com/> a web site that lampoons bad code.

Crispin

From dcrocker at eschertech.com  Sun Oct 29 15:57:43 2006
From: dcrocker at eschertech.com (David Crocker)
Date: Sun, 29 Oct 2006 20:57:43 -0000
Subject: [SC-L] Proving the security properties of transaction protocols -
	10 years on
Message-ID: <007b01c6fb9c$e1bda550$cb00000a@escheradmin>

Members of this list might be interested in an article in this month's IEEE
Computer Journal about the use of automatic and semi-automatic theorem proving
to prove the security of a transaction protocol. The article - which is called
First Steps in the Verified Software Grand Challenge - concerns the transaction
protocol that was used by the Mondex electronic purse, which was developed and
formally verified (by hand) around ten years ago. Several teams have recently
attempted to apply modern tools to the problem. In the process, several of the
teams working on the project found that the original hand-developed proof was
incomplete, but could be patched.

More details can be found at
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/co/&toc=co
mp/mags/co/2006/10/rxtoc.xml&DOI=10.1109/MC.2006.340#abstract . Non-subscribers
can download the article for $19.

My own company provided one of the teams working on this problem, and we found
it is quite a challenge to prove the protocol correct by fully-automatic means.
Proofs that software is free from buffer overflows for all possible inputs are
almost trivial by comparison.

Regards

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com




From rcs at cert.org  Sun Oct 29 18:37:06 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Sun, 29 Oct 2006 18:37:06 -0500
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <Pine.LNX.4.21.0610290305510.30647-100000@linuxbox.org>
References: <Pine.LNX.4.21.0610290305510.30647-100000@linuxbox.org>
Message-ID: <45453B22.50401@cert.org>

Gadi,

I feel like I've been here before, but I'll give it another shot anyway.

> Okay, than let's make some progress:
> 1. Where and who is currently involved with doing this?
> 2. What are they doing?
> 3. Can we use their experience to make it a larger success?
> 4. How do we begin doing something large-scale?

The Secure Coding Initiative at CERT has a web site at
www.securecoding.cert.org.  The purpose of this site is to collect
secure coding recommendations and rules for various programming
languages.  Our initial focus has been C and C++, but we are willing and
interested in expanding this effort to other programming languages
provided that we can find someone to manage the efforts.

The C and C++ material on the site will be used as supplemental material
to the Addison-Wesley book "Secure Coding in C and C++" in a "Secure
Programming" course I am teaching this Spring at CMU (so it is being
used to teach, as well as being a commercial and government resource).
I am also working with other instructors at other educational
institutions to develop secure coding curriculum.

We have had significant community effort in the development of these
secure coding standard practices so far, but we can use all the help we
can get.  If you would like to get involved, go the sight, sign up, and
start reviewing the material.  If you are qualified and would like to
edit the material directly, send me email and I will grant you edit
permissions.

I think having a body of knowledge that identifies insecure coding
practices and provides secure alternatives is a good first start, and
not as easy as it sounds.

---------

I also had another thought about improving the quality of code examples
in texts.  I know my publisher (Addison-Wesley), and I'm sure others,
are very concerned about quality.  I could ask my editor if they would
be willing to make sure that someone with a security background reviewed
any new programming texts.  If we can come up with a list of subject
matter experts willing to review new texts, I'm guessing they would be
very happy to have our feedback.

rCs



From ge at linuxbox.org  Mon Oct 30 02:23:34 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Mon, 30 Oct 2006 01:23:34 -0600 (CST)
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <45453B22.50401@cert.org>
Message-ID: <Pine.LNX.4.21.0610300121130.14708-100000@linuxbox.org>

On Sun, 29 Oct 2006, Robert C. Seacord wrote:
> Gadi,
> 
> I feel like I've been here before, but I'll give it another shot anyway.
> 
> > Okay, than let's make some progress:
> > 1. Where and who is currently involved with doing this?
> > 2. What are they doing?
> > 3. Can we use their experience to make it a larger success?
> > 4. How do we begin doing something large-scale?
> 
> The Secure Coding Initiative at CERT has a web site at
> www.securecoding.cert.org.  The purpose of this site is to collect
> secure coding recommendations and rules for various programming
> languages.  Our initial focus has been C and C++, but we are willing and
> interested in expanding this effort to other programming languages
> provided that we can find someone to manage the efforts.
> 
> The C and C++ material on the site will be used as supplemental material
> to the Addison-Wesley book "Secure Coding in C and C++" in a "Secure
> Programming" course I am teaching this Spring at CMU (so it is being
> used to teach, as well as being a commercial and government resource).
> I am also working with other instructors at other educational
> institutions to develop secure coding curriculum.

We misunderstand each other. I am not speaking of a secure coding book, I
am speaking of "Introduction to Computer Science" and "The C programming
Language".

If we can use what you have already worked on to supplament these courses,
then all for the better!

> 
> We have had significant community effort in the development of these
> secure coding standard practices so far, but we can use all the help we
> can get.  If you would like to get involved, go the sight, sign up, and
> start reviewing the material.  If you are qualified and would like to
> edit the material directly, send me email and I will grant you edit
> permissions.

I doubt I am that much of a good coder anymore.

> 
> I think having a body of knowledge that identifies insecure coding
> practices and provides secure alternatives is a good first start, and
> not as easy as it sounds.

Agreed!
Nice work on all that!

> 
> ---------
> 
> I also had another thought about improving the quality of code examples
> in texts.  I know my publisher (Addison-Wesley), and I'm sure others,
> are very concerned about quality.  I could ask my editor if they would
> be willing to make sure that someone with a security background reviewed
> any new programming texts.  If we can come up with a list of subject
> matter experts willing to review new texts, I'm guessing they would be
> very happy to have our feedback.

That sounds like a very good idea! I am sure many would agree to get some
extra cash for reviewing, thing is, that doesn't pay very well.

> 
> rCs
> 
> 


From gunnar at arctecgroup.net  Mon Oct 30 15:46:03 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Mon, 30 Oct 2006 14:46:03 -0600
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <45430FBB.8080108@novell.com>
Message-ID: <C16BC0AB.356A%gunnar@arctecgroup.net>

> Seeking perfect correctness as an approach to security is a fool's
> errand. Security is designing systems that can tolerate imperfect software.
> 

Exactly. On "Curb Your Enthusiasm" this happened recently. Larry David was
frantically looking for a DVD case, but could not find it.

LD: "I don't know what happened. I have a system. I put the DVD in the
player, and I put the case on top of the player. But now it is gone."

Friend: "That's not a system. A system is - you buy a bunch of empty DVD
cases and put them next to the player."

-gp



From gem at cigital.com  Tue Oct 31 10:18:06 2006
From: gem at cigital.com (Gary McGraw)
Date: Tue, 31 Oct 2006 10:18:06 -0500
Subject: [SC-L] Build a better death star
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB740@va-mail.cigital.com>

Hi all,

This article describes one way of hooking your existing badness-ometer
(that is, your black box security testing tool) into a better system for
actually fixing software.

http://www.adtmag.com/article.aspx?id=19498

Or, as I put it down there somewhere...a way to build a better death
star.  Yeesh.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From bencorneau at adelphia.net  Tue Oct 31 21:08:11 2006
From: bencorneau at adelphia.net (Ben Corneau)
Date: Tue, 31 Oct 2006 21:08:11 -0500
Subject: [SC-L] Why Shouldn't I use C++?
Message-ID: <20061101020855.CEA28824.mta13.adelphia.net@computer>

>From time to time on this list, the recommendation is made to never user C++
when given a choice (most recently by Crispin Cowan in the "re-writing
college books" thread). This is a recommendation I do not understand. Now,
I'm not an expert C++ programmer or Java or C# programmer and as you may
have guessed based on the question, I'm not an expert on secure coding
either. I'm also not disagreeing with the recommendation; I would just like
a better understanding.

I understand that C++ allows unsafe operations, like buffer overflows.
However, if you are a halfway decent C++ programmer buffer overflows can
easily be avoided, true? If you use the STL containers and follow basic good
programming practices of C++ instead of using C-Arrays and pointer
arithmetic then the unsafe C features are no longer an issue?

C and C++ are very different. Using C++ like C is arguable unsafe, but when
it's used as it was intended can't C++ too be considered for secure
programming?

Ben Corneau



From rcs at cert.org  Wed Nov  1 05:15:30 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Wed, 01 Nov 2006 05:15:30 -0500
Subject: [SC-L] Why Shouldn't I use C++?
In-Reply-To: <20061101020855.CEA28824.mta13.adelphia.net@computer>
References: <20061101020855.CEA28824.mta13.adelphia.net@computer>
Message-ID: <454873C2.3030304@cert.org>

Ben,

I would not go so far as to say never use C++.  It is probably the most
powerful and expressive commercially successful programming language
available today and there are often good reasons to use the language.

Secure programming in C++ is possible, but C++ itself is exceptionally
complex, has many idiosyncrasies, and as a result it is very easy to
make mistakes in the language.  Because of these factors, many C++
experts recommend an idiomatic approach to C++ where basically you reuse
 snippets of code that do something akin to what you are after.  The
message here, of course, is that you are likely to mess up if you write
some "new code" which has not been thoroughly considered by a panel of
experts for many years. 8^)

> If you use the STL containers and follow basic good
> programming practices of C++ instead of using C-Arrays and pointer
> arithmetic then the unsafe C features are no longer an issue?

See
https://www.securecoding.cert.org/confluence/display/cplusplus/13.+STL+%28STL%29
for common security flaws involving the STL

See
https://www.securecoding.cert.org/confluence/display/cplusplus/10.+Basic+string+class+%28BSC%29

for common security flaws involving basic_string (which also functions
as an STL sequence container)

Integer related security problems are basically the same for both C and C++.

> C and C++ are very different. Using C++ like C is arguable unsafe, but when
> it's used as it was intended can't C++ too be considered for secure
> programming?

I'll agree with you that using C++ in an idiomatic fashion is safer than
  using it like C.  One of the things you will note through the
www.securecoding.cert.org web site is that many of the problems for C
programming language also exist for C++, but the solutions are different
because C++ offers better/different options.  But you need to know to
use these, you have to be aware of the new problems that C++ brings, and
you often need to use C features to interact with existing libraries.

Hope this (partial) explanation helps somewhat.

rCs



From ljknews at mac.com  Wed Nov  1 06:35:37 2006
From: ljknews at mac.com (ljknews)
Date: Wed, 1 Nov 2006 06:35:37 -0500
Subject: [SC-L] Why Shouldn't I use C++?
In-Reply-To: <20061101020855.CEA28824.mta13.adelphia.net@computer>
References: <20061101020855.CEA28824.mta13.adelphia.net@computer>
Message-ID: <p05200f08c16e36a08750@[192.168.1.254]>

At 9:08 PM -0500 10/31/06, Ben Corneau wrote:

> C and C++ are very different. Using C++ like C is arguable unsafe, but when
> it's used as it was intended can't C++ too be considered for secure
> programming?

What assurance does upper management have that C++ was used "as it was
intended" rather than "like C" ?
-- 
Larry Kilgallen

From peter.amey at praxis-his.com  Wed Nov  1 07:02:27 2006
From: peter.amey at praxis-his.com (Peter Amey)
Date: Wed, 1 Nov 2006 12:02:27 -0000
Subject: [SC-L] Why Shouldn't I use C++?
Message-ID: <4BF0455B353E524FBEA15C3A490F7DFE6B9995@EVS01.praxis.local>

 

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Robert C. Seacord
> Sent: 01 November 2006 10:16
> To: Ben Corneau
> Cc: SC-L at securecoding.org
> Subject: Re: [SC-L] Why Shouldn't I use C++?
> 
> Ben,
> 
> I would not go so far as to say never use C++.  It is 
> probably the most powerful and expressive commercially 
> successful programming language available today ...

... other than Ada, which has all the OO capability of C++, language
level support for multi-threaded programs and suffers from none of the
problems that exercise this discussion list so regularly. 

regards


Peter




From gem at cigital.com  Wed Nov  1 07:14:38 2006
From: gem at cigital.com (Gary McGraw)
Date: Wed, 1 Nov 2006 07:14:38 -0500
Subject: [SC-L] Why Shouldn't I use C++?
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E7B46@va-mail.cigital.com>

The biggest problem with C++ is that, like C, it is not type safe.   The memory model is a disasterous sea of bits.  Plus it is an arcane, hard to understand language prone to misunderstandings.

If you can at all avoid C++, do so.  

Use Java, C#, or some other type safe alternative.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com


 -----Original Message-----
From: 	Ben Corneau [mailto:bencorneau at adelphia.net]
Sent:	Tue Oct 31 22:08:08 2006
To:	SC-L at securecoding.org
Subject:	[SC-L] Why Shouldn't I use C++?

>From time to time on this list, the recommendation is made to never user C++
when given a choice (most recently by Crispin Cowan in the "re-writing
college books" thread). This is a recommendation I do not understand. Now,
I'm not an expert C++ programmer or Java or C# programmer and as you may
have guessed based on the question, I'm not an expert on secure coding
either. I'm also not disagreeing with the recommendation; I would just like
a better understanding.

I understand that C++ allows unsafe operations, like buffer overflows.
However, if you are a halfway decent C++ programmer buffer overflows can
easily be avoided, true? If you use the STL containers and follow basic good
programming practices of C++ instead of using C-Arrays and pointer
arithmetic then the unsafe C features are no longer an issue?

C and C++ are very different. Using C++ like C is arguable unsafe, but when
it's used as it was intended can't C++ too be considered for secure
programming?

Ben Corneau


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From leichter_jerrold at emc.com  Wed Nov  1 10:32:29 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Wed, 1 Nov 2006 10:32:29 -0500 (EST)
Subject: [SC-L] Why Shouldn't I use C++?
In-Reply-To: <20061101020855.CEA28824.mta13.adelphia.net@computer>
References: <20061101020855.CEA28824.mta13.adelphia.net@computer>
Message-ID: <Pine.SOL.4.61.0611011015130.3381@mental>

| From time to time on this list, the recommendation is made to never
| user C++ when given a choice (most recently by Crispin Cowan in the
| "re-writing college books" thread). This is a recommendation I do not
| understand. Now, I'm not an expert C++ programmer or Java or C#
| programmer and as you may have guessed based on the question, I'm not
| an expert on secure coding either. I'm also not disagreeing with the
| recommendation; I would just like a better understanding.
| 
| I understand that C++ allows unsafe operations, like buffer overflows.
| However, if you are a halfway decent C++ programmer buffer overflows
| can easily be avoided, true? If you use the STL containers and follow
| basic good programming practices of C++ instead of using C-Arrays and
| pointer arithmetic then the unsafe C features are no longer an issue?
| 
| C and C++ are very different. Using C++ like C is arguable unsafe, but
| when it's used as it was intended can't C++ too be considered for
| secure programming?
You could, in principle, produce a set of classes that defined a
"safe" C++ environment.  Basically, you'd get rid of all uses of
actual pointers, and all actual arrays.  Objects would be manipulated
only through "smart pointers" which could only be modified in limited
ways.  In particular, there would be no way to do arithmetic on such
pointers (or maybe the smart pointers would be "fat", containing
bounds information, so that arithmetic could be allowed but checked), 
arbitrarily cast them, etc.  Arrays would be replaced by objects with
[] operators that checked bounds.

The STL would be an unlikely member of such a world:  It models
iterators on pointers, and they inherit many of the latter's lack
of safety.  (There are "checked" versions of the STL which might
help provide the beginnings of a "safe C++" environment.)

You'd have to wrap existing API's to be able to access them safely.
All the standard OS API's (Unix and Windows), everything in the C
library, most other libraries you are going to find out there - these
are heavily pointer-based.  Strings are often passed as char*'s.
Note that you can't even write down a non-pointer-based C++ string
constant!

But wait, there's more!  For example, we've seen attacks based on
integer overflow.  C++ doesn't let you detect that.  If you really want
your integer arithmetic to be safe, you can't use any of the native
integer types.  You need to define wrapper types that do something
safe in case of an overflow.  (To be fair, even many "safe" languages,
Java among them, don't detect integer overflow either.)

By the time you were done, you would in effect have defined a whole new
language and set of libraries to go with it.  Programming in that
language would require significant discipline:  You would not be allowed
to use most common C++ data types, library functions, idioms, and so on.
You'd probably want to use some kind of a tool to check for conformance,
since I doubt even well-intentioned human beings would be able to do so.

It happens that C++ has extension facilities that are powerful enough
to let you do most, perhaps all, of this, subject to programmer
discipline.  But is there really an advantage, when all is said and
done?
							-- Jerry
					[Who uses C++ extensively, and
					 does his best to make his
					 abstractions "safe"]

| Ben Corneau

From crispin at novell.com  Thu Nov  2 06:17:31 2006
From: crispin at novell.com (Crispin Cowan)
Date: Thu, 02 Nov 2006 03:17:31 -0800
Subject: [SC-L] Why Shouldn't I use C++?
In-Reply-To: <20061101020855.CEA28824.mta13.adelphia.net@computer>
References: <20061101020855.CEA28824.mta13.adelphia.net@computer>
Message-ID: <4549D3CB.80607@novell.com>

Ben Corneau wrote:
> From time to time on this list, the recommendation is made to never user C++
> when given a choice (most recently by Crispin Cowan in the "re-writing
> college books" thread). This is a recommendation I do not understand. Now,
> I'm not an expert C++ programmer or Java or C# programmer and as you may
> have guessed based on the question, I'm not an expert on secure coding
> either. I'm also not disagreeing with the recommendation; I would just like
> a better understanding.
>
> I understand that C++ allows unsafe operations, like buffer overflows.
> However, if you are a halfway decent C++ programmer buffer overflows can
> easily be avoided, true? If you use the STL containers and follow basic good
> programming practices of C++ instead of using C-Arrays and pointer
> arithmetic then the unsafe C features are no longer an issue?
>
> C and C++ are very different. Using C++ like C is arguable unsafe, but when
> it's used as it was intended can't C++ too be considered for secure
> programming?
>   
No, it cannot.

C++ is no more safe than C. C++ still supports many undefined
operations, which is what makes a language unsafe. No way can C++ be
considered a secure programming language.

If you need a lean, small language for doing embedded or kernel stuff,
then use C; you cannot afford the bloat of C++, so it is not appropriate.

If you need a powerful, abstract language for building complex
applications, then use C# or Java (or ML, or Haskell). They provide all
of the abstraction and programming convenience of C++, and they also
provide type safety. This means that there are no undefined operations,
which is what makes them secure programming languages.

There is no excuse for *choosing* C++, ever. Always avoid it. The only
excuse for *using* C++ is that some doofus before you chose it and you
have to live with the legacy code :)

So why does C++ exist? Because technology has moved. 25 years ago, when
C++ was invented, there was not a great supply of well developed type
safe object oriented programming languages. So C++ seemed like an
incremental improvement over C when it was introduced in the early
1980s. It did provide an improvement over C for developing large
applications, where development costs due to complexity were the big
problem, and bloat could be afforded.

But that lunch has now been eaten by the type safe OOP languages of Java
and C#. They are strictly better than C++ at complex applications, so
there really is no excuse for using C++ to write new application code.

And there never was an excuse for using C++ to write kernel or embedded
code. You cannot afford the bloat of C++ there, and if your kernel is so
complex that you need OOP to be able to program it, then your kernel
design is broken anyway.

I suppose there should be an "IMHO" in here somewhere in a rant like
this. Feel free to insert it anywhere you like :)

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From crispin at novell.com  Thu Nov  2 23:46:25 2006
From: crispin at novell.com (Crispin Cowan)
Date: Thu, 02 Nov 2006 20:46:25 -0800
Subject: [SC-L] re-writing college books [was: Re: A banner
 year	for	software bugs | Tech News on ZDNet]
In-Reply-To: <01de01c6fa76$1512db00$cb00000a@escheradmin>
References: <01de01c6fa76$1512db00$cb00000a@escheradmin>
Message-ID: <454AC9A1.4090804@novell.com>

David Crocker wrote:
> Unfortunately, there are at least two situations in which C++ is a more suitable
> alternative to Java and C#:
>
> - Where performance is critical. Run time of C# code (using the faster .NET 2.0
> runtime) can be as much as double the run time of a C++ version of the same
> algorithm. Try telling a large company that it must double the size of its
> compute farms so you can switch to a "better" programming language!
>
> - In hard real-time applications where garbage collection pauses cannot be
> tolerated.
>   
Except that in both of those cases, C++ is not appropriate either. That
is a case for C.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From ken at krvw.com  Fri Nov  3 11:09:00 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 3 Nov 2006 11:09:00 -0500
Subject: [SC-L] Apple Places Encrypted Binaries in Mac OS X
Message-ID: <B75A1D11-071C-43CD-8B4B-74176DB1AD67@krvw.com>

Here's a somewhat interesting link to an eweek article that discusses  
Apple's use of encryption to protect some of its OS X binaries:

http://www.eweek.com/article2/0,1895,2050875,00.asp

Of course, encrypting binaries isn't anything new, but it's  
interesting (IMHO) to see how it's being used in a real OS.  The  
article cites speculation as to whether Apple uses encryption for  
anti-piracy or anti-reverse-engineering.

Another interesting side topic (though not mentioned in this article)  
is code obfuscation, which is being increasingly used for both  
purposes as well.  Course, some coders have been inadvertently doing  
code obfuscation for years.  ;-\

Cheers,

Ken
-----
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20061103/554ba3bc/attachment.bin 

From gem at cigital.com  Fri Nov  3 12:02:45 2006
From: gem at cigital.com (Gary McGraw)
Date: Fri, 3 Nov 2006 12:02:45 -0500
Subject: [SC-L] On exploits, hubris, and software security
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB7CF@va-mail.cigital.com>

Hi all,

We all know that there is nothing more powerful for causing software
security change than a flashy exploit demonstration.  Once again, this
has come to the fore in the actions of an IU student who took a well
known boarding pass vulnerability and wrote a script to make it real.
Just after that, a Congressman called for his arrest and the FBI/TSA
showed up at his house with a search warrant and took away his machines.

My latest darkreading article is about the situation:
http://www.darkreading.com/document.asp?doc_id=109717&WT.svl=tease3_2

The main thing I wonder is, what do you think?  When you have a hot
demonstration of an exploit, how do you responsibly release it?  What
role do such demonstrations play in moving software security forward?

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 


----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From leichter_jerrold at emc.com  Fri Nov  3 12:44:17 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Fri, 3 Nov 2006 12:44:17 -0500 (EST)
Subject: [SC-L] Apple Places Encrypted Binaries in Mac OS X
In-Reply-To: <B75A1D11-071C-43CD-8B4B-74176DB1AD67@krvw.com>
References: <B75A1D11-071C-43CD-8B4B-74176DB1AD67@krvw.com>
Message-ID: <Pine.SOL.4.61.0611031234340.6535@mental>

| Here's a somewhat interesting link to an eweek article that discusses
| Apple's use of encryption to protect some of its OS X binaries:
| http://www.eweek.com/article2/0,1895,2050875,00.asp
| 
| Of course, encrypting binaries isn't anything new, but it's
| interesting (IMHO) to see how it's being used in a real OS.  The
| article cites speculation as to whether Apple uses encryption for
| anti-piracy or anti-reverse-engineering.
Actually, it's pretty clear why they are doing it, if you look at
the pieces they encrypt.  The Finder and Dock have no particularly
valuable intellectual property in them, but they are fundamental to
the GUI.  Encrypting them means that a version of OS X that's been
modified to boot on non-Apple hardware won't have a GUI, thus
limiting its attractiveness to non-hackers.  To really get the
result to be widely used, someone would have to write a replacement
for these components that looked "enough like the original".  And
of course, since they built a general-purpose mechanism, nothing
prevents Apple encrypting other components later.

Rosetta (the binary translator for PowerPC programs) isn't an essential
program.  Apple may simply consider it valuable, but I think it's more
likely that they may be preparing the way for the next step:  Encrypting
applications they deliver as "native".  Since the encryption isn't
supported on PowerPC, running those applications under Rosetta would
provide a quick way to get around encryption for the native versions of
applications.

It is worth pointing out that while Darwin, the underlying OS, is
open source, no part of the GUI code, or Rosetta, or any of
Apple's applications, have ever been open source.

							-- Jerry

From secureCoding2dave at davearonson.com  Fri Nov  3 12:30:18 2006
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Fri, 03 Nov 2006 17:30:18 +0000
Subject: [SC-L] On exploits, hubris, and software security
Message-ID: <W7495218115307541162575018@webmail2>

Gary McGraw [mailto:gem at cigital.com] writes:

> The main thing I wonder is, what do you think? When you have a hot
> demonstration of an exploit, how do you responsibly release it?

This isn't so much about that, in the usual sense. This was, as you say, a well-known vulnerability, one screamingly obvious to anybody who bothered to think about how to get around the No-Fly List. Bruce Schneier wrote about it on his blog long ago, as did many others.

> What role do such demonstrations play in moving software security forward?

It could help dramatically. Not so much because of the demo itself, which will of course be ignored by the Powers that Be, but the publicity around it. That might possibly eventually make enough of a dent in the public consciousness, to wake them up to the fact that what the PTBs have been doing is almost all just security THEATER.

However, it depends how much the media gives background. Unfortunately, even a brief blurb like "this flaw in the No-Fly List concept has been well known for several years" is unlikely to be aired or printed, since it takes valuable time/space away from the latest scandals of skanky "socialites" and other such much more important news. Without this little bit of trivia, the sheeple will just ass-u-me that the demo-giver was, as the PTBs will insinuate, a malefactor in league with $ENEMY[$YEAR], and deserves to be shipped off to the Git-lag.

-Dave

-- 
Dave Aronson
"Specialization is for insects." -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/




From BlueBoar at thievco.com  Fri Nov  3 12:50:10 2006
From: BlueBoar at thievco.com (Blue Boar)
Date: Fri, 03 Nov 2006 09:50:10 -0800
Subject: [SC-L] On exploits, hubris, and software security
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB7CF@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB7CF@va-mail.cigital.com>
Message-ID: <454B8152.9080106@thievco.com>

Gary McGraw wrote:
> The main thing I wonder is, what do you think?  When you have a hot
> demonstration of an exploit, how do you responsibly release it?  What
> role do such demonstrations play in moving software security forward?

To pick one extreme, I believe there are times when intentionally 
blindsiding a vendor is appropriate:
http://ryanlrussell.blogspot.com/2006/11/you-want-mac-wireless-bugs.html

					BB

From gem at cigital.com  Fri Nov  3 13:20:25 2006
From: gem at cigital.com (Gary McGraw)
Date: Fri, 3 Nov 2006 13:20:25 -0500
Subject: [SC-L] On exploits, hubris, and software security
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB7E6@va-mail.cigital.com>

Ed Felten and I found out early on (back in 1996) that you can use the
press as a lever to get companies to do the right thing.  We learned
this when releasing the very first Java Security hole.  We found out
that Sun paid much more attention once USA Today picked up the story
from comp.risks.

Later, we could disclose the problems responsibly, keeping a short leash
on Microsoft, Netscape, and Sun without ever resorting to FULL
disclosure.  Our goal was to get the problems fixed with no nonsense.
The companies also allowed the press to be responsibly involved.

We discussed all of the problems we found in our books "Java Security"
and "Securing Java", but without ever releasing code for the exploits. 

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com  

-----Original Message-----
From: Blue Boar [mailto:BlueBoar at thievco.com] 
Sent: Friday, November 03, 2006 12:50 PM
To: Gary McGraw
Cc: SC-L at securecoding.org
Subject: Re: [SC-L] On exploits, hubris, and software security

Gary McGraw wrote:
> The main thing I wonder is, what do you think?  When you have a hot
> demonstration of an exploit, how do you responsibly release it?  What
> role do such demonstrations play in moving software security forward?

To pick one extreme, I believe there are times when intentionally 
blindsiding a vendor is appropriate:
http://ryanlrussell.blogspot.com/2006/11/you-want-mac-wireless-bugs.html

					BB



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From BlueBoar at thievco.com  Fri Nov  3 14:38:13 2006
From: BlueBoar at thievco.com (Blue Boar)
Date: Fri, 03 Nov 2006 11:38:13 -0800
Subject: [SC-L] On exploits, hubris, and software security
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB7E6@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB7E6@va-mail.cigital.com>
Message-ID: <454B9AA5.7040508@thievco.com>

Gary McGraw wrote:
> Later, we could disclose the problems responsibly, keeping a short leash
> on Microsoft, Netscape, and Sun without ever resorting to FULL
> disclosure.  Our goal was to get the problems fixed with no nonsense.
> The companies also allowed the press to be responsibly involved.

Are you familiar with the backstory on this one?  While I acknowledge 
there is controversy on who is telling the truth, here's the 60-second 
summary, according to how I believe it happened.  (And how I believe it 
happened is important, because other researchers also believe this, and 
are acting accordingly.):

-Researchers show video demo at Black Hat of an attack against a 
wireless driver for a third-party NIC on a MacBook.  They poke fun at 
Mac users.  They claim it works against the driver for the built-in 
wireless, too.  (They also claim it works against Windows drivers, *nix 
drivers, etc.. but no one cares for purposes of the controversy.)

-Reporter reports it, uses sensational headline, backs up their story 
about the built-in card driver being vulnerable, too.  Says researchers 
claim Apple "leaned" on them to remove the video demo of the built-in 
card exploit.

-Researchers claim they told Apple.  Apple denies it to reporters. 
Apple issues press releases denying it.  Apple PR person goes on record 
as claiming Apple was not given one shred of evidence.  Employer of one 
of the researchers appears to be keeping both researchers from saying 
anything to defend themselves.

-Apple releases patch for the vulnerability (so says one of the 
researchers) and Apple claims credit for finding it.

So, if you believe the researchers' side of the story, the press WAS 
involved, Apple denied it, threw around legal threats to gag the 
researchers, and then stole the credit.

Ergo, the next set of researchers (who tend to believe the first set of 
researchers) say screw Apple, and release details in such a way that 
there can be no denial of what they found.

Researchers will tend to take the word of other researchers over the 
vendors, and some researchers already have a tendency to just publish if 
they get flack from the vendor anyway.

The actual hard truth of the situation isn't critical, the researchers 
will behave according to their perception of what happened.  While I am 
extremely interested in the hard truth for this situation, we don't have 
it yet, we might never.  I don't particularly want to debate the actual 
truth here, and I'm pretty sure Gary doesn't want us to, either.  If you 
want to read a very good counterpoint from someone who believes more of 
Apple's side of the story, Dave Schroeder posed a detailed response on 
my blog entry that I referenced earlier.  If you want to debate me on it 
in particular, please feel free to do so there.

Again, the important bit is how Apple appears to behave, to people like 
the researchers.  I have the same bias, and if I were any good at 
finding kernel vulnerabilities, I'd be treating Apple the same way about 
now.

					BB

(Apologies for the length.  I've already been debating this for a few 
days, and Gary DID invoke the Full Disclosure debate.)

From leichter_jerrold at emc.com  Fri Nov  3 19:28:15 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Fri, 3 Nov 2006 19:28:15 -0500 (EST)
Subject: [SC-L] Apple Places Encrypted Binaries in Mac OS X
In-Reply-To: <Pine.SOL.4.61.0611031234340.6535@mental>
References: <B75A1D11-071C-43CD-8B4B-74176DB1AD67@krvw.com>
	<Pine.SOL.4.61.0611031234340.6535@mental>
Message-ID: <Pine.SOL.4.61.0611031920170.6535@mental>

BTW, an interesting fact has been pointed out by Amit Singh, author
of a book describing Mac OS X internals:  The first generation of
x86-based Mac's - or at least some of them - contained a TPM chip
(specifically, the Infineon SKB 9635 TT 1.2.  However, Apple
never used the chip - in fact, they didn't even provide a driver
for it.  It certainly was not used in generating the encrypted
binaries.  Proof?  The most recent revision of the Macbook Pro
does *not* contain a TPM chip.

So in fact Apple is not using the TPM to "certify" a machine as
being real Apple hardware.  Presumably one can hack out the
decryption key - it's in the software somewhere....

							-- Jerry


From dcrocker at eschertech.com  Sat Nov  4 06:57:55 2006
From: dcrocker at eschertech.com (David Crocker)
Date: Sat, 4 Nov 2006 11:57:55 -0000
Subject: [SC-L] re-writing college books [was: Re: A banner
	year	for	software bugs | Tech News on ZDNet]
In-Reply-To: <454AC9A1.4090804@novell.com>
Message-ID: <009301c70008$782be730$cb00000a@escheradmin>

Crispin,

It is most certainly true that C++ can be appropriate in those cases. C++
programs can perform just as well as C programs, while also being much better
structured. Of course, it will be necessary to avoid performing frequent
allocation and deallocation of heap memory in the C++ program - but the same is
true of C programs. Poorly-performing programs can be written in either
language.

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com



-----Original Message-----
From: Crispin Cowan [mailto:crispin at novell.com] 
Sent: 03 November 2006 04:46
To: David Crocker
Cc: 'Secure Coding'
Subject: Re: [SC-L] re-writing college books [was: Re: A banner year for
software bugs | Tech News on ZDNet]


David Crocker wrote:
> Unfortunately, there are at least two situations in which C++ is a 
> more suitable alternative to Java and C#:
>
> - Where performance is critical. Run time of C# code (using the faster 
> .NET 2.0
> runtime) can be as much as double the run time of a C++ version of the same
> algorithm. Try telling a large company that it must double the size of its
> compute farms so you can switch to a "better" programming language!
>
> - In hard real-time applications where garbage collection pauses 
> cannot be tolerated.
>   
Except that in both of those cases, C++ is not appropriate either. That is a
case for C.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From mark at markgraff.com  Sat Nov  4 17:48:19 2006
From: mark at markgraff.com (Mark Graff)
Date: Sat, 4 Nov 2006 14:48:19 -0800
Subject: [SC-L] SC-L Digest, Vol 2, Issue 183
References: <mailman.3.1162659601.86322.sc-l@securecoding.org>
Message-ID: <004d01c70063$53697150$0401a8c0@TallTrees>

Gary McGraw said:

> Ed Felten and I found out early on (back in 1996) that you can use the
> press as a lever to get companies to do the right thing.  We learned
> this when releasing the very first Java Security hole.  We found out
> that Sun paid much more attention once USA Today picked up the story
> from comp.risks.
>
> Later, we could disclose the problems responsibly...

I told my part of this tale in "Secure Coding" (O'Reiily, 2003--with KRvw, 
of course). I was Sun's corporate-wide "Security Coordinator", responsible 
for fixing, or getting fixed, all security bugs or flaws in our products. I 
had analyzed, without source code, the Java jail approach and had identified 
what I thought was a potential problem. I reached out internally and had a 
series of meetings with the main designer, the main architect, and the 
person who was in charge of security for Java. I told them each that my 
experience and intuition indicated that there would be a serious security 
bug, "right there", and volunteered to round up a group of volunteer 
external experts (I was well plugged into FIRST at the time) to help analyze 
potential problems.

All this was before any security bugs had been found in Java. And as busy as 
I was keeping up with bugs fixes, disclosures, and exploits inh UIX/Solaris, 
I was determined to act proactively and help perfect what I saw as a great 
step forward in security.

The three Java experts gave me the cold shoulder. I persisted. They told me 
to go away, and expressed with force and conviction that there were 
not--could not be--any security bugs in Java.

About 10 weeks later, I was at a national-security conference in Houston. 
While I was walking up to give my address on the Java Security 
Model--literally, while I was taking to the stage--an acquaintance there 
said, "Hard day for Sun security types, I guess" He then showed me the USA 
Today headline Gary referred to in his post. It turned out that Gary and Ed 
had independently discovered and (unsuccessfully) reported the self-same bug 
I had hypothesized about. It was fixed a few short weeks later.

Hubris is not endemic to a single company, or individual. And the inability 
to see our own mistakes (sometimes, even when they are pointed out to us) is 
something I don't believe we software types can even claim as particular to 
our occupation. It is, as luminaries like Peter Neumann and James Reason 
have amply demonstrated, a failure common to that combination of orderly and 
creative thinking we call engineering. Similarly, for reasons Ken and I 
discuss in Chapter 1 of "Secure Coding", the corporate animal really will, 
all too often, turn the Reality Distortion Field on full-force rather than 
deal with a pre-headline problem.

I often ask myself which set of dangerous behavior--corporate blindness, or 
preemptive disclosure--is more likely to trigger the first 
security-bug-caused death. I don't know. Can we turn the ship of software 
development before we hit that rock? I doubt it. One hopes.

-mg-



From michaelslists at gmail.com  Sat Nov  4 21:19:11 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Sun, 5 Nov 2006 13:19:11 +1100
Subject: [SC-L] re-writing college books [was: Re: A banner year for
	software bugs | Tech News on ZDNet]
In-Reply-To: <01de01c6fa76$1512db00$cb00000a@escheradmin>
References: <453E69E4.80300@novell.com>
	<01de01c6fa76$1512db00$cb00000a@escheradmin>
Message-ID: <5e01c29a0611041819u468ba6f0s24e6d92739f29485@mail.gmail.com>

On 10/28/06, David Crocker <dcrocker at eschertech.com> wrote:
> Crispin Cowan wrote:
>
> >>
> For me, the enemy in the room is C++. It gives you the safety of C with the
> performance of SmallTalk. There is no excuse at all to be writing anything in
> C++ yet vastly too many applications are written in C++ anyway. Instead of
> trying to coax developers to switch from C++ to something "weird" like SML, lets
> encourage them to switch to Java or C#, which are closer to their experience.
> <<
>
> Unfortunately, there are at least two situations in which C++ is a more suitable
> alternative to Java and C#:
>
> - Where performance is critical. Run time of C# code (using the faster .NET 2.0
> runtime) can be as much as double the run time of a C++ version of the same
> algorithm. Try telling a large company that it must double the size of its
> compute farms so you can switch to a "better" programming language!

Don't go there, sister. Come up with some reasonable tests before
making a statement like that. "Assembly code can be as much as a
million times faster then the run time of a C++ version of the same
algorithm." Bit useless, isn't it?

Lets not forget that writing faster/more optimised code in c++ will be
more complex and hence allow room for more errors then letting the
c#/java runtime optimiser do the dirty work for us.


> However, I suspect that most security-critical programs do not fall into either
> of these categories,

What? Cryptography rings a bell ...


> so C# or Java would indeed be a better choice than C++ for
> those programs.
>
> David Crocker, Escher Technologies Ltd.
> Consultancy, contracting and tools for dependable software development
> www.eschertech.com

-- mic

From dcrocker at eschertech.com  Sun Nov  5 07:17:01 2006
From: dcrocker at eschertech.com (David Crocker)
Date: Sun, 5 Nov 2006 12:17:01 -0000
Subject: [SC-L] re-writing college books [was: Re: A banner year for
	software bugs | Tech News on ZDNet]
In-Reply-To: <5e01c29a0611041819u468ba6f0s24e6d92739f29485@mail.gmail.com>
Message-ID: <00f001c700d4$67dcf870$cb00000a@escheradmin>

mikeiscool wrote:

>>
Don't go there, sister. Come up with some reasonable tests before making a
statement like that. "Assembly code can be as much as a million times faster
then the run time of a C++ version of the same algorithm." Bit useless, isn't
it?
<<

I would not have made the statement I did had the tests not been done and
provided very clear results. I am not at liberty to go into details of the tests
I have been involved with, however if you Google for e.g. "C++ C# performance",
you will see that other people are getting similar results.

>>
Lets not forget that writing faster/more optimised code in c++ will be more
complex and hence allow room for more errors then letting the c#/java runtime
optimiser do the dirty work for us.
<<

C++ offers much more room for errors than C# or Java, and not just in memory
management. If you re-read my comment, you will realise that I was not promoting
C++ as being a better language than C#, just pointing out that there are some
situations in which the replacement of C++ by C# is not yet feasible, such as
where a performance reduction of around 30% to 50% cannot be accepted. It is to
be hoped that as JIT compiler technology continues to improve, the performance
gap will be further reduced.

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com




-----Original Message-----
From: mikeiscool [mailto:michaelslists at gmail.com] 
Sent: 05 November 2006 02:19
To: David Crocker
Cc: Secure Coding
Subject: Re: [SC-L] re-writing college books [was: Re: A banner year for
software bugs | Tech News on ZDNet]


On 10/28/06, David Crocker <dcrocker at eschertech.com> wrote:
> Crispin Cowan wrote:
>
> >>
> For me, the enemy in the room is C++. It gives you the safety of C 
> with the performance of SmallTalk. There is no excuse at all to be 
> writing anything in
> C++ yet vastly too many applications are written in C++ anyway. 
> C++ Instead of
> trying to coax developers to switch from C++ to something "weird" like 
> SML, lets encourage them to switch to Java or C#, which are closer to 
> their experience. <<
>
> Unfortunately, there are at least two situations in which C++ is a 
> more suitable alternative to Java and C#:
>
> - Where performance is critical. Run time of C# code (using the faster 
> .NET 2.0
> runtime) can be as much as double the run time of a C++ version of the same
> algorithm. Try telling a large company that it must double the size of its
> compute farms so you can switch to a "better" programming language!

Don't go there, sister. Come up with some reasonable tests before making a
statement like that. "Assembly code can be as much as a million times faster
then the run time of a C++ version of the same algorithm." Bit useless, isn't
it?

Lets not forget that writing faster/more optimised code in c++ will be more
complex and hence allow room for more errors then letting the c#/java runtime
optimiser do the dirty work for us.


> However, I suspect that most security-critical programs do not fall 
> into either of these categories,

What? Cryptography rings a bell ...


> so C# or Java would indeed be a better choice than C++ for those 
> programs.
>
> David Crocker, Escher Technologies Ltd.
> Consultancy, contracting and tools for dependable software development 
> www.eschertech.com

-- mic



From leichter_jerrold at emc.com  Sun Nov  5 12:05:40 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Sun, 5 Nov 2006 12:05:40 -0500 (EST)
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <45435E9E.805@cert.org>
References: <Pine.LNX.4.21.0610280039300.14421-100000@linuxbox.org>
	<45430FBB.8080108@novell.com> <45435E9E.805@cert.org>
Message-ID: <Pine.SOL.4.61.0611051148110.8051@mental>

Much as I agree with many of the sentiments expressed in this discussion,
there's a certain air of unreality to it.  While software has it's own
set of problems, it's not the first engineered artifact with security
implications in the history of the world.  Bridges and buildings
regularly collapsed.  (In the Egyptian desert, you can still see a
pyramid that was built too aggressively - every designer wanted to
build higher and steeper than his predecessor - and collapsed before
it was finished.)  Steam boilers exploded.  Steel linings on wooden
railroad tracks stripped of, flew through the floors of passing cars,
and killed people.  Electrical systems regularly caused fires.

How do we keep such traditional artifacts safe?  It's not by writing
introductory texts with details of safety margins, how to analyze the
strength of materials, how to include a crowbar in a power supply.
What you *may* get in an introductory course is the notion that there
are standards, that when it comes time for you to actually design
stuff you'll have to know and follow them, and that if you don't you're
likely to end up at best unemployed and possibly in jail when your
"creativity" kills someone.

In software, we have only the beginnings of such standards.  We
teach and encourage an attitude in which every last bit of the
software is a valid place to exercise your creativity, for better
or (for most people, most of the time) worse.  With no established
standards, we have no way to push back on managers and marketing
guys and such who insist that something must be shipped by the
end of the week, handle 100 clients at a time, have no more tha
1 second response time, and run on some old 486 with 2 MB of memory.

I don't want to get into the morass of licensing.  It's a fact that
licensing is heavily intertwined with standard-setting in many
older fields, but not in all of them, and there's no obvious inherent
reason why it has to be.

The efforts to write down "best practices" at CERT are very important,
but also very preliminary.  As it stands, what we have to offer
are analogous to best practices for using saws and hammers and
such - not best practices for determining floor loadings, appropriate
beam strengths, safe fire evacuation routes.

Every little bit helps, but a look at history shows us just how
little we really have to offer as yet.
							-- Jerry




From michaelslists at gmail.com  Sun Nov  5 17:09:26 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Mon, 6 Nov 2006 09:09:26 +1100
Subject: [SC-L] re-writing college books [was: Re: A banner year for
	software bugs | Tech News on ZDNet]
In-Reply-To: <00f001c700d4$67dcf870$cb00000a@escheradmin>
References: <5e01c29a0611041819u468ba6f0s24e6d92739f29485@mail.gmail.com>
	<00f001c700d4$67dcf870$cb00000a@escheradmin>
Message-ID: <5e01c29a0611051409o451140dyf6fe9f8843f40ed8@mail.gmail.com>

On 11/5/06, David Crocker <dcrocker at eschertech.com> wrote:
> mikeiscool wrote:
>
> >>
> Don't go there, sister. Come up with some reasonable tests before making a
> statement like that. "Assembly code can be as much as a million times faster
> then the run time of a C++ version of the same algorithm." Bit useless, isn't
> it?
> <<
>
> I would not have made the statement I did had the tests not been done and
> provided very clear results. I am not at liberty to go into details of the tests
> I have been involved with, however if you Google for e.g. "C++ C# performance",
> you will see that other people are getting similar results.

Right, so again your statement is useless without numbers and tests we
can perform ourselves. You made the statement, so you either have to
prove it or let it slide.

-- mic

From ge at linuxbox.org  Sun Nov  5 17:53:56 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Sun, 5 Nov 2006 16:53:56 -0600 (CST)
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <Pine.SOL.4.61.0611051148110.8051@mental>
Message-ID: <Pine.LNX.4.21.0611051651530.30176-100000@linuxbox.org>

On Sun, 5 Nov 2006, Leichter, Jerry wrote:
> Much as I agree with many of the sentiments expressed in this discussion,
> there's a certain air of unreality to it.  While software has it's own
> set of problems, it's not the first engineered artifact with security
> implications in the history of the world.  Bridges and buildings
> regularly collapsed.  (In the Egyptian desert, you can still see a
> pyramid that was built too aggressively - every designer wanted to
> build higher and steeper than his predecessor - and collapsed before
> it was finished.)  Steam boilers exploded.  Steel linings on wooden
> railroad tracks stripped of, flew through the floors of passing cars,
> and killed people.  Electrical systems regularly caused fires.
> 
> How do we keep such traditional artifacts safe?  It's not by writing
> introductory texts with details of safety margins, how to analyze the
> strength of materials, how to include a crowbar in a power supply.
> What you *may* get in an introductory course is the notion that there
> are standards, that when it comes time for you to actually design
> stuff you'll have to know and follow them, and that if you don't you're
> likely to end up at best unemployed and possibly in jail when your
> "creativity" kills someone.
> 
> In software, we have only the beginnings of such standards.  We
> teach and encourage an attitude in which every last bit of the
> software is a valid place to exercise your creativity, for better
> or (for most people, most of the time) worse.  With no established
> standards, we have no way to push back on managers and marketing
> guys and such who insist that something must be shipped by the
> end of the week, handle 100 clients at a time, have no more tha
> 1 second response time, and run on some old 486 with 2 MB of memory.
> 
> I don't want to get into the morass of licensing.  It's a fact that
> licensing is heavily intertwined with standard-setting in many
> older fields, but not in all of them, and there's no obvious inherent
> reason why it has to be.
> 
> The efforts to write down "best practices" at CERT are very important,
> but also very preliminary.  As it stands, what we have to offer
> are analogous to best practices for using saws and hammers and
> such - not best practices for determining floor loadings, appropriate
> beam strengths, safe fire evacuation routes.
> 
> Every little bit helps, but a look at history shows us just how
> little we really have to offer as yet.

Well said, and quite right. A few pointers though.

A bridge is a single-purpose device. A watch is a simple purpose computer,
as was the Enigma machine, if we can call it such.

Multi-purpose computers or programmable computers are where our problems
start. Anyone can DO and create. One simply has to sit in front of a
keyboard and screen and make it happen..

As such, even if built well, the computer is programmable, and thus at
risk.

	Gadi.

> -- Jerry
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 


From sasa at pheniscidae.tvnetwork.hu  Sun Nov  5 17:59:26 2006
From: sasa at pheniscidae.tvnetwork.hu (SZALAY Attila)
Date: Sun, 05 Nov 2006 23:59:26 +0100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college books]
In-Reply-To: <00f001c700d4$67dcf870$cb00000a@escheradmin>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
Message-ID: <1162767566.2289.15.camel@sasa.home>

Hi All!

I read this thread and I little be afraid. I'm just ahead of a complete
rewriting of my program. The previous code was written in pure C (with
an OOP looks-like somewhere).

This program should run on Linux, freebsd and windows platform. This
program is a GUI, so it has a graphical interface too but do a lot of
computing and xml handling.

I know C the most, so C++ is the least step I have to do. But I'm
uncertain now that this is enough. When I have looked around for OO
alternatives the C# was dropped, because I couldn't find a
cross-platform graphical tools and Java was dropped because it's speed
and the possibilities of debugging problems.

Is there any other alternatives or I left something or the C++ is the
only alternative for me?

From ppowenski at yahoo.com  Mon Nov  6 04:09:21 2006
From: ppowenski at yahoo.com (Paul Powenski)
Date: Mon, 6 Nov 2006 01:09:21 -0800 (PST)
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <Pine.SOL.4.61.0611051148110.8051@mental>
Message-ID: <20061106090921.97163.qmail@web54003.mail.yahoo.com>

Most of the incidents in your first paragraph were improved with the establishment of laws, regulation bodies, and external testing with a stamp of approval.
 The Underwriters labaroratory was established to ensure that a product was sales worthy to the public due to manufacturers focusing on sales and not much on safety. 
 
 Having a clearing house/body/organization which inspects an application for business worthiness, critical machinery functions, consumer entertainment or consumer sensitive use (personal planner, financial package) might  persuade vendors to use security enabled tools and  software building tools stricktly based upon  how difficult it is to acheive a  worthiness  approval. For instance if an application is developed in C,C++,C# then an appropriate set of audits and testing must be performed to acheive a certification. Since these would be more comprehensive than other languages the vendor would have to decide which is easier the extra expense of the extensive audits and testing vs. using a approved language that does not required a greater degree of testing. This would provide software tools vendors the incentive to create more security enabled tools to align themselves with the requirements of the body delivering the accredication for use.
 
 The software industry is no different than most other industries. There are devices with little risk a garage door opener, a radio might have more user risk depending upon how you look at it, and then there are very dangerous applicances Irons, Microwaves, Snow Blowers. 
 For software a game, word processor, personal finance planner, for a business a financial package.
 
 

"Leichter, Jerry" <leichter_jerrold at emc.com> wrote: Much as I agree with many of the sentiments expressed in this discussion,
there's a certain air of unreality to it.  While software has it's own
set of problems, it's not the first engineered artifact with security
implications in the history of the world.  Bridges and buildings
regularly collapsed.  (In the Egyptian desert, you can still see a
pyramid that was built too aggressively - every designer wanted to
build higher and steeper than his predecessor - and collapsed before
it was finished.)  Steam boilers exploded.  Steel linings on wooden
railroad tracks stripped of, flew through the floors of passing cars,
and killed people.  Electrical systems regularly caused fires.

How do we keep such traditional artifacts safe?  It's not by writing
introductory texts with details of safety margins, how to analyze the
strength of materials, how to include a crowbar in a power supply.
What you *may* get in an introductory course is the notion that there
are standards, that when it comes time for you to actually design
stuff you'll have to know and follow them, and that if you don't you're
likely to end up at best unemployed and possibly in jail when your
"creativity" kills someone.

In software, we have only the beginnings of such standards.  We
teach and encourage an attitude in which every last bit of the
software is a valid place to exercise your creativity, for better
or (for most people, most of the time) worse.  With no established
standards, we have no way to push back on managers and marketing
guys and such who insist that something must be shipped by the
end of the week, handle 100 clients at a time, have no more tha
1 second response time, and run on some old 486 with 2 MB of memory.

I don't want to get into the morass of licensing.  It's a fact that
licensing is heavily intertwined with standard-setting in many
older fields, but not in all of them, and there's no obvious inherent
reason why it has to be.

The efforts to write down "best practices" at CERT are very important,
but also very preliminary.  As it stands, what we have to offer
are analogous to best practices for using saws and hammers and
such - not best practices for determining floor loadings, appropriate
beam strengths, safe fire evacuation routes.

Every little bit helps, but a look at history shows us just how
little we really have to offer as yet.
       -- Jerry



_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


 
---------------------------------
 Check out the New Yahoo! Mail - Fire up a more powerful email and get things done faster. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061106/bdec9a2d/attachment.html 

From michaelslists at gmail.com  Mon Nov  6 07:23:06 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Mon, 6 Nov 2006 23:23:06 +1100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <1162767566.2289.15.camel@sasa.home>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
Message-ID: <5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>

On 11/6/06, SZALAY Attila <sasa at pheniscidae.tvnetwork.hu> wrote:
> Hi All!
>
> I read this thread and I little be afraid. I'm just ahead of a complete
> rewriting of my program. The previous code was written in pure C (with
> an OOP looks-like somewhere).
>
> This program should run on Linux, freebsd and windows platform. This
> program is a GUI, so it has a graphical interface too but do a lot of
> computing and xml handling.
>
> I know C the most, so C++ is the least step I have to do. But I'm
> uncertain now that this is enough. When I have looked around for OO
> alternatives the C# was dropped, because I couldn't find a
> cross-platform graphical tools and Java was dropped because it's speed
> and the possibilities of debugging problems.

Hold the phone ... What debugging problems? What _specific_ speed
issues? I'd be really surprised if your project couldn't be resolved
with java; what specific problems are you facing? What tests have you
run/consider to show that java's supposed "speed issues" will give you
trouble? If it's just xml processing I'd say efficient data structures
are what you care about, so java can help you there.


> Is there any other alternatives or I left something or the C++ is the
> only alternative for me?

Certainly not. If all else fails you can write memory-intensive stuff
in a dll and import it into one java or c#. It'll still be some
lower-level coding (in c++ or c or asm) but at least it'll be
isolated.

You'll need to explain your program more ...

-- mic

From psteichen at gmail.com  Mon Nov  6 07:33:30 2006
From: psteichen at gmail.com (psteichen)
Date: Mon, 6 Nov 2006 13:33:30 +0100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <1162767566.2289.15.camel@sasa.home>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
Message-ID: <a92866b40611060433y780d2e28i14d4908c9cce8157@mail.gmail.com>

for cross-platform C# there is the mono project which do a great jpb of
porting the .NET framework to the Linux world, check it out at :
http://www.mono-project.com/

further perl or python (which are more or less cross-platform) might also be
used for your rewrite project, all depends one your specific needs...

On 11/5/06, SZALAY Attila <sasa at pheniscidae.tvnetwork.hu> wrote:
>
> Hi All!
>
> I read this thread and I little be afraid. I'm just ahead of a complete
> rewriting of my program. The previous code was written in pure C (with
> an OOP looks-like somewhere).
>
> This program should run on Linux, freebsd and windows platform. This
> program is a GUI, so it has a graphical interface too but do a lot of
> computing and xml handling.
>
> I know C the most, so C++ is the least step I have to do. But I'm
> uncertain now that this is enough. When I have looked around for OO
> alternatives the C# was dropped, because I couldn't find a
> cross-platform graphical tools and Java was dropped because it's speed
> and the possibilities of debugging problems.
>
> Is there any other alternatives or I left something or the C++ is the
> only alternative for me?
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061106/32742427/attachment-0001.html 

From leichter_jerrold at emc.com  Mon Nov  6 08:22:32 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Mon, 6 Nov 2006 08:22:32 -0500 (EST)
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <20061106090921.97163.qmail@web54003.mail.yahoo.com>
References: <20061106090921.97163.qmail@web54003.mail.yahoo.com>
Message-ID: <Pine.SOL.4.61.0611060803570.8051@mental>

| Most of the incidents in your first paragraph were improved with the
| establishment of laws, regulation bodies, and external testing with a
| stamp of approval.  The Underwriters labaroratory was established to
| ensure that a product was sales worthy to the public due to
| manufacturers focusing on sales and not much on safety.
|  
|  Having a clearing house/body/organization which inspects an
| application for business worthiness, critical machinery functions,
| consumer entertainment or consumer sensitive use (personal planner,
| financial package) might persuade vendors to use security enabled
| tools and software building tools stricktly based upon how difficult
| it is to acheive a worthiness approval. For instance if an application
| is developed in C,C++,C# then an appropriate set of audits and testing
| must be performed to acheive a certification. Since these would be
| more comprehensive than other languages the vendor would have to
| decide which is easier the extra expense of the extensive audits and
| testing vs. using a approved language that does not required a greater
| degree of testing. This would provide software tools vendors the
| incentive to create more security enabled tools to align themselves
| with the requirements of the body delivering the accredication for
| use.
|  
|  The software industry is no different than most other
| industries. There are devices with little risk a garage door opener, a
| radio might have more user risk depending upon how you look at it, and
| then there are very dangerous applicances Irons, Microwaves, Snow
| Blowers.  For software a game, word processor, personal finance
| planner, for a business a financial package.
I agree with what you say .... until the very last paragraph.  The
different in the software industry is that we don't really know yet what
the right standards should be - and it's not even clear to me that there
is any concerted effort to find out.  Yes, it's possible to build
highly reliable software for things like aircraft control.  It's (a)
extremely expensive to do - the techniques we have today are so
expensive as to rule out all but obviously life-critical uses of
software; (b) only give you assurance in certain directions.  In
particular, aircraft control software doesn't have to be exposed to
active, intelligent attackers on the Internet.

All elements of the software development community - developers
themselves, software makers, makers of products based on software, even
most software purchasers and users - have a vested interest in resisting
such laws, regulations, and external bodies.  It crimps their style,
adds to their costs, and has no obvious benefits.  The same, of course,
was true of most other kinds of engineered product development at some
point in their life.  However, it's much easier for everyone to see that
there is something wrong when a boiler blows up because the maker saved
money by using steel that's too brittle than it is to see that a bug in
handling URL's allowed a cross-site scripting attack that allowed
critical information to be stolen.  This leads to much less pressure on
the software industry to fix things.  Things are changing, but we're
running into another problem: Even very simple attempts at regulation
quickly run into lack of the basic science and engineering knowledge
necessary.  Industry standards on boilers could refer to standard tables
of steel strengths.  An industry standard to prevent cross-site
scripting attacks could refer to ... what, exactly?  And, again, there
is the important distinction that boiler failures are due to "lawful"
physical processes, while cross-site scripting prevention failures are
due to intelligent attacks.  Perhaps for that kind of thing we need to
look not at industry standards but at military experience....

							-- Jerry

From Kevin.Wall at qwest.com  Mon Nov  6 09:02:38 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Mon, 6 Nov 2006 08:02:38 -0600
Subject: [SC-L] re-writing college books - erm.. ahm...
References: <Pine.LNX.4.21.0611051651530.30176-100000@linuxbox.org>
Message-ID: <CF8B26B8B49184429CB084616B00193002F2AF77@itomae2km05.AD.QINTRA.COM>

In response to a post by Jerry Leichter, Gadi Evron wrote...

> A bridge is a single-purpose device. A watch is a simple
> purpose computer, as was the Enigma machine, if we can call
> it such.
> 
> Multi-purpose computers or programmable computers are where
> our problems start. Anyone can DO and create. One simply has
> to sit in front of a keyboard and screen and make it happen.

Let us keep in mind that in the name of profits (and ignoring our
prophets, see .sig, below), as an industry, we have strived to
lower the entry level of programming by introducing "diseases"
(I'll probably catch some flack for that) such as Visual Basic,
etc. so that managers who have never had even the simplest
introduction to computer science can now develop their own
software, complete with security vulnerabilities. This only
exacerbates the situation. To add to that, often you get some
manager or marketing type who slaps together a "working" prototype
of something they or a customer is asking for by using a spreadsheet,
an Access "database", and some VB glue that works for maybe 100
records and then s/he thinks that a small development team should be
able to tweak that prototype to turn it into an enterprise-wide,
Internet-facing application that can handle millions of records,
handle a transaction volume that is 3 or 4 orders of magnitude larger
than the prototype handles, and slap it all together in a couple
of weeks.

Developers have to cut corners somewhere, and since security issues
are not paramount, that's often what gets overlooked.

As an industry, I think that we've, in part, done this to ourselves.
When I started in this industry 27 years ago, at least real software
engineering techniques were _attempted_. There were requirements
gathered, specifications written and reviewed, designs written,
reviewed, and applied, and an extensive testing period after
coding was more or less complete. But that used to take 15-20 people
about 1 to 2 years. Now we've compressed that down to 90 days or so,
so something had to give (besides our sanity ;-). What I see today
is a few "analysts" go talk to marketing or other stakeholders and
they write up some "user stories" (not even real "use cases"; what
I'm referring to but more like a sentence or two describing some basic,
sunny-day-only usage scenario collected into a spreadsheet). From
there, the application development teams jump directly into coding/testing,
magically expecting the design to somehow just "emerge" or expecting to
be able to "refactor it" later (if there ever is a "later"). (Can you
tell I think that extreme programming--at least as practiced here--has
been a horrible failure, especially from a security POV? :)

I ask you, just where would civil or mechanical engineering be today
if they had encouraged the average construction worker to develop their
own bridge or designed their own buildings rather than relying on
architects and engineers to do this? That's just one reason why things
are as bad as they are. Today, I don't even see professional software
developers develop software using good software engineering principles.
("It takes too long" or "It's too expensive" are the usual comments.)
Or where would we be if the city council expected to build a new
80-story skyscraper, starting from inception, in only 6 months?
It's no wonder that we so often here that remark that says

 "If [building] architects built buildings the way that
 software developers build software, the first woodpecker
 that came by would destroy civilization."

Maybe what we need is to require that as part of the software development
education, we need to partly indoctrinate them into other "real"
engineering disciplines and hope that some of it rubs off. Because, IMO
what we are doing now is failing miserably.

BTW, if you've not yet read the Dijkstra article referenced below, I
highly recommend it. It's quite dated, but it's a gem for .sig quotes.

-kevin

Std disclaimer: Everything I've written above reflects solely my own
                opinion and not the opinion of any of my employers,
                past or present.
--- 
Kevin W. Wall           Qwest Information Technology, Inc. 
Kevin.Wall at qwest.com <mailto:Kevin.Wall at qwest.com>     Phone: 614.215.4788 
"It is practically impossible to teach good programming to students 
 that have had a prior exposure to BASIC: as potential programmers 
 they are mentally mutilated beyond hope of regeneration" 
    - Edsger Dijkstra, How do we tell truths that matter? 
      http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html <http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html> 



This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.


From mouse at Rodents.Montreal.QC.CA  Mon Nov  6 10:47:56 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Mon, 6 Nov 2006 10:47:56 -0500 (EST)
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <1162767566.2289.15.camel@sasa.home>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
Message-ID: <200611061553.KAA17083@Sparkle.Rodents.Montreal.QC.CA>

> I read this thread and I little be afraid.  I'm just ahead of a
> complete rewriting of my program.  The previous code was written in
> pure C (with an OOP looks-like somewhere).

Perhaps I'm missing something.  Why do you have to abandon C?  You
mention C++, C#, and Java, but no other languages; is there some reason
you have to use a language that tries to be object-oriented?

Also, you have said nothing about what the tradeoffs involved are.
Since this is sc-l, I assume security is involved; what does this code
need to be secure against?

It could very well be that C is the right language for you to use.
Yes, it has problems, but so do all other languages; it's just a
question of finding the language whose problems are least problematic
for you and your application, and it sounds to me as though some of the
most important problems for you have nothing to do with the languages'
capabilities per se.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From ljknews at mac.com  Mon Nov  6 11:57:56 2006
From: ljknews at mac.com (ljknews)
Date: Mon, 6 Nov 2006 11:57:56 -0500
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
 books]
In-Reply-To: <200611061553.KAA17083@Sparkle.Rodents.Montreal.QC.CA>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
	<200611061553.KAA17083@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <p05200f12c17519e8cb97@[192.168.1.254]>

At 10:47 AM -0500 11/6/06, der Mouse wrote:
>> I read this thread and I little be afraid.  I'm just ahead of a
>> complete rewriting of my program.  The previous code was written in
>> pure C (with an OOP looks-like somewhere).
> 
> Perhaps I'm missing something.  Why do you have to abandon C?  You
> mention C++, C#, and Java, but no other languages; is there some reason
> you have to use a language that tries to be object-oriented?

Is there some reason you have to use a language that "looks like" C ?
-- 
Larry Kilgallen

From peter.werner at gmail.com  Mon Nov  6 18:19:40 2006
From: peter.werner at gmail.com (pete werner)
Date: Tue, 7 Nov 2006 10:19:40 +1100
Subject: [SC-L] re-writing college books - erm.. ahm...
In-Reply-To: <CF8B26B8B49184429CB084616B00193002F2AF77@itomae2km05.AD.QINTRA.COM>
References: <Pine.LNX.4.21.0611051651530.30176-100000@linuxbox.org>
	<CF8B26B8B49184429CB084616B00193002F2AF77@itomae2km05.AD.QINTRA.COM>
Message-ID: <6378f48a0611061519q44deb0c3iba43b122c575d953@mail.gmail.com>

On 11/7/06, Wall, Kevin <Kevin.Wall at qwest.com> wrote:
>
> Developers have to cut corners somewhere, and since security issues
> are not paramount, that's often what gets overlooked.
>

this is the biggest issue i think. it gets overlooked because
management dont value it. partly because its expensive to do, and
theres no real qualitative or quantitative measures of success. you
cant go to your management and say "i spent 20% of my time working on
security issues, it cost us $x but it will save our customers $y, and
security was improved by 15%" or if you can, you're bullshitting, but
will probably get a nice bonus :)

i think a college level textbook would have limited benefit. there is
plenty of information out there at the moment for those who are
interested, both on the net and in book form. i suppose its nice to
have a single point of reference though. however, most graduates
aren't really good practical programmers. they know stuff like what a
for loop is and how recursion works, which is great, but they learn
the ins and outs of developing when they get their first real job.

so they get their first job, and basically learn from the people
they're working with. the people they're working with and learning
from are busy, and working under time and budget constraints. they're
just not going to focus on security, even if they had the knowledge to
do it effectively, because other things are more important to the
companies management. most managers (and developers too i guess) do
care about security, but only in the way people care about global
warming. they know global warming is bad, but oh gee what are we going
to do, oh today i remembered to turn off my desk lamp when i left the
office. great. same with security, you dont have to be a genius to
work out security holes are bad, but oh gee what are you actually
going to do about it?

if organisations dont really care about software security, a security
concious developer faces an uphill battle. if two devs are working on
some code, one does it slower but more securely, the other does it
quicker but less securely, who's going to look better, in a typical
organisation? your fresh grad is going to learn quick enough what
companies want from them. as time goes by, they become the ones
breaking in the new developers, so the cycle continues. a book isnt
going to help this, it probably wont hurt, but i dont think the lack
of available literature is a big problem.

a good organisation will focus on what its customers want. untill the
customers start kicking up a storm about vulnerabilities, there's
little impetus for management to devote resources to security. i think
this is one of the things microsoft has done well, over the last few
years they have started taking security seriously, and i can only
assume its because their customers starting complaining. they still
have a lot of security issues (an insuperable amount imo), but it
shows that for companies to start taking software security seriously,
it has to be something the customer wants.

From jjchryan at gwu.edu  Mon Nov  6 22:42:29 2006
From: jjchryan at gwu.edu (Julie J.C.H. Ryan)
Date: Mon, 6 Nov 2006 22:42:29 -0500
Subject: [SC-L] Fwd:  re-writing college books - erm.. ahm...
References: <63c483720611061314h1a035f18wcd007dae2547da5@mail.gmail.com>
Message-ID: <5ED0BA83-2324-4C47-8A46-60180144BA32@gwu.edu>

Folks, I've been forwarding select messages from this listserv to my  
nephews, who are undergrads in CS at some fairly reknown  
universities, which shall remain nameless cause it would embarrass  
the heck out of them to have the following sentiment aired......

Begin forwarded message:

>
> ya, as per one of your previous emails, we are still taught to use
> only printf and random stuff like that. printf was even incorporated
> into java 1.5 because "it was so good." But right now I think we are
> really just learning base algorithms and ideas rather than security
> practices. Hell, I talked to my student advisor and apparently I can't
> even take security courses till I'm working on a masters degree.
>


From ge at linuxbox.org  Tue Nov  7 08:01:13 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Tue, 7 Nov 2006 07:01:13 -0600 (CST)
Subject: [SC-L] Fwd:  re-writing college books - erm.. ahm...
In-Reply-To: <5ED0BA83-2324-4C47-8A46-60180144BA32@gwu.edu>
Message-ID: <Pine.LNX.4.21.0611070700040.32180-100000@linuxbox.org>

On Mon, 6 Nov 2006, Julie J.C.H. Ryan wrote:
> Folks, I've been forwarding select messages from this listserv to my  
> nephews, who are undergrads in CS at some fairly reknown  
> universities, which shall remain nameless cause it would embarrass  
> the heck out of them to have the following sentiment aired......
> 
> Begin forwarded message:
> 
> >
> > ya, as per one of your previous emails, we are still taught to use
> > only printf and random stuff like that. printf was even incorporated
> > into java 1.5 because "it was so good." But right now I think we are
> > really just learning base algorithms and ideas rather than security
> > practices. Hell, I talked to my student advisor and apparently I can't
> > even take security courses till I'm working on a masters degree.

Well, I never recieved any replies here on what's already being done.. so
now, I am asking for ideas on how we can approach schools. What's needed,
in order for basic CS classes to have a security orientation?

	Gadi.


From robin at kallisti.net.nz  Tue Nov  7 08:27:03 2006
From: robin at kallisti.net.nz (Robin Sheat)
Date: Wed, 8 Nov 2006 02:27:03 +1300
Subject: [SC-L] Fwd:  re-writing college books - erm.. ahm...
In-Reply-To: <5ED0BA83-2324-4C47-8A46-60180144BA32@gwu.edu>
References: <63c483720611061314h1a035f18wcd007dae2547da5@mail.gmail.com>
	<5ED0BA83-2324-4C47-8A46-60180144BA32@gwu.edu>
Message-ID: <200611080227.20429.robin@kallisti.net.nz>

On Tuesday 07 November 2006 16:42, Julie J.C.H. Ryan wrote:
> Folks, I've been forwarding select messages from this listserv to my
> nephews, who are undergrads in CS at some fairly reknown
I did a CS degree quite recently. There was simply _no_ mention of security, 
with the exception of passing mentions in the software engineering paper. In 
my 4th year (first year of postgrad), I did a paper on network security that 
was run by the information science department[0] for my own edification. A 
good paper, although it didn't cover software development security at all 
(and didn't intend to, either).

A large amount of the programming done there is in safer languages, however. I 
was in the last year doing Pascal, now it's Java. They are taught C later 
more to give students exposure to something a bit 'closer to the metal', 
where less of the donkey work is taken care of. After that, it tends to 
develop more into specific languages as suits what people are doing (haskell, 
prolog, LISP, etc). 

It is important to note that there is no goal of teaching students to go off 
and be safe programmers. Computer science is seen to a reasonable extent to 
be a theoretical persuit. Algorithms are covered, GC methods, heuristical 
searchs, and so on. That many students from this tend to go off and become 
programmers is almost seen the same as if they went off and became plumbers, 
just much more common. They are, of course, expected to hang around and 
become academics ;)

You could reasonably argue (and I'm inclined to believe it myself) that not 
teaching secure practices to computer science students is a problem, but I 
think that the underlying issue is more that security is more of a vocational 
thing, the same as if they were to teach, say, programming with EJB. (Note: I 
consider many branches of security research to fit fairly comfortably into 
computer science, but I don't think that things like 'avoiding buffer 
overflow vulnerabilities' do, the usefulness of the knowledge aside)

None of this is to say that it shouldn't be taught, just to provide my 
opinions on why it's not taught. Given a large number of CS students _do_ go 
off and develop real-world software, security should be given some time.

Aside: I don't think there's anything wrong with printf in Java, it is 
helpful, and AFAIK it's not prone to the same format string vulnerabilities 
as C is.

[0] at my uni, information science is the more business/application-oriented 
computer-related department, computer science is much more like applied 
mathematics/biology/cognitive psychology, depending on what exactly you're 
doing.

-- 
Robin <robin at kallisti.net.nz> JabberID: <eythian at jabber.kallisti.net.nz>

Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20061108/53dd0592/attachment.bin 

From bishop at cs.ucdavis.edu  Tue Nov  7 12:56:42 2006
From: bishop at cs.ucdavis.edu (Matt Bishop)
Date: Tue, 7 Nov 2006 09:56:42 -0800
Subject: [SC-L] Fwd:  re-writing college books - erm.. ahm...
In-Reply-To: <Pine.LNX.4.21.0611070700040.32180-100000@linuxbox.org>
References: <Pine.LNX.4.21.0611070700040.32180-100000@linuxbox.org>
Message-ID: <A5946BE0-82EC-48C6-AF67-258AD2513DF3@cs.ucdavis.edu>

Folks,

A comment based on an idea we tried here.

> Well, I never recieved any replies here on what's already being  
> done.. so
> now, I am asking for ideas on how we can approach schools. What's  
> needed,
> in order for basic CS classes to have a security orientation?

Ideally, I agree with the sentiment but would quarrel with the  
wording :-). On a practical level, I think this is very unlikely to  
happen. For example, one problem is those classes are already  
overloaded with how to program *plus* language stuff. You can only do  
so much in 10 or 15 weeks (depending on whether you're on the quarter  
or semester system).

An alternative to focusing on the introductory classes is to provide  
support for programming throughout the curriculum. But the big  
problem is overloaded classes--we try to teach too much material now.  
Telling an algorithms instructor she also needs to teach some  
security will fail on at least two counts: (1) "How do I teach the  
required course material *plus* security?" (2) "How do I learn enough  
about security to know what to teach and how to teach it? And where  
do I find the time to learn this?" So I don't think adding more  
material to existing classes will work.

So let's take a page from English departments and/or law schools.  
Both have writing clinics--they are separate from classes, and  
provide reviews of written papers before those papers are turned in.  
The ones I'm familiar with do *not* address content, but they *do*  
address mechanics (grammar, punctuation, etc.) and expression--does  
the writing make sense, is it well organized, and so forth. Why not  
establish something similar for programming?

You could work this in a number of ways. The one we've tried here was  
to require the students to write the program and then meet with  
someone working in the clinic. The clinician went through the program  
with the student, pointed out potential problems and bad programming  
practices, and (when appropriate) security issues. No grading  
occurred, but the student could rewrite the program to fix the  
problems pointed out (and others that the student found--the  
clinician did not try to find all the problems, just enough to show  
the student what types of problems were there).

We did some very informal testing, and the results were promising. If  
anyone's interested, we did a write-up of it; see:

http://nob.cs.ucdavis.edu/~bishop/papers/2006-cisse-2/

I need to emphasize the results are informal because we weren't  
educational metricians. Our next step (assuming we can get the  
funding) will be to devise formal metrics and do some more rigorous  
measurements to see how well the clinic works.

The interesting point about the clinic is that it appeared to be  
effective at both introductory and upper division levels, provided  
the students used it. It also would provide reinforcement throughout  
the student's undergraduate education, and give the student more of a  
chance to absorb good programming practices than do one or two  
classes that focus on those aspects of programming.

Just a thought ....

Matt

==================================
Matt Bishop
Department of Computer Science
University of California at Davis
One Shields Ave.
Davis, CA 95616-8562
United States of America

phone: +1 530 752 8060
fax: +1 530 752 4767
web: http://seclab.cs.ucdavis.edu/~bishop




From james.walden at gmail.com  Tue Nov  7 13:08:37 2006
From: james.walden at gmail.com (James Walden)
Date: Tue, 7 Nov 2006 13:08:37 -0500
Subject: [SC-L] Fwd: re-writing college books - erm.. ahm...
In-Reply-To: <Pine.LNX.4.21.0611070700040.32180-100000@linuxbox.org>
References: <5ED0BA83-2324-4C47-8A46-60180144BA32@gwu.edu>
	<Pine.LNX.4.21.0611070700040.32180-100000@linuxbox.org>
Message-ID: <21c655860611071008x9860fc7l3fd138f8b7d12130@mail.gmail.com>

On 11/7/06, Gadi Evron <ge at linuxbox.org> wrote:

>
> Well, I never recieved any replies here on what's already being done.. so
> now, I am asking for ideas on how we can approach schools. What's needed,
> in order for basic CS classes to have a security orientation?



Most CS professors have little awareness about security in general or secure
programming techniques in specific, so I think awareness is the place we
need to start.  I've been giving workshops in secure programming and
software security targeted at CS educators since 2005 and will be giving
workshops in both areas in March at the largest annual gathering of CS
educators, the ACM SIGCSE Conference (
http://www.cs.potsdam.edu/sigcse07/index.html).

Software security awareness is growing these days.  I've seen software
security and/or secure programming classes appear at a couple dozen security
focused CS departments in the last couple of years, including my own.  I
teach relevant software security topics in my classes, and I know professors
at a few universities who are working on a variety of approaches to
introducing secure programming into CS1 and CS2.

I'm currently surveying a variety of introductory CS textbooks in C, C++,
and Java to look for security errors in their examples.  If you know of any
such errors, I'd appreciate getting an e-mail from you with the information
about the error.  I plan to use the data as part of a paper on teaching
secure programming in early CS classes and will acknowledge any
contributions in the paper.

James Walden
Assistant Professor, NKU
http://www.nku.edu/~waldenj1/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061107/dd3b7583/attachment.html 

From ge at linuxbox.org  Tue Nov  7 13:40:33 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Tue, 7 Nov 2006 12:40:33 -0600 (CST)
Subject: [SC-L] Fwd:  re-writing college books - erm.. ahm...
In-Reply-To: <200611080227.20429.robin@kallisti.net.nz>
Message-ID: <Pine.LNX.4.21.0611071237570.16918-100000@linuxbox.org>

On Wed, 8 Nov 2006, Robin Sheat wrote:
> 
> It is important to note that there is no goal of teaching students to go off 
> and be safe programmers. Computer science is seen to a reasonable extent to 
> be a theoretical persuit. Algorithms are covered, GC methods, heuristical 
> searchs, and so on. That many students from this tend to go off and become 
> programmers is almost seen the same as if they went off and became plumbers, 
> just much more common. They are, of course, expected to hang around and 
> become academics ;)

CS degree brings you to the academic world, and makes a scietist of
you. Many go that route to become, coders.

You don't teach programming at an EDU.

As they are supposed to be scientists, I see no reason why this training
can't be done with correct programming in mind. Teaching people how to
code wrongly just to teach them later how it sid one correctly and slower,
is a silly idea.

It's not a bad idea as a conentrated specialized course, it is a silly
idea as far as the actual original teaching goes, that is equivalent to
patches rather than no vulnerabilities.

	Gadi.


From ge at linuxbox.org  Tue Nov  7 13:45:54 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Tue, 7 Nov 2006 12:45:54 -0600 (CST)
Subject: [SC-L] Fwd:  re-writing college books - erm.. ahm...
In-Reply-To: <A5946BE0-82EC-48C6-AF67-258AD2513DF3@cs.ucdavis.edu>
Message-ID: <Pine.LNX.4.21.0611071243340.16918-100000@linuxbox.org>

On Tue, 7 Nov 2006, Matt Bishop wrote:
> Folks,
> 
> A comment based on an idea we tried here.
> 
> > Well, I never recieved any replies here on what's already being  
> > done.. so
> > now, I am asking for ideas on how we can approach schools. What's  
> > needed,
> > in order for basic CS classes to have a security orientation?
> 
> Ideally, I agree with the sentiment but would quarrel with the  
> wording :-). On a practical level, I think this is very unlikely to  
> happen. For example, one problem is those classes are already  
> overloaded with how to program *plus* language stuff. You can only do  
> so much in 10 or 15 weeks (depending on whether you're on the quarter  
> or semester system).
> 
> An alternative to focusing on the introductory classes is to provide  
> support for programming throughout the curriculum. But the big  
> problem is overloaded classes--we try to teach too much material now.  
> Telling an algorithms instructor she also needs to teach some  
> security will fail on at least two counts: (1) "How do I teach the  
> required course material *plus* security?" (2) "How do I learn enough  
> about security to know what to teach and how to teach it? And where  
> do I find the time to learn this?" So I don't think adding more  
> material to existing classes will work.
> 
> So let's take a page from English departments and/or law schools.  
> Both have writing clinics--they are separate from classes, and  
> provide reviews of written papers before those papers are turned in.  
> The ones I'm familiar with do *not* address content, but they *do*  
> address mechanics (grammar, punctuation, etc.) and expression--does  
> the writing make sense, is it well organized, and so forth. Why not  
> establish something similar for programming?
> 
> You could work this in a number of ways. The one we've tried here was  
> to require the students to write the program and then meet with  
> someone working in the clinic. The clinician went through the program  
> with the student, pointed out potential problems and bad programming  
> practices, and (when appropriate) security issues. No grading  
> occurred, but the student could rewrite the program to fix the  
> problems pointed out (and others that the student found--the  
> clinician did not try to find all the problems, just enough to show  
> the student what types of problems were there).
> 
> We did some very informal testing, and the results were promising. If  
> anyone's interested, we did a write-up of it; see:
> 
> http://nob.cs.ucdavis.edu/~bishop/papers/2006-cisse-2/
> 
> I need to emphasize the results are informal because we weren't  
> educational metricians. Our next step (assuming we can get the  
> funding) will be to devise formal metrics and do some more rigorous  
> measurements to see how well the clinic works.
> 
> The interesting point about the clinic is that it appeared to be  
> effective at both introductory and upper division levels, provided  
> the students used it. It also would provide reinforcement throughout  
> the student's undergraduate education, and give the student more of a  
> chance to absorb good programming practices than do one or two  
> classes that focus on those aspects of programming.
> 
> Just a thought ....

I am not sure I understand all you wrote yet. So I may ask you more later.

Let me ask you this, the basic courses such as C (pascal, c++,
whatever) are used to teach other things along the line. Won't changing
that course be a great start?

Further, if not much can be changed with time constraints, what would it
"cost, for example, to teach people to check their input, or set
boundaries? With references to more material.

	Gadi.

> 
> Matt
> 
> ==================================
> Matt Bishop
> Department of Computer Science
> University of California at Davis
> One Shields Ave.
> Davis, CA 95616-8562
> United States of America
> 
> phone: +1 530 752 8060
> fax: +1 530 752 4767
> web: http://seclab.cs.ucdavis.edu/~bishop
> 
> 
> 


From Greg.Beeley at LightSys.org  Tue Nov  7 18:47:44 2006
From: Greg.Beeley at LightSys.org (Greg Beeley)
Date: Tue, 07 Nov 2006 15:47:44 -0800
Subject: [SC-L] Fwd:  re-writing college books - erm.. ahm...
In-Reply-To: <Pine.LNX.4.21.0611071243340.16918-100000@linuxbox.org>
References: <Pine.LNX.4.21.0611071243340.16918-100000@linuxbox.org>
Message-ID: <45511B20.2000501@LightSys.org>

Hi all,

I've been watching this discussion with interest, as I've taught a
undergrad-level course a couple of times that focuses on infosec
with a concentration in software security.  Yes, _Secure Coding_
was one of the books we used :)

A few observations from my experience so far:

   - Sure, we can teach "don't overflow the buffer" in lower division
     undergrad courses, but many students won't understand the
     reasons why this results in an exploitable condition, since those
     reasons require understanding concepts that are not normally taught
     until the upper division of undergrad CS.

   - I think we need to not only give the students the right *tools*
     to code securely, but also the right *mindset*.  It is harder
     to teach the "mindset" in the earlier courses.

   - As for a specialized course on software security, it can be
     tricky working it into the undergrad CS curriculum.  When I've
     taught this material, I could not assume (for instance) a
     certain degree of student knowledge about computer architecture
     and the way the call stack works.  I had to explain that stuff
     just to be able to explain how a buffer overflow works, for instance.

   - We can teach, "be more secure, use Java/C#/etc instead of C",
     and that is good, but remember that these students are going
     out into the real workforce and will use the language(s)
     chosen by their employers (or already in place on an existing
     product line).  I do believe that students still need to know
     how to use C/C++ responsibly.  Otherwise, they may very well
     be ill-prepared for the real world :)

   - As for vocational vs. academic, I think there's a lot of room
     for software security in each.  At the academic level, you
     spend more time explaining the underlying concepts.  For
     example, teaching why having a call stack share data and program
     flow control constructs tends to cause trouble (when no enforcement
     of the bounds of data and control is performed).  Vocational
     teaching is much more hands-on and tools oriented.  At the
     academic level, you want your students to be able to take the
     knowledge and apply it in new and creative ways, not just learn
     a tool or a technique.

   - Many universities want to teach in the academic world the kind
     of knowledge that will give their students a definite edge when
     they go into private industry.  If potential employers (or
     graduate programs, etc.) look favorably on some "software security"
     experience, we will probably see more of it taught and/or
     integrated into existing coursework.

   - I found Corewars to be an interesting tool for starting to
     exercise that "defensive coding" muscle.  It gets students used
     to assuming that their program will be abused and misused,
     among other things :)

Greg.

----------------------------------------------------------------
Greg Beeley, President & Co-Founder     Greg.Beeley at LightSys.org
LightSys Technology Services, Inc.      http://www.LightSys.org/
----------------------------------------------------------------


From sasa at pheniscidae.tvnetwork.hu  Wed Nov  8 07:46:37 2006
From: sasa at pheniscidae.tvnetwork.hu (SZALAY Attila)
Date: Wed, 08 Nov 2006 13:46:37 +0100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing
	college	books]
In-Reply-To: <5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>
Message-ID: <1162989998.5096.19.camel@localhost>

Hi All!

On Mon, 2006-11-06 at 23:23 +1100, mikeiscool wrote:
> 
> Hold the phone ... What debugging problems? What _specific_ speed
> issues? I'd be really surprised if your project couldn't be resolved
> with java; what specific problems are you facing? What tests have you
> run/consider to show that java's supposed "speed issues" will give you
> trouble? If it's just xml processing I'd say efficient data structures
> are what you care about, so java can help you there.

1. Debug

When the program do something nasty or unwanted thing then in C I could
do a lot of thing to find what happened.

For example I could make the program dropping a core and analyze it at
home. This needed because the program used some places where I cannot go
into. And there were bugs in program which is definitely a race
condition what is hard to reproduce. So it's not enough to write the
steps to reproduce the bug.

And I'm not sure that I can get the complete state of the program (and
just the program) so I can detect where is the problem, even when the
problem is in the compiler. I think it's more harder in java language.

2. Speed

Yes, it's maybe an outdated information but for example if there are a
java plugin in my web browser (not javascript, java, for example the
terminal plugin in some management page of AMD64 servers) or the
``famous'' Hungarian social web page iWIW, which was programmed in JAVA
and was slow like Hell.

And in this program there are some functions, which is in the corner of
usage about speed. (Sometimes in the other side :( ), So any speed
degradation is a PIA.


From sasa at pheniscidae.tvnetwork.hu  Wed Nov  8 10:59:04 2006
From: sasa at pheniscidae.tvnetwork.hu (SZALAY Attila)
Date: Wed, 08 Nov 2006 16:59:04 +0100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing
	college	books]
In-Reply-To: <200611061553.KAA17083@Sparkle.Rodents.Montreal.QC.CA>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
	<200611061553.KAA17083@Sparkle.Rodents.Montreal.QC.CA>
Message-ID: <1163001544.5096.46.camel@localhost>

On Mon, 2006-11-06 at 10:47 -0500, der Mouse wrote:
> 
> Perhaps I'm missing something.  Why do you have to abandon C?  You
> mention C++, C#, and Java, but no other languages; is there some reason
> you have to use a language that tries to be object-oriented?

To be object-oriented.

The truth is, that it's not my own project. And there are programmers
with more knowledge and ones with less. And the previous program (more
than 200k lines of code) is not maintainable because the hidden link
between ``objects'' and a lot of other thing. And I think, that I can
more easily control the architect of the code.

> Also, you have said nothing about what the tradeoffs involved are.
> Since this is sc-l, I assume security is involved; what does this code
> need to be secure against?

This code is part of a security application. And (I think) it's not
acceptable from a security application to contains security flaws. :)

(And not, I'm write here not because of security tradeoffs but because
there were the thread that nobody should use C++. (Because there are C#
and Java) and I were a little bit frightened that I chose wrong. (There
were other candidates and C# and Java was in, but we chose C++ instead
of this. And if this choices are equivalent in every other aspects, then
I want to choose the safest one. So because of this I asked that C++ is
really could be abandoned  (for me) or not.)



From michaelslists at gmail.com  Wed Nov  8 18:20:03 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Thu, 9 Nov 2006 10:20:03 +1100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <1162989998.5096.19.camel@localhost>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>
	<1162989998.5096.19.camel@localhost>
Message-ID: <5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>

On 11/8/06, SZALAY Attila <sasa at pheniscidae.tvnetwork.hu> wrote:
> Hi All!
>
> On Mon, 2006-11-06 at 23:23 +1100, mikeiscool wrote:
> >
> > Hold the phone ... What debugging problems? What _specific_ speed
> > issues? I'd be really surprised if your project couldn't be resolved
> > with java; what specific problems are you facing? What tests have you
> > run/consider to show that java's supposed "speed issues" will give you
> > trouble? If it's just xml processing I'd say efficient data structures
> > are what you care about, so java can help you there.
>
> 1. Debug
>
> When the program do something nasty or unwanted thing then in C I could
> do a lot of thing to find what happened.
>
> For example I could make the program dropping a core and analyze it at
> home. This needed because the program used some places where I cannot go
> into. And there were bugs in program which is definitely a race
> condition what is hard to reproduce. So it's not enough to write the
> steps to reproduce the bug.
>
> And I'm not sure that I can get the complete state of the program (and
> just the program) so I can detect where is the problem, even when the
> problem is in the compiler. I think it's more harder in java language.

You can definately get appropriate information via the stack trace
with java's exception handling. It's strange to see you say debugging
is _eaiser_ in c, typically people find it far easier in a managed
language :)


> 2. Speed
>
> Yes, it's maybe an outdated information but for example if there are a
> java plugin in my web browser (not javascript, java, for example the
> terminal plugin in some management page of AMD64 servers) or the
> ``famous'' Hungarian social web page iWIW, which was programmed in JAVA
> and was slow like Hell.

That's a java applet; please don't judge Java the language based on
applets; they are a really bad representation. Serverside java will be
very effective and useful; what sort of client are you writing? Is it
a website or a desktop app? Even if it's a desktop app, perhaps look
to azureus to see a good, well running app written in java for the
desktop. There are others.

-- mic

From sasa at pheniscidae.tvnetwork.hu  Thu Nov  9 06:20:00 2006
From: sasa at pheniscidae.tvnetwork.hu (SZALAY Attila)
Date: Thu, 09 Nov 2006 12:20:00 +0100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing
	college	books]
In-Reply-To: <5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>
	<1162989998.5096.19.camel@localhost>
	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>
Message-ID: <1163071200.5136.22.camel@localhost>

Hi All,

On Thu, 2006-11-09 at 10:20 +1100, mikeiscool wrote:
> 
> You can definately get appropriate information via the stack trace
> with java's exception handling. It's strange to see you say debugging
> is _eaiser_ in c, typically people find it far easier in a managed
> language :)

People are different. :))

I personally want to know what happens and I don't believe anything waht
I can't see. In C I can see the assembly code what (I hope) is a
deterministic thing. An interpreter is to big (to me) to think about it
as a deterministic thing. And yes, with ``normal'' bugs a managed
language could give me more possibility to find the place of the
problem. But I want to hope, that we don't commit normal bugs. :)

And with mysterious bugs, when you cannot reproduce it in a test system,
just the costumer some hundred miles away, I think that the stability of
the compiled code (and the core file what may created) is give more more
chance to find the right place.

> That's a java applet; please don't judge Java the language based on
> applets; they are a really bad representation. Serverside java will be
> very effective and useful; what sort of client are you writing? Is it
> a website or a desktop app? Even if it's a desktop app, perhaps look
> to azureus to see a good, well running app written in java for the
> desktop. There are others.

This is a desktop application in a client-server model.
I will look after azureus.



From ljknews at mac.com  Thu Nov  9 08:47:52 2006
From: ljknews at mac.com (ljknews)
Date: Thu, 9 Nov 2006 08:47:52 -0500
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing	college
 books]
In-Reply-To: <1163071200.5136.22.camel@localhost>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>
	<1162989998.5096.19.camel@localhost>
	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>
	<1163071200.5136.22.camel@localhost>
Message-ID: <p05200f04c178e0f79dc9@[192.168.1.254]>

At 12:20 PM +0100 11/9/06, SZALAY Attila wrote:

> And with mysterious bugs, when you cannot reproduce it in a test system,
> just the costumer some hundred miles away, I think that the stability of
> the compiled code (and the core file what may created) is give more more
> chance to find the right place.

I think you are mixing the issue of Java vs. C* with the issue of
interpreters vs compiled languages.

I heard a talk by the Sun Vice President of Technology (or some
such) some years ago extolling the virtues of Java.  He emphasized
that he was talking about the _language_ not the bytecode interpreter.
Sun felt (at the time) they got much better results with Java compiled
to machine code that with C* compiled to machine code.

Personally I don't care for any C*-style languages (including Java)
or byte-code-intepretation of languages I _do_ like, but I think it
is important that the discussion points separate the byte-code-engine
issues from those of the language itself.
-- 
Larry Kilgallen

From sasa at pheniscidae.tvnetwork.hu  Thu Nov  9 10:18:27 2006
From: sasa at pheniscidae.tvnetwork.hu (SZALAY Attila)
Date: Thu, 09 Nov 2006 16:18:27 +0100
Subject: [SC-L] Could I use Java or c#? [was: Re:
	re-writing	college	books]
In-Reply-To: <p05200f04c178e0f79dc9@[192.168.1.254]>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>
	<1162989998.5096.19.camel@localhost>
	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>
	<1163071200.5136.22.camel@localhost>
	<p05200f04c178e0f79dc9@[192.168.1.254]>
Message-ID: <1163085507.5136.36.camel@localhost>

Hi Al,

On Thu, 2006-11-09 at 08:47 -0500, ljknews wrote:
> 
> I think you are mixing the issue of Java vs. C* with the issue of
> interpreters vs compiled languages.

Yes, you are totally right. Sorry.

But I have not seen java or c# compiler.


From ljknews at mac.com  Thu Nov  9 10:18:49 2006
From: ljknews at mac.com (ljknews)
Date: Thu, 9 Nov 2006 10:18:49 -0500
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing	college
 books]
In-Reply-To: <1163085507.5136.36.camel@localhost>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>
	<1162989998.5096.19.camel@localhost>
	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>
	<1163071200.5136.22.camel@localhost>
	<p05200f04c178e0f79dc9@[192.168.1.254]>
	<1163085507.5136.36.camel@localhost>
Message-ID: <p05200f08c178f6c0bbe3@[192.168.1.254]>

At 4:18 PM +0100 11/9/06, SZALAY Attila wrote:
> Hi Al,
> 
> On Thu, 2006-11-09 at 08:47 -0500, ljknews wrote:
>> 
>> I think you are mixing the issue of Java vs. C* with the issue of
>> interpreters vs compiled languages.
> 
> Yes, you are totally right. Sorry.
> 
> But I have not seen java or c# compiler.

That will depend on what machine your use - I gather Sun has a Java
compiler at least for internal use.  But it is important to keep the
issues distinct so that when such a compiler does come along you can
know the reason for your prior decision.

I know that for one of the non-C languages I use there is a bytecode
version available, but I have no interest in that due to some of the
issues you have mentioned (and others).
-- 
Larry Kilgallen

From ge at linuxbox.org  Thu Nov  9 11:57:14 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Thu, 9 Nov 2006 10:57:14 -0600 (CST)
Subject: [SC-L] it's Y2K, no, it's 32 bit unix time, no, it's slashdot!
Message-ID: <Pine.LNX.4.21.0611091056300.30032-100000@linuxbox.org>

[X-posted to the funsec mailing list]

http://slashdot.org/articles/06/11/09/1534204.shtml

"2^24 comments ought to be enough for anyone" -- CmdrTaco

Slashdot Posting Bug Infuriates Haggard Admins 
Posted by CmdrTaco on Thursday November 09, @10:45AM
 from the this-is-never-good dept. 
 Slashdot.org 
 Last night we crossed over 16,777,216 comments in the database. The wise
amongst you might note that this number is 2^24, or in MySQLese an
unsigned mediumint. Unfortunately, like 5 years ago we changed our primary
keys in the comment table to unsigned int (32 bits, or 4.1 billion) but
neglected to change the index that handles parents. We're awesome! Fixing
is a simple ALTER TABLE statement... but on a table that is 16 million
rows long, our system will take 3+ hours to do it, during which time there
can be no posting. So today, we're disabling threading and will enable it
again later tonight. Sorry for the inconvenience. We shall flog ourselves
appropriately.


From crispin at novell.com  Thu Nov  9 17:48:39 2006
From: crispin at novell.com (Crispin Cowan)
Date: Thu, 09 Nov 2006 14:48:39 -0800
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing	college
	books]
In-Reply-To: <p05200f08c178f6c0bbe3@[192.168.1.254]>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>	<1162767566.2289.15.camel@sasa.home>	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>	<1162989998.5096.19.camel@localhost>	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>	<1163071200.5136.22.camel@localhost>	<p05200f04c178e0f79dc9@[192.168.1.254]>	<1163085507.5136.36.camel@localhost>
	<p05200f08c178f6c0bbe3@[192.168.1.254]>
Message-ID: <4553B047.403@novell.com>

ljknews wrote:
> At 4:18 PM +0100 11/9/06, SZALAY Attila wrote:
>   
>> Hi Al,
>>
>> On Thu, 2006-11-09 at 08:47 -0500, ljknews wrote:
>>     
>>> I think you are mixing the issue of Java vs. C* with the issue of
>>> interpreters vs compiled languages.
>>>       
I agree with LJ: language issues aside, I detest bytecode interpreters.
Prior to Java, resorting to compiling to byte code (e.g. P-code back in
the Pascal days) was considered a lame kludge because the language
developers couldn't be bothered to write a real compiler. The innovation
of Java was to describe this as a feature instead of a bug :)

>> Yes, you are totally right. Sorry.
>>
>> But I have not seen java or c# compiler.
>>     
For Java, look at JGC <http://www.gnu.org/software/gcc/java/>. "It can
compile Java source code to Java bytecode (class files) or directly to
native machine code, and Java bytecode to native machine code."

For C#, the Mono compiler says
<http://www.mono-project.com/using/relnotes/1.0-features.html> that it
has "an advanced native optimizing compiler is available for x86, SPARC,
s390 and PowerPC available in both an ahead-of-time (AOT) compilation
mode to reduce startup time and take advantage of all available
optimizations and a Just-in-Time (JIT) compilation mode."

However, having native code generation is different from having good
support in GDB for you generated code :) Without GDB support, the
debugger will treat your binaries like they were written in hand
assembly, and not be able to relate core dumps to high level constructs
like variables and lines of source code. Current status:

    * For Java: From the JGC FAQ <http://gcc.gnu.org/java/faq.html#1_6>,
      "gdb 5.0 <ftp://ftp.gnu.org/pub/gnu/gdb/> includes support for
      debugging gcj-compiled Java programs. For more information please
      read Java Debugging with gdb <http://gcc.gnu.org/java/gdb.html>."
    * For C#: There is a Mono Debugger
      <http://www.mono-project.com/Debugging>, but it is not complete.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From michaelslists at gmail.com  Thu Nov  9 18:53:02 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Fri, 10 Nov 2006 10:53:02 +1100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <1163071200.5136.22.camel@localhost>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>
	<1162989998.5096.19.camel@localhost>
	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>
	<1163071200.5136.22.camel@localhost>
Message-ID: <5e01c29a0611091553w74a5d3b7gdbbe71aa22737cc9@mail.gmail.com>

On 11/9/06, SZALAY Attila <sasa at pheniscidae.tvnetwork.hu> wrote:
> Hi All,
>
> On Thu, 2006-11-09 at 10:20 +1100, mikeiscool wrote:
> >
> > You can definately get appropriate information via the stack trace
> > with java's exception handling. It's strange to see you say debugging
> > is _eaiser_ in c, typically people find it far easier in a managed
> > language :)
>
> People are different. :))
>
> I personally want to know what happens and I don't believe anything waht
> I can't see. In C I can see the assembly code what (I hope) is a
> deterministic thing. An interpreter is to big (to me) to think about it
> as a deterministic thing. And yes, with ``normal'' bugs a managed
> language could give me more possibility to find the place of the
> problem. But I want to hope, that we don't commit normal bugs. :)

So basically you are expecting the only thing to go wrong on your
program is to be bugs in the VM? Be it java or c#? I find that really
strange. Sure, there have been bugs in the JVM/C# VM but just the same
there have been bugs in windows that will affect your c programs. I
really don't see that being a feasible/likely enough scenario to not
use one of these languages.


> And with mysterious bugs, when you cannot reproduce it in a test system,
> just the costumer some hundred miles away, I think that the stability of
> the compiled code (and the core file what may created) is give more more
> chance to find the right place.

Right exactly, and the fact that you have a stable VM instead of a
strange-patched-level of windows/linux os gives you a stable platform.

-- mic

From Ken at krvw.com  Fri Nov 10 15:31:59 2006
From: Ken at krvw.com (Kenneth Van Wyk)
Date: Fri, 10 Nov 2006 15:31:59 -0500
Subject: [SC-L] Top 10 Ajax Security Holes and Driving Factors
Message-ID: <9FA109D2-408E-44AC-8359-CD916E1D674E@krvw.com>

FYI, a friend forwarded me a link to this interesting article by  
Shreeraj Shah on Ajax holes, http://www.net-security.org/article.php? 
id=956

Since much has been written here on SC-L about relatively safe  
programming languages recently, I thought it might be interesting to  
look at the other end of the spectrum.  ;-)  Yes, I know Ajax is  
wildly popular these days.  10,000 lemmings can't be wrong, certainly!

Cheers,

Ken
-----
Kenneth R. van Wyk
Moderator, SC-L
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20061110/d46f8c57/attachment.bin 

From leichter_jerrold at emc.com  Fri Nov 10 18:12:54 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Fri, 10 Nov 2006 18:12:54 -0500 (EST)
Subject: [SC-L] Top 10 Ajax Security Holes and Driving Factors
In-Reply-To: <9FA109D2-408E-44AC-8359-CD916E1D674E@krvw.com>
References: <9FA109D2-408E-44AC-8359-CD916E1D674E@krvw.com>
Message-ID: <Pine.SOL.4.61.0611101746390.10678@mental>

| FYI, a friend forwarded me a link to this interesting article by
| Shreeraj Shah on Ajax holes,
|  http://www.net-security.org/article.php?id=956
|
| Since much has been written here on SC-L about relatively safe
| programming languages recently, I thought it might be interesting to
| look at the other end of the spectrum.  ;-) Yes, I know Ajax is wildly
| popular these days.  10,000 lemmings can't be wrong, certainly!
The problem isn't "safe" vs. "unsafe" languages, as such.  That confuses
levels of abstraction.

Not so many years ago, we defined "safe" as "can't affect what other
people are doing on the machine".  Hardware isolation of process
memory spaces solved that - at least once OS's began using it.  (There
are still Windows 98 boxes out there...)  That was safety at the
machine code level:  You could assume that your piece of machine code
would correctly implement the semantics given in the manuals, even
though others were running their own (possibly malicious) machine code
on the same machine.

Safe languages take the same notion up to the next higher level of
abstraction:  You can assume that your piece of source language text
will, when compiled and run, implement the semantics given in the
manuals, even in the presence of malicious code within your own
program.

The problem is that these are no longer very good safety properties.
The first is simply not strong enough:  It's fine for an isolated
program, but simply irrelevant when multiple programs share access
to files, network connections, and so on.  Other programs may not
be able to stomp on your memory, but when you can no longer trust
your own code as it comes of the disk because some virus got into
it, you're out of luck.  The second of these closes many loopholes,
but the world is no longer bounded by your machine:  It's the whole
Internet.

A look at bug lists shows that three kinds of problems represent
most of the reported issues (though they may not be the most
important by measures other than simple issue counts):  Ability
to access files outside of a supposedly bounded area; SQL injection;
cross-site scripting.  What do these have in common?  In all cases,
the cause of the bug is that the programmer is dealing with strings
as the fundamental datatype.  He misses ways to encode "../" because
of various games, or he misses ways to "escape" from the quoting
that's supposed to isolate code from data.  The accesses to the
strings themselves are completely safe.  The problem is, these
are not just strings:  These are complex objects with very complex
implicit semantics.  They are being programmed in machine language -
not even assembler.  If you move up a level of abstraction and
realize that today, the issue isn't how to write a code to
manipulate strings in the memory of one machine, it's how to
write a distributed program that runs across a bunch of machines
loosely coupled to each other on the Internet, you'll see that
you need an entirely different notion of a "safety property".

In some cases, the right primitives are completely clear.  The
"incorrect file path sanitization issue" was solved 30 years ago
on a variety of DEC OS's, which provided functions to pick apart
and reconstruct file specifications.  You almost never dealt with
a file spec as a string - oh, you kept it around as a string, but
you never did string operations on it.  To do this, file specs on
DEC OS's had a specified syntax, from which the full semantics
could be read.  We lost this with the Unix vision file specs
should be uniform - just a list of elements with no internal
structure, separated by slashes.  Because of this simplification,
there was no need to provide library routines to manipulate the
things - the basic string routines would do just fine.  This
became such an article of faith among programmers that newer
languages - which often have much more powerful string manipulation
primitives - saw no reason not to let programmers keep treating
file specs as strings.  And so the holes continue to be programmed
in.  (BTW, in the product I work on, we defined a single function
that ... picks apart and glues back together file specifications.
Programmers are specifically told *not* to try to manipulate specs
as strings - they should use the provided function.  Now, we only
have to get it right once.  (Of course, if we get it wrong, *all*
of our code is exposed.  But that's a tradeoff - I'd much rather
audit one reasonably small function that who knows how many lines
of code scattered here and there.)

In other cases, the general form of a solution is clear, but no
one has gotten the details right.  SQL injection is a non-issue if
you build statements with SQL parameters.  But that's a pain to
write, because the abstractions are so poor.  It's so much easier
to just generate the SQL query by pasting strings together - and
in scripting languages, so proud of their ability to express
string substitutions elegantly, it's often the only tool you
have.

If we're going to program the meta-computer that is the Web, we
need appropriate abstractions, and appropriate safe ways to
express them.  But we're so far behind the curve that we are
*still* arguing about yesterday's solved problems, safety down
at the individual program level.
							-- Jerry

From dcrocker at eschertech.com  Sat Nov 11 09:50:58 2006
From: dcrocker at eschertech.com (David Crocker)
Date: Sat, 11 Nov 2006 14:50:58 -0000
Subject: [SC-L] Could I use Java or c#? [was: Re:
	re-writingcollege	books]
In-Reply-To: <1163071200.5136.22.camel@localhost>
Message-ID: <046401c705a0$ccf84f40$cb00000a@escheradmin>

Hi Attila,

I wouldn't worry about not being able to see the assembly code while debugging.
In practice, there is less need for debugging Java or C# code than with C++. For
example, in C++, out-of-bounds array writes and incorrect type conversions can
give rise to bugs that are hard to find, because the effect may be felt some
time after the cause (e.g. the out-of-bounds array write corrupts some data). In
Java or C#, the runtime system catches this sort of bug immediately.

My company uses a code generator that can generate either C++ or Java. Although
the production version of the products we ship are built using C++ code, for
development and initial testing we generally use the Java code because bugs are
caught much earlier.

The performance improvement you can get from using C++ rather than Java or C# is
significant only if the program uses really huge amounts of CPU time, in which
case you might be able to make a case that the hardware cost saving outweighs
the higher cost and time to develop in C++ rather than Java or C#. Otherwise,
for application-level programming, Java or C# would generally be a more
productive choice.

Regards

David Crocker, Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com



-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On
Behalf Of SZALAY Attila
Sent: 09 November 2006 11:20
To: fake at mailinator.com
Cc: Secure Coding
Subject: Re: [SC-L] Could I use Java or c#? [was: Re: re-writingcollege books]


Hi All,

On Thu, 2006-11-09 at 10:20 +1100, mikeiscool wrote:
> 
> You can definately get appropriate information via the stack trace 
> with java's exception handling. It's strange to see you say debugging 
> is _eaiser_ in c, typically people find it far easier in a managed 
> language :)

People are different. :))

I personally want to know what happens and I don't believe anything waht I can't
see. In C I can see the assembly code what (I hope) is a deterministic thing. An
interpreter is to big (to me) to think about it as a deterministic thing. And
yes, with ``normal'' bugs a managed language could give me more possibility to
find the place of the problem. But I want to hope, that we don't commit normal
bugs. :)

And with mysterious bugs, when you cannot reproduce it in a test system, just
the costumer some hundred miles away, I think that the stability of the compiled
code (and the core file what may created) is give more more chance to find the
right place.

> That's a java applet; please don't judge Java the language based on 
> applets; they are a really bad representation. Serverside java will be 
> very effective and useful; what sort of client are you writing? Is it 
> a website or a desktop app? Even if it's a desktop app, perhaps look 
> to azureus to see a good, well running app written in java for the 
> desktop. There are others.

This is a desktop application in a client-server model.
I will look after azureus.


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php



From al.eridani at gmail.com  Sat Nov 11 19:39:39 2006
From: al.eridani at gmail.com (Al Eridani)
Date: Sat, 11 Nov 2006 16:39:39 -0800
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <4553B047.403@novell.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162767566.2289.15.camel@sasa.home>
	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>
	<1162989998.5096.19.camel@localhost>
	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>
	<1163071200.5136.22.camel@localhost>
	<p05200f04c178e0f79dc9@192.168.1.254>
	<1163085507.5136.36.camel@localhost>
	<p05200f08c178f6c0bbe3@192.168.1.254> <4553B047.403@novell.com>
Message-ID: <af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>

On 11/9/06, Crispin Cowan <crispin at novell.com> wrote:

> Prior to Java, resorting to compiling to byte code (e.g. P-code back in
> the Pascal days) was considered a lame kludge because the language
> developers couldn't be bothered to write a real compiler.

"Post-Java, resorting to compiling to machine code is considered a lame
kludge because the language developers cannot be bothered to write a
real optimizer."

From rcs at cert.org  Sun Nov 12 13:15:08 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Sun, 12 Nov 2006 13:15:08 -0500
Subject: [SC-L] Integral Security article/library
In-Reply-To: <af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>	<1162767566.2289.15.camel@sasa.home>	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>	<1162989998.5096.19.camel@localhost>	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>	<1163071200.5136.22.camel@localhost>	<p05200f04c178e0f79dc9@192.168.1.254>	<1163085507.5136.36.camel@localhost>	<p05200f08c178f6c0bbe3@192.168.1.254>
	<4553B047.403@novell.com>
	<af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
Message-ID: <455764AC.6090107@cert.org>


I forgot to post notice to this list about an article published by Dr.
Dobb's Journal on November 3rd that I wrote.  It is available on-line at
http://www.ddj.com/dept/security/193501774.

If you attempt to download the secure integer library that we developed
at CERT (http://www.cert.org/secure-coding/IntegerLib.zip), please use
Mozilla for the download.  There are reports that downloading with IE
causes the file to be corrupted, for reasons I don't currently understand.

rCs

From crispin at novell.com  Sun Nov 12 14:10:06 2006
From: crispin at novell.com (Crispin Cowan)
Date: Sun, 12 Nov 2006 11:10:06 -0800
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing
	college	books]
In-Reply-To: <af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>	<1162767566.2289.15.camel@sasa.home>	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>	<1162989998.5096.19.camel@localhost>	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>	<1163071200.5136.22.camel@localhost>	<p05200f04c178e0f79dc9@192.168.1.254>	<1163085507.5136.36.camel@localhost>	<p05200f08c178f6c0bbe3@192.168.1.254>
	<4553B047.403@novell.com>
	<af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
Message-ID: <4557718E.8080309@novell.com>

Al Eridani wrote:
> On 11/9/06, Crispin Cowan <crispin at novell.com> wrote:
>   
>> Prior to Java, resorting to compiling to byte code (e.g. P-code back in
>> the Pascal days) was considered a lame kludge because the language
>> developers couldn't be bothered to write a real compiler.
>>     
> "Post-Java, resorting to compiling to machine code is considered a lame
> kludge because the language developers cannot be bothered to write a
> real optimizer."
>   
I don't see what a bytecode intermediate stage has to do with "real
optimizer". Very sophisticated optimizers have existed for native code
generators for a very long time.

Bytecode interpreter performance blows goats, so I'm going to assume you
are referring to JIT. The first order effect of JIT is slow startup
time, but that's not an advantage either. So you must be claiming that
dynamic profiling (using runtime behavior to optimize code) is a major
advantage. It had better be, because the time constraints of doing your
optimization at JIT time restrict the amount of optimization you can do
vs. with a native code generator that gets to run off-line for as long
as it needs to.

But yes, dynamic profiling can be an advantage. However, its use is not
restricted to bytecode systems. VMware, the Transmeta CPU, and DEC's
FX86 (virtual machine emulation to run x86 code on Alpha CPUs) use
dynamic translation to optimize performance. It works, in that those
systems all do gain performance from dynamic profiling, but note also
the reputation that they all have for speed: poor.

And then there's "write once, run anywhere." Yeah ... right. I've run
Java applets, and Javascript applets, and the latter are vastly superior
for performance, and worse, all too often the Java applets are not "run
anywhere", they only run on very specific JVM implementations.

There's the nice property that bytecode can be type safe. I really like
that. But the bytecode checker is slow; do people really run it
habitually? More important; is type safety a valuable property for
*untrusted code* that you are going to have to sandbox anyway?

So I give up; what is it that's so great about bytecode? It looks a
*lot* like the Emperor is not wearing clothes to me.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From michaelslists at gmail.com  Sun Nov 12 20:07:42 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Mon, 13 Nov 2006 12:07:42 +1100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <4557718E.8080309@novell.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<1162989998.5096.19.camel@localhost>
	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>
	<1163071200.5136.22.camel@localhost>
	<p05200f04c178e0f79dc9@192.168.1.254>
	<1163085507.5136.36.camel@localhost>
	<p05200f08c178f6c0bbe3@192.168.1.254> <4553B047.403@novell.com>
	<af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
	<4557718E.8080309@novell.com>
Message-ID: <5e01c29a0611121707t72aab150s9f0f6fc57cf08f9f@mail.gmail.com>

> And then there's "write once, run anywhere." Yeah ... right. I've run
> Java applets, and Javascript applets, and the latter are vastly superior
> for performance, and worse, all too often the Java applets are not "run
> anywhere", they only run on very specific JVM implementations.

You really can't judge java based on java applets; they are a really
poor front, for reasons I assume you are aware.


> There's the nice property that bytecode can be type safe. I really like
> that. But the bytecode checker is slow; do people really run it
> habitually? More important; is type safety a valuable property for
> *untrusted code* that you are going to have to sandbox anyway?

I believe major application servers run with -verify, which is
appropriate and useful for them.


> So I give up; what is it that's so great about bytecode? It looks a
> *lot* like the Emperor is not wearing clothes to me.

I think you just want to see him that way ;)


> Crispin

-- mic

From everhart at gce.com  Sun Nov 12 21:54:32 2006
From: everhart at gce.com (Glenn and Mary Everhart)
Date: Sun, 12 Nov 2006 21:54:32 -0500
Subject: [SC-L] Could I use Java or c#? [was: Re:
	re-writing	college	books]
In-Reply-To: <4557718E.8080309@novell.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>	<1162767566.2289.15.camel@sasa.home>	<5e01c29a0611060423q793a994bg337e3f9d1d1042f@mail.gmail.com>	<1162989998.5096.19.camel@localhost>	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>	<1163071200.5136.22.camel@localhost>	<p05200f04c178e0f79dc9@192.168.1.254>	<1163085507.5136.36.camel@localhost>	<p05200f08c178f6c0bbe3@192.168.1.254>	<4553B047.403@novell.com>	<af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
	<4557718E.8080309@novell.com>
Message-ID: <4557DE68.9030408@gce.com>

Crispin Cowan wrote:
> Al Eridani wrote:
>> On 11/9/06, Crispin Cowan <crispin at novell.com> wrote:
>>   
>>> Prior to Java, resorting to compiling to byte code (e.g. P-code back in
>>> the Pascal days) was considered a lame kludge because the language
>>> developers couldn't be bothered to write a real compiler.
>>>     
>> "Post-Java, resorting to compiling to machine code is considered a lame
>> kludge because the language developers cannot be bothered to write a
>> real optimizer."
>>   
> I don't see what a bytecode intermediate stage has to do with "real
> optimizer". Very sophisticated optimizers have existed for native code
> generators for a very long time.
> 
> Bytecode interpreter performance blows goats, so I'm going to assume you
> are referring to JIT. The first order effect of JIT is slow startup
> time, but that's not an advantage either. So you must be claiming that
> dynamic profiling (using runtime behavior to optimize code) is a major
> advantage. It had better be, because the time constraints of doing your
> optimization at JIT time restrict the amount of optimization you can do
> vs. with a native code generator that gets to run off-line for as long
> as it needs to.
> 
> But yes, dynamic profiling can be an advantage. However, its use is not
> restricted to bytecode systems. VMware, the Transmeta CPU, and DEC's
> FX86 (virtual machine emulation to run x86 code on Alpha CPUs) use
> dynamic translation to optimize performance. It works, in that those
> systems all do gain performance from dynamic profiling, but note also
> the reputation that they all have for speed: poor.
> 
> And then there's "write once, run anywhere." Yeah ... right. I've run
> Java applets, and Javascript applets, and the latter are vastly superior
> for performance, and worse, all too often the Java applets are not "run
> anywhere", they only run on very specific JVM implementations.
> 
> There's the nice property that bytecode can be type safe. I really like
> that. But the bytecode checker is slow; do people really run it
> habitually? More important; is type safety a valuable property for
> *untrusted code* that you are going to have to sandbox anyway?
> 
> So I give up; what is it that's so great about bytecode? It looks a
> *lot* like the Emperor is not wearing clothes to me.
> 
> Crispin
> 
Considering that on VMS, due to the use everywhere of a single calling
standard and a linker that can understand things, you can link any language
with any other language and get things to run. A single app with some pieces
in Fortran, C, Pascal, BASIC, and assembly language, all in one program, is
perfectly feasible. I have worked with such. Everything's compiled, everything
compiles to optimised machine code, and there is no interpreter needed.

So why does anyone consider that multilingual development requires some kind
of interpretive runtime? The old P-system was current a LONG time ago now, 
always did have speed problems (and took down some pretty decent apps with that 
ship in its day because they couldn't run as fast as native code ones).

If there is some construct that NEEDS to be interpreted to gain something, it 
can be justified on that basis. Using interpretive runtimes just to link 
languages, or just to achieve portability when source code portability runs 
pretty well thanks, seems wasteful to me.

Anybody know why .net uses a runtime of the sort it does?

Glenn Everhart



From michaelslists at gmail.com  Mon Nov 13 06:31:50 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Mon, 13 Nov 2006 22:31:50 +1100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <4557DE68.9030408@gce.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>
	<1163071200.5136.22.camel@localhost>
	<p05200f04c178e0f79dc9@192.168.1.254>
	<1163085507.5136.36.camel@localhost>
	<p05200f08c178f6c0bbe3@192.168.1.254> <4553B047.403@novell.com>
	<af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
	<4557718E.8080309@novell.com> <4557DE68.9030408@gce.com>
Message-ID: <5e01c29a0611130331n56f00542me53ab14e62424f69@mail.gmail.com>

On 11/13/06, Glenn and Mary Everhart <everhart at gce.com> wrote:
> Crispin Cowan wrote:
> > Al Eridani wrote:
> >> On 11/9/06, Crispin Cowan <crispin at novell.com> wrote:
> >>
> >>> Prior to Java, resorting to compiling to byte code (e.g. P-code back in
> >>> the Pascal days) was considered a lame kludge because the language
> >>> developers couldn't be bothered to write a real compiler.
> >>>
> >> "Post-Java, resorting to compiling to machine code is considered a lame
> >> kludge because the language developers cannot be bothered to write a
> >> real optimizer."
> >>
> > I don't see what a bytecode intermediate stage has to do with "real
> > optimizer". Very sophisticated optimizers have existed for native code
> > generators for a very long time.
> >
> > Bytecode interpreter performance blows goats, so I'm going to assume you
> > are referring to JIT. The first order effect of JIT is slow startup
> > time, but that's not an advantage either. So you must be claiming that
> > dynamic profiling (using runtime behavior to optimize code) is a major
> > advantage. It had better be, because the time constraints of doing your
> > optimization at JIT time restrict the amount of optimization you can do
> > vs. with a native code generator that gets to run off-line for as long
> > as it needs to.
> >
> > But yes, dynamic profiling can be an advantage. However, its use is not
> > restricted to bytecode systems. VMware, the Transmeta CPU, and DEC's
> > FX86 (virtual machine emulation to run x86 code on Alpha CPUs) use
> > dynamic translation to optimize performance. It works, in that those
> > systems all do gain performance from dynamic profiling, but note also
> > the reputation that they all have for speed: poor.
> >
> > And then there's "write once, run anywhere." Yeah ... right. I've run
> > Java applets, and Javascript applets, and the latter are vastly superior
> > for performance, and worse, all too often the Java applets are not "run
> > anywhere", they only run on very specific JVM implementations.
> >
> > There's the nice property that bytecode can be type safe. I really like
> > that. But the bytecode checker is slow; do people really run it
> > habitually? More important; is type safety a valuable property for
> > *untrusted code* that you are going to have to sandbox anyway?
> >
> > So I give up; what is it that's so great about bytecode? It looks a
> > *lot* like the Emperor is not wearing clothes to me.
> >
> > Crispin
> >
> Considering that on VMS, due to the use everywhere of a single calling
> standard and a linker that can understand things, you can link any language
> with any other language and get things to run. A single app with some pieces
> in Fortran, C, Pascal, BASIC, and assembly language, all in one program, is
> perfectly feasible. I have worked with such. Everything's compiled, everything
> compiles to optimised machine code, and there is no interpreter needed.
>
> So why does anyone consider that multilingual development requires some kind
> of interpretive runtime? The old P-system was current a LONG time ago now,
> always did have speed problems (and took down some pretty decent apps with that
> ship in its day because they couldn't run as fast as native code ones).
>
> If there is some construct that NEEDS to be interpreted to gain something, it
> can be justified on that basis. Using interpretive runtimes just to link
> languages, or just to achieve portability when source code portability runs
> pretty well thanks, seems wasteful to me.

You think source code portability is good enough such that runtime
portability isn't really needed?


> Anybody know why .net uses a runtime of the sort it does?

Because .net is microsofts clone of Java, so they copied everything.


> Glenn Everhart

-- mic

From ljknews at mac.com  Mon Nov 13 08:54:13 2006
From: ljknews at mac.com (ljknews)
Date: Mon, 13 Nov 2006 08:54:13 -0500
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
 books]
In-Reply-To: <5e01c29a0611130331n56f00542me53ab14e62424f69@mail.gmail.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<5e01c29a0611081520j4f62e34fs11d0c7c2e435be6d@mail.gmail.com>
	<1163071200.5136.22.camel@localhost>
	<p05200f04c178e0f79dc9@192.168.1.254>
	<1163085507.5136.36.camel@localhost>
	<p05200f08c178f6c0bbe3@192.168.1.254> <4553B047.403@novell.com>
	<af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
	<4557718E.8080309@novell.com> <4557DE68.9030408@gce.com>
	<5e01c29a0611130331n56f00542me53ab14e62424f69@mail.gmail.com>
Message-ID: <p05200f0ec17e2934edb7@[192.168.1.254]>

At 10:31 PM +1100 11/13/06, mikeiscool wrote:
> On 11/13/06, Glenn and Mary Everhart <everhart at gce.com> wrote:

>> If there is some construct that NEEDS to be interpreted to gain something, it
>> can be justified on that basis. Using interpretive runtimes just to link
>> languages, or just to achieve portability when source code portability runs
>> pretty well thanks, seems wasteful to me.
> 
> You think source code portability is good enough such that runtime
> portability isn't really needed?

Anything beyond source code portability tempts the customer into use on
a platform where the developer has not tested.
-- 
Larry Kilgallen

From dwheeler at ida.org  Mon Nov 13 10:54:43 2006
From: dwheeler at ida.org (David A. Wheeler)
Date: Mon, 13 Nov 2006 10:54:43 -0500
Subject: [SC-L] p-code was created for PLATFORM PORTABILITY
References: <mailman.1.1163350801.90192.sc-l@securecoding.org>
Message-ID: <45589543.6060905@ida.org>

On 11/9/06, Crispin Cowan <crispin at novell.com> wrote:
>>Prior to Java, resorting to compiling to byte code (e.g. P-code back in
>>the Pascal days) was considered a lame kludge because the language
>>developers couldn't be bothered to write a real compiler.

I believe that is completely and totally false.
If you want to claim p-code itself was lame, fine.
But let's keep the history accurate.

The UCSD p-system was created in the late 1970's SPECIFICALLY for
PORTABILITY of executable code: You could ship p-code to any
machine, and it would run.  It was the 70s/80s way of getting
"Write once, run anywhere".  It was sold that way, too;
I remember ads pressing hard the notion that you could compile your
code once, and it'd run on many different systems. At the time
there LOTS of different and incompatible programming platforms:
Think 8080, Z80, 6502, 6800, DEC PDP-11, etc.  It had NOTHING to
do with not being willing to write a "real" compiler; the effort spent
to create the Pascal compiler (for example) probably far exceeded the
effort spent to implement the competing BASIC interpreters of the day.

Sure, you could achieve the same result as bytecode by shipping source code for
a portable language, and then have every machine recompile it. But:
* Many 8-bit computers of the time could RUN programs that would take
   dozens of hours to recompile from scratch, with constant disk-flipping
   to get different programs.  Users couldn't be expected
   to go through the agony of compiling just to run a program.
   The Apple ][, a common UCSD platform, often had 64KiB RAM and 1MHz clock rate
   (with many instructions taking 2-3 cycles), with 140K floppies.
* Many compiler developers wanted to sell compilers separately, not give
   them away.  They were willing to give away the runtime, though.
* People could redevelop JUST the runtime - not a new compiler - and run
   programs.  That made it MUCH easier to support new platforms.
* Many developers did not want to release source code to users.

More info:
* http://en.wikipedia.org/wiki/UCSD_p-System
* http://www.threedee.com/jcm/psystem/index.html

There's nothing wrong with the bytecode concept, e.g., Java class files
or .NET's equivalent.  If you want easy portability of executables,
it's STILL a reasonable approach. "Real" compilers tend to work the
same way anyway; they often have a front-end that generates one or more
intermediate forms that are easily viewed as a bytecode format, and then
compile the intermediate form(s) into a final form.
Whether or not having a standalone intermediate form is useful
depends on your goals.

--- David A. Wheeler



From bugtraq at cgisecurity.net  Mon Nov 13 13:22:30 2006
From: bugtraq at cgisecurity.net (bugtraq at cgisecurity.net)
Date: Mon, 13 Nov 2006 13:22:30 -0500 (EST)
Subject: [SC-L] Challenges faced by automated web application security
	assessment tools
Message-ID: <20061113182230.71400.qmail@cgisecurity.net>

I have released a new document 'Challenges faced by automated web application security assessment tools' that a few of you
may find interesting. 
 
URL:
http://www.cgisecurity.com/articles/scannerchallenges.shtml

Comments welcome. 
 
- Robert
http://www.cgisecurity.com/ Website Security news, and more!
http://www.cgisecurity.com/index.rss [RSS Feed]


From michaelslists at gmail.com  Mon Nov 13 15:30:48 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Tue, 14 Nov 2006 07:30:48 +1100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <p05200f0ec17e2934edb7@192.168.1.254>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<p05200f04c178e0f79dc9@192.168.1.254>
	<1163085507.5136.36.camel@localhost>
	<p05200f08c178f6c0bbe3@192.168.1.254> <4553B047.403@novell.com>
	<af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
	<4557718E.8080309@novell.com> <4557DE68.9030408@gce.com>
	<5e01c29a0611130331n56f00542me53ab14e62424f69@mail.gmail.com>
	<p05200f0ec17e2934edb7@192.168.1.254>
Message-ID: <5e01c29a0611131230j3dbe35fqa55267e81b9bd695@mail.gmail.com>

On 11/14/06, ljknews <ljknews at mac.com> wrote:
> At 10:31 PM +1100 11/13/06, mikeiscool wrote:
> > On 11/13/06, Glenn and Mary Everhart <everhart at gce.com> wrote:
>
> >> If there is some construct that NEEDS to be interpreted to gain something, it
> >> can be justified on that basis. Using interpretive runtimes just to link
> >> languages, or just to achieve portability when source code portability runs
> >> pretty well thanks, seems wasteful to me.
> >
> > You think source code portability is good enough such that runtime
> > portability isn't really needed?
>
> Anything beyond source code portability tempts the customer into use on
> a platform where the developer has not tested.

But it has been tested, because if it runs on that jvm it has been
tested for that JVM. a JVM version x on linux is the same as a JVM
version x on windows. That's the point. Now maybe they try running it
with a version x - 5 JVM, well fine, it may not work, but the response
would be: "duh".


> --
> Larry Kilgallen

-- mic

From leichter_jerrold at emc.com  Mon Nov 13 17:36:25 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Mon, 13 Nov 2006 17:36:25 -0500 (EST)
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
 books]
In-Reply-To: <5e01c29a0611131230j3dbe35fqa55267e81b9bd695@mail.gmail.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<p05200f04c178e0f79dc9@192.168.1.254>
	<1163085507.5136.36.camel@localhost>
	<p05200f08c178f6c0bbe3@192.168.1.254> <4553B047.403@novell.com>
	<af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
	<4557718E.8080309@novell.com> <4557DE68.9030408@gce.com>
	<5e01c29a0611130331n56f00542me53ab14e62424f69@mail.gmail.com>
	<p05200f0ec17e2934edb7@192.168.1.254>
	<5e01c29a0611131230j3dbe35fqa55267e81b9bd695@mail.gmail.com>
Message-ID: <Pine.SOL.4.61.0611131729420.10678@mental>

| > >> If there is some construct that NEEDS to be interpreted to gain
| > >> something, it can be justified on that basis. Using interpretive
| > >> runtimes just to link languages, or just to achieve portability
| > >> when source code portability runs pretty well thanks, seems
| > >> wasteful to me.
| > >
| > > You think source code portability is good enough such that runtime
| > > portability isn't really needed?
| >
| > Anything beyond source code portability tempts the customer into use
| > on a platform where the developer has not tested.
| 
| But it has been tested, because if it runs on that jvm it has been
| tested for that JVM. a JVM version x on linux is the same as a JVM
| version x on windows. That's the point. Now maybe they try running it
| with a version x - 5 JVM, well fine, it may not work, but the response
| would be: "duh".
That would be nice, wouldn't it?

Unfortunately, painful experience says it's not so.  At least not for
applications with non-trivial graphics components, in particular.

The joke we used to make was:  The promise of Java was "Write once,
run everywhere".  What we found was "Write once, debug everywhere".
Then came the Swing patches, which would cause old bugs to re-appear,
or suddenly make old workaround cause problems.  So the real message
of Java is "Write once, debug everywhere - forever".

Now, I'm exagerating for effect.  There are Java programs even quite
substantial Java programs, that run on multiple platforms with no
problems and no special porting efforts.  (Hell, there are C programs
with the same property!)  But there are also Java programs that
cause no end of porting grief.  It's certainly much more common to
see porting problems with C than with Java, but don't kid yourself:
Writing in Java doesn't guarantee you that there will be no platform
issues.
							-- Jerry

From michaelslists at gmail.com  Mon Nov 13 18:18:28 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Tue, 14 Nov 2006 10:18:28 +1100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <Pine.SOL.4.61.0611131729420.10678@mental>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<p05200f08c178f6c0bbe3@192.168.1.254> <4553B047.403@novell.com>
	<af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
	<4557718E.8080309@novell.com> <4557DE68.9030408@gce.com>
	<5e01c29a0611130331n56f00542me53ab14e62424f69@mail.gmail.com>
	<p05200f0ec17e2934edb7@192.168.1.254>
	<5e01c29a0611131230j3dbe35fqa55267e81b9bd695@mail.gmail.com>
	<Pine.SOL.4.61.0611131729420.10678@mental>
Message-ID: <5e01c29a0611131518k2d10204dj8be5bdfbe9663e44@mail.gmail.com>

On 11/14/06, Leichter, Jerry <leichter_jerrold at emc.com> wrote:
> | > >> If there is some construct that NEEDS to be interpreted to gain
> | > >> something, it can be justified on that basis. Using interpretive
> | > >> runtimes just to link languages, or just to achieve portability
> | > >> when source code portability runs pretty well thanks, seems
> | > >> wasteful to me.
> | > >
> | > > You think source code portability is good enough such that runtime
> | > > portability isn't really needed?
> | >
> | > Anything beyond source code portability tempts the customer into use
> | > on a platform where the developer has not tested.
> |
> | But it has been tested, because if it runs on that jvm it has been
> | tested for that JVM. a JVM version x on linux is the same as a JVM
> | version x on windows. That's the point. Now maybe they try running it
> | with a version x - 5 JVM, well fine, it may not work, but the response
> | would be: "duh".
> That would be nice, wouldn't it?
>
> Unfortunately, painful experience says it's not so.  At least not for
> applications with non-trivial graphics components, in particular.
>
> The joke we used to make was:  The promise of Java was "Write once,
> run everywhere".  What we found was "Write once, debug everywhere".
> Then came the Swing patches, which would cause old bugs to re-appear,
> or suddenly make old workaround cause problems.  So the real message
> of Java is "Write once, debug everywhere - forever".
>
> Now, I'm exagerating for effect.  There are Java programs even quite
> substantial Java programs, that run on multiple platforms with no
> problems and no special porting efforts.  (Hell, there are C programs
> with the same property!)  But there are also Java programs that
> cause no end of porting grief.  It's certainly much more common to
> see porting problems with C than with Java, but don't kid yourself:
> Writing in Java doesn't guarantee you that there will be no platform
> issues.

True, but that doesn't mean runtime portability isn't a good thing to aim for.

-- mic

From crispin at novell.com  Mon Nov 13 18:18:16 2006
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 13 Nov 2006 15:18:16 -0800
Subject: [SC-L] p-code was created for PLATFORM PORTABILITY
In-Reply-To: <45589543.6060905@ida.org>
References: <mailman.1.1163350801.90192.sc-l@securecoding.org>
	<45589543.6060905@ida.org>
Message-ID: <4558FD38.60702@novell.com>

David A. Wheeler wrote:
> On 11/9/06, Crispin Cowan <crispin at novell.com> wrote:
>   
>>> Prior to Java, resorting to compiling to byte code (e.g. P-code back in
>>> the Pascal days) was considered a lame kludge because the language
>>> developers couldn't be bothered to write a real compiler.
>>>       
> I believe that is completely and totally false.
> If you want to claim p-code itself was lame, fine.
> But let's keep the history accurate.
>
> The UCSD p-system was created in the late 1970's SPECIFICALLY for
> PORTABILITY of executable code: You could ship p-code to any
> machine, and it would run.
That is not inconsistent with my claim. The "P-code is a kludge to get
around writing a real compiler" is multiplied by the diversity of
architectures. Writing a native code generator is a cost you pay for
every supported architecture. So in more detail, P-code is a
performance-compromising kludge to avoid having to write a *lot* of real
code generators.

One major change between then and now is consolidation of CPUs. Then,
there really was a very broad diversity of CPU architectures (IBM
mainframe, IBM  AS/400, DEC VAX, PDP, DEC10, DEC20, Data General,
Apollo, HP, Xerox Sigma, x86, 68000, NS32K, etc. etc.) and they all more
or less mattered. It is *very* different today: the list of CPU
architectures that matter is much shorter (x86, x86-64, SPARC, POWER,
Itanium): only 4 instead of a baker's dozen, and of those 4, a single
one (x86) is a huge majority of the market.

Pascal was a student language, not often used for commercial
development, so money for Pascal development was scarce. In contrast,
real languages for commercial purposes (PL/1, COBOL, FORTRAN, C) all
used native code generators. P-code was precisely a
performance-compromising kludge to allow Pascal to be portable with less
development effort.

Of course, there was one big exception: Turbo Pascal. Arguably the most
popular Pascal implementation ever. And it used a native code generator.

The need for portability, and the cost of portability (how many
platforms you really have to port to) has dropped dramatically. Bytecode
should be going away, the the architectural mistake of Java and C#/.Net
are going to preserve it for some time to come :(

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From crispin at novell.com  Mon Nov 13 19:28:24 2006
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 13 Nov 2006 16:28:24 -0800
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing
	college	books]
In-Reply-To: <5e01c29a0611131518k2d10204dj8be5bdfbe9663e44@mail.gmail.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>	<p05200f08c178f6c0bbe3@192.168.1.254>
	<4553B047.403@novell.com>	<af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>	<4557718E.8080309@novell.com>
	<4557DE68.9030408@gce.com>	<5e01c29a0611130331n56f00542me53ab14e62424f69@mail.gmail.com>	<p05200f0ec17e2934edb7@192.168.1.254>	<5e01c29a0611131230j3dbe35fqa55267e81b9bd695@mail.gmail.com>	<Pine.SOL.4.61.0611131729420.10678@mental>
	<5e01c29a0611131518k2d10204dj8be5bdfbe9663e44@mail.gmail.com>
Message-ID: <45590DA8.90606@novell.com>

mikeiscool wrote:
> On 11/14/06, Leichter, Jerry <leichter_jerrold at emc.com> wrote:
>   
>> The joke we used to make was:  The promise of Java was "Write once,
>> run everywhere".  What we found was "Write once, debug everywhere".
>> Then came the Swing patches, which would cause old bugs to re-appear,
>> or suddenly make old workaround cause problems.  So the real message
>> of Java is "Write once, debug everywhere - forever".
>>
>> Now, I'm exagerating for effect.  There are Java programs even quite
>> substantial Java programs, that run on multiple platforms with no
>> problems and no special porting efforts.  (Hell, there are C programs
>> with the same property!)  But there are also Java programs that
>> cause no end of porting grief.  It's certainly much more common to
>> see porting problems with C than with Java, but don't kid yourself:
>> Writing in Java doesn't guarantee you that there will be no platform
>> issues.
>>     
> True, but that doesn't mean runtime portability isn't a good thing to aim for.
>   
It means that compromising performance to obtain runtime portability
that does not actually exist is a poor bargain.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From michaelslists at gmail.com  Mon Nov 13 19:34:18 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Tue, 14 Nov 2006 11:34:18 +1100
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <45590DA8.90606@novell.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<af0358420611111639l173cf81bn595016f14b3a7389@mail.gmail.com>
	<4557718E.8080309@novell.com> <4557DE68.9030408@gce.com>
	<5e01c29a0611130331n56f00542me53ab14e62424f69@mail.gmail.com>
	<p05200f0ec17e2934edb7@192.168.1.254>
	<5e01c29a0611131230j3dbe35fqa55267e81b9bd695@mail.gmail.com>
	<Pine.SOL.4.61.0611131729420.10678@mental>
	<5e01c29a0611131518k2d10204dj8be5bdfbe9663e44@mail.gmail.com>
	<45590DA8.90606@novell.com>
Message-ID: <5e01c29a0611131634i4d0dd625ibbfb731dedf5dbdb@mail.gmail.com>

On 11/14/06, Crispin Cowan <crispin at novell.com> wrote:
> mikeiscool wrote:
> > On 11/14/06, Leichter, Jerry <leichter_jerrold at emc.com> wrote:
> >
> >> The joke we used to make was:  The promise of Java was "Write once,
> >> run everywhere".  What we found was "Write once, debug everywhere".
> >> Then came the Swing patches, which would cause old bugs to re-appear,
> >> or suddenly make old workaround cause problems.  So the real message
> >> of Java is "Write once, debug everywhere - forever".
> >>
> >> Now, I'm exagerating for effect.  There are Java programs even quite
> >> substantial Java programs, that run on multiple platforms with no
> >> problems and no special porting efforts.  (Hell, there are C programs
> >> with the same property!)  But there are also Java programs that
> >> cause no end of porting grief.  It's certainly much more common to
> >> see porting problems with C than with Java, but don't kid yourself:
> >> Writing in Java doesn't guarantee you that there will be no platform
> >> issues.
> >>
> > True, but that doesn't mean runtime portability isn't a good thing to aim for.
> >
> It means that compromising performance to obtain runtime portability
> that does not actually exist is a poor bargain.

Runtime portability _does_ exist and the perfomance argument is old
and outdated now, there's the hotspot compiler that can beat the lazy
programmer (and aren't we all lazy?) and, although it's not java, you
may note Raymond Chens' optimisation challenge[1] with C# and C++ and
the results and discussion resulting.

And of course there are other reasons aside from just the runtime
portability to use Java; it's rich API, and so on.

-- mic
[1] http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

From robin at kallisti.net.nz  Mon Nov 13 20:01:29 2006
From: robin at kallisti.net.nz (Robin Sheat)
Date: Tue, 14 Nov 2006 14:01:29 +1300
Subject: [SC-L]
	=?iso-8859-1?q?Could_I_use_Java_or_c=23=3F_=5Bwas=3A_Re=3A?=
	=?iso-8859-1?q?_re-writing_college=09books=5D?=
In-Reply-To: <45590DA8.90606@novell.com>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>
	<5e01c29a0611131518k2d10204dj8be5bdfbe9663e44@mail.gmail.com>
	<45590DA8.90606@novell.com>
Message-ID: <200611141401.29898.robin@kallisti.net.nz>

On Tuesday 14 November 2006 13:28, Crispin Cowan wrote:
> It means that compromising performance 
It's not necessarily a given that runtime performance is compromised. There 
are situations where Java is faster than C (I've tested this on trivial 
things). I'm sure there are situations where the reverse is true, too. But as 
new releases of the JVM come out, all Java programs get faster.

Personally, I find the programmer time to be much better used in Java too. 
That is less of a factor of the VM side of things (although you can do some 
really quite nice debugging things by communicating with the JVM which 
helps), but it does tend to be a feature of things that predominantly run 
inside some non-native environment. I don't know if there's a causation 
effect going on there or not however.

> to obtain runtime portability 
> that does not actually exist is a poor bargain.
The runtime portability is not perfect. The problems mostly exist where it 
interfaces to the underlying system, and where that's done imperfectly. Not 
so long ago, I ported a commercial desktop Java-based application from 
Windows to Linux. It took me a day or two to go through all the references to 
File, and make sure they were constructed properly (i.e. replace instances 
of '\\' with a properly constructed File) and do some testing, and that was 
all. It then looked and behaved just the same as it did on Windows, and 
objects could happily be de/reserialised across the different platforms (and 
on different architectures if necessary).

However, you never have to deal with different word sizes, different endians, 
and so on. It removes as many of the gotchas as is feasible. Back on the 
security topic for a moment, you also gain things like sandboxing that works 
in a way that isn't reliant on the capabilities of the hardware.

Robin.

From gem at cigital.com  Mon Nov 13 20:35:53 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 13 Nov 2006 20:35:53 -0500
Subject: [SC-L] p-code was created for PLATFORM PORTABILITY
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E7C7C@va-mail.cigital.com>

I am all for the "mistake" of type safety and reference monitors.   All we need to do is build a real machine that runs byte code and/or clr instead of interpreting it.  I agree that jit'ing os a kludge...

I await the scheme-os which bill joy and I figure may emerge from africa sometime in the next decade.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com


 -----Original Message-----
From: 	Crispin Cowan [mailto:crispin at novell.com]
Sent:	Mon Nov 13 18:32:53 2006
To:	David A. Wheeler
Cc:	sc-l at securecoding.org
Subject:	Re: [SC-L] p-code was created for PLATFORM PORTABILITY

David A. Wheeler wrote:
> On 11/9/06, Crispin Cowan <crispin at novell.com> wrote:
>   
>>> Prior to Java, resorting to compiling to byte code (e.g. P-code back in
>>> the Pascal days) was considered a lame kludge because the language
>>> developers couldn't be bothered to write a real compiler.
>>>       
> I believe that is completely and totally false.
> If you want to claim p-code itself was lame, fine.
> But let's keep the history accurate.
>
> The UCSD p-system was created in the late 1970's SPECIFICALLY for
> PORTABILITY of executable code: You could ship p-code to any
> machine, and it would run.
That is not inconsistent with my claim. The "P-code is a kludge to get
around writing a real compiler" is multiplied by the diversity of
architectures. Writing a native code generator is a cost you pay for
every supported architecture. So in more detail, P-code is a
performance-compromising kludge to avoid having to write a *lot* of real
code generators.

One major change between then and now is consolidation of CPUs. Then,
there really was a very broad diversity of CPU architectures (IBM
mainframe, IBM  AS/400, DEC VAX, PDP, DEC10, DEC20, Data General,
Apollo, HP, Xerox Sigma, x86, 68000, NS32K, etc. etc.) and they all more
or less mattered. It is *very* different today: the list of CPU
architectures that matter is much shorter (x86, x86-64, SPARC, POWER,
Itanium): only 4 instead of a baker's dozen, and of those 4, a single
one (x86) is a huge majority of the market.

Pascal was a student language, not often used for commercial
development, so money for Pascal development was scarce. In contrast,
real languages for commercial purposes (PL/1, COBOL, FORTRAN, C) all
used native code generators. P-code was precisely a
performance-compromising kludge to allow Pascal to be portable with less
development effort.

Of course, there was one big exception: Turbo Pascal. Arguably the most
popular Pascal implementation ever. And it used a native code generator.

The need for portability, and the cost of portability (how many
platforms you really have to port to) has dropped dramatically. Bytecode
should be going away, the the architectural mistake of Java and C#/.Net
are going to preserve it for some time to come :(

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From crispin at novell.com  Tue Nov 14 06:48:24 2006
From: crispin at novell.com (Crispin Cowan)
Date: Tue, 14 Nov 2006 03:48:24 -0800
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writing college
	books]
In-Reply-To: <200611141401.29898.robin@kallisti.net.nz>
References: <00f001c700d4$67dcf870$cb00000a@escheradmin>	<5e01c29a0611131518k2d10204dj8be5bdfbe9663e44@mail.gmail.com>	<45590DA8.90606@novell.com>
	<200611141401.29898.robin@kallisti.net.nz>
Message-ID: <4559AD08.2070600@novell.com>

Robin Sheat wrote:
> On Tuesday 14 November 2006 13:28, Crispin Cowan wrote:
>   
>> It means that compromising performance 
>>     
> It's not necessarily a given that runtime performance is compromised. There 
> are situations where Java is faster than C (I've tested this on trivial 
> things).
Here it is "bytecode vs. native code generator", not "Java vs. C."
Remember, I advocated Java over C++ in the first place :)

Even in the bytecode vs. native code generator contest, there are cases
where each will win:

    * bytecode interpreters always lose; they really are just a kludge
    * JIT can win if it uses dynamic profiling effectively and the
      application is amenable to optimization for decisions that need to
      be evaluated at runtime
    * JIT can be a lose because of the latency required to JIT the code
      instead of compiling ahead of time

So:

    * JIT will win if your application is long-lived, and has a lot of
      dynamic decision making to do, e.g. making a lot of deep object
      member function calls that are virtual, or just a lot of
      conditional branches.
    * Native code will win if your applications are just short-lived,
      because they are dispatched as children from a dispatcher process
          o You pat the JIT cost each time it starts
          o The short lifespan doesn't give dynamic profiling time to do
            its thing


> Personally, I find the programmer time to be much better used in Java too. 
>   
No argument from me. I advocate Java, I just want a native code
generator instead of bytecode.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes


From Kevin.Wall at qwest.com  Tue Nov 14 21:18:34 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Tue, 14 Nov 2006 20:18:34 -0600
Subject: [SC-L] Could I use Java or c#? [was: Re:
	re-writingcollege	books]
In-Reply-To: <45590DA8.90606@novell.com>
Message-ID: <CF8B26B8B49184429CB084616B00193003C76B24@itomae2km05.AD.QINTRA.COM>

Crispin Cowan wrote...
> mikeiscool wrote:
...
> > True, but that doesn't mean runtime portability isn't a 
> good thing to aim for.
> > 
> It means that compromising performance to obtain runtime portability
> that does not actually exist is a poor bargain.

To me, the bigger loss than performance is all the functionality that
you give up to gain the portability. E.g., because several system calls
(in a functional/feature way, not the _specific_ sys calls) aren't
portable
across all OSes that Sun wanted to support with Java, they dumbed down
the list to the lowest common demoninator. That makes a Java
inappropriate
for a lot of system-level programming tasks. Simple example: There's no
way
in pure Java that I can lock a process in memory. Wrt this list, that
has
a lot of security ramifications especially on shared processors. Sure
makes
hiding secrets a lot harder.

Plea to moderator: Ken: While I find this debate interesting, I think it
	has little to do with secure coding. I'm trying to bring it back
on
	track a bit, but I fear that it is too far gone. My vote is to
kill
	this topic unless someone has a major objection or we can make
it
	relevant to security. Thanks.

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
"It is practically impossible to teach good programming to students
 that have had a prior exposure to BASIC: as potential programmers
 they are mentally mutilated beyond hope of regeneration"
    - Edsger Dijkstra, How do we tell truths that matter?
      http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.


From ljknews at mac.com  Wed Nov 15 08:54:39 2006
From: ljknews at mac.com (ljknews)
Date: Wed, 15 Nov 2006 08:54:39 -0500
Subject: [SC-L] Could I use Java or c#? [was: Re:	re-writingcollege
 books]
In-Reply-To: <CF8B26B8B49184429CB084616B00193003C76B24@itomae2km05.AD.QINTRA.COM>
References: <CF8B26B8B49184429CB084616B00193003C76B24@itomae2km05.AD.QINTRA.COM>
Message-ID: <p05200f00c180cbe7fc7c@[192.168.1.254]>

At 8:18 PM -0600 11/14/06, Wall, Kevin wrote:

> That makes a Java
> inappropriate
> for a lot of system-level programming tasks. Simple example: There's no
> way
> in pure Java that I can lock a process in memory. Wrt this list, that
> has
> a lot of security ramifications especially on shared processors. Sure
> makes
> hiding secrets a lot harder.

Please explain that issue.

Is there some multiuser operating system that does not clear memory before
retasking it for another  process ?
-- 
Larry Kilgallen

From petesh at indigo.ie  Wed Nov 15 10:44:30 2006
From: petesh at indigo.ie (Pete Shanahan)
Date: Wed, 15 Nov 2006 15:44:30 +0000
Subject: [SC-L] Could I use Java or c#? [was: Re:	re-writingcollege
	books]
In-Reply-To: <p05200f00c180cbe7fc7c@[192.168.1.254]>
References: <CF8B26B8B49184429CB084616B00193003C76B24@itomae2km05.AD.QINTRA.COM>
	<p05200f00c180cbe7fc7c@[192.168.1.254]>
Message-ID: <455B35DE.90105@indigo.ie>

ljknews wrote:
> At 8:18 PM -0600 11/14/06, Wall, Kevin wrote:
> 
>> That makes a Java
>> inappropriate
>> for a lot of system-level programming tasks. Simple example: There's no
>> way
>> in pure Java that I can lock a process in memory. Wrt this list, that
>> has
>> a lot of security ramifications especially on shared processors. Sure
>> makes
>> hiding secrets a lot harder.

It's an operating system feature where you can lock a chunk of the memory of a
process such that it is not swapped out at any time.

see the specs for mlock, madvise.

win32, I believe has an even more feature ridden facility for secure memory.

on the receipt of abnormal termination signals this memory can be cleared, thus
keeping the secret safe, so you could produce a process crash dump that is
sanitized for sending to a support group.

-- 
Pete	+353 (87) 412 9576 [M]
I'm gliding over a NUCLEAR WASTE DUMP near ATLANTA, Georgia!!


From mouse at Rodents.Montreal.QC.CA  Wed Nov 15 11:32:00 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Wed, 15 Nov 2006 11:32:00 -0500 (EST)
Subject: [SC-L] Could I use Java or c#? [was: Re:	re-writingcollege
 books]
In-Reply-To: <p05200f00c180cbe7fc7c@[192.168.1.254]>
References: <CF8B26B8B49184429CB084616B00193003C76B24@itomae2km05.AD.QINTRA.COM>
	<p05200f00c180cbe7fc7c@[192.168.1.254]>
Message-ID: <200611151634.LAA26281@Sparkle.Rodents.Montreal.QC.CA>

>> Simple example: There's no way in pure Java that I can lock a
>> process in memory.  Wrt this list, that has a lot of security
>> ramifications especially on shared processors.  Sure makes hiding
>> secrets a lot harder.
> Please explain that issue.

It makes it impossible to keep things like crypto keys out of swap
space.  (Looking through swap space is a relatively well-known forensic
technique for finding things like crypto keys or passwords.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From Kevin.Wall at qwest.com  Wed Nov 15 11:55:42 2006
From: Kevin.Wall at qwest.com (Wall, Kevin)
Date: Wed, 15 Nov 2006 10:55:42 -0600
Subject: [SC-L] Could I use Java or c#? [was: Re:	re-writingcollegebooks]
In-Reply-To: <p05200f00c180cbe7fc7c@[192.168.1.254]>
Message-ID: <CF8B26B8B49184429CB084616B00193003C76B31@itomae2km05.AD.QINTRA.COM>

Larry Kilgallen wrote:
> At 8:18 PM -0600 11/14/06, Wall, Kevin wrote:
> 
> > That makes a Java inappropriate for a lot of
> > system-level programming tasks. Simple example: There's no
> > way in pure Java that I can lock a process in memory. Wrt this 
> > list, that has a lot of security ramifications especially on
> > shared processors. Sure makes hiding secrets a lot harder.
> 
> Please explain that issue.
> 
> Is there some multiuser operating system that does not clear 
> memory before retasking it for another  process ?

By shared processors, I didn't mean multi-CPU systems, but simple
computers used by multiple users. Sorry for the possible confusion.

I wasn't referring to the OS not clearing memory between use by
different processes. Instead consider a case where there's a secret
such as an encryption key, password, etc. in a chunk of memory that
has been paged out to a swap device (*nix) or pagefile.sys (Windows).
The process them terminates abnormally because of a signal, abrupt
power outage, etc. From a security POV, this is a bad thing since
now your secret is somewhere on the hard drive. If your computer
is physically secure and the OS is probably secured, this is a
relatively low risk, but it still may not be acceptable. In the
first case, where your Java process might abnormally terminated
via a signal, you may even end up with a process [core] dump.
In C/C++, I'd use something like mlock(2) or perhaps memcntl(2) and
lock the secret in physical memory. But there's no way to do this
using _pure_ Java.

Another example, perhaps easier to grasp and still security related.
Say you have a regular "console" application (i.e., doesn't bring up
it's own window; e.g., consider Windows console programs). Your
application wants to _prompt_ the user for a password. You would
like to disable echoing of the password to the console window.

In Java, you can do this if you use something like Swing or AWT,
etc., but there's no portable way that I've found using pure Java.
(Note: kludges such as continously overwriting each character as
it's input isn't secure. Consider case where user is running 'script'
or has xterm logging enabled, etc. Also, IMHO, calling an external
program, such as stty, from a Java program in order to disable and
re-enable character echo is also a kludge.)

In C/C++ or other language where I can call system calls directly,
this is easy to do (though not necessarily portable across different
OSes) via appropriate ioctl(2) call or various other means. (E.g., see
termio(7) for *nix systems.)

Overall, I find these types limitations with Java or C# more frustrating
than I do with the performance issues. If the performance issue is that
bad, it's usually my algorithm or data structures that need the tuning.
If all you need is to run machine code to get bettere performance,
then compile your Java with gjc or TowerJ or something similar. (Not
sure what options exist for C#.)

-kevin
---
Kevin W. Wall		Qwest Information Technology, Inc.
Kevin.Wall at qwest.com	Phone: 614.215.4788
"It is practically impossible to teach good programming to students
 that have had a prior exposure to BASIC: as potential programmers
 they are mentally mutilated beyond hope of regeneration"
    - Edsger Dijkstra, How do we tell truths that matter?
      http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.


From ljknews at mac.com  Wed Nov 15 12:23:47 2006
From: ljknews at mac.com (ljknews)
Date: Wed, 15 Nov 2006 12:23:47 -0500
Subject: [SC-L] Could I use Java or c#? [was: Re:	re-writingcollege
 books]
In-Reply-To: <455B35DE.90105@indigo.ie>
References: <CF8B26B8B49184429CB084616B00193003C76B24@itomae2km05.AD.QINTRA.COM>
	<p05200f00c180cbe7fc7c@[192.168.1.254]> <455B35DE.90105@indigo.ie>
Message-ID: <p05200f05c180f63ceec6@[192.168.1.254]>

At 3:44 PM +0000 11/15/06, Pete Shanahan wrote:
> ljknews wrote:
>> At 8:18 PM -0600 11/14/06, Wall, Kevin wrote:
>> 
>>> That makes a Java
>>> inappropriate
>>> for a lot of system-level programming tasks. Simple example: There's no
>>> way
>>> in pure Java that I can lock a process in memory. Wrt this list, that
>>> has
>>> a lot of security ramifications especially on shared processors. Sure
>>> makes
>>> hiding secrets a lot harder.

I did not write any of that.

> It's an operating system feature where you can lock a chunk of the memory of a
> process such that it is not swapped out at any time.
> 
> see the specs for mlock, madvise.

Those words mean nothing to me, but I presume you are talking about
either locking a page into memory:

	http://h71000.www7.hp.com/doc/83FINAL/4527/4527pro_081.html#jun_369

or locking a page into the working set:

	http://h71000.www7.hp.com/doc/83FINAL/4527/4527pro_082.html#jun_373

or preventing an entire process from being swapped out:

	http://h71000.www7.hp.com/doc/83FINAL/4527/4527pro_105.html#jun_526

None of those resolve the responsibility of the operating system to remove
residue from memory before transferring it to another user.  That is true
regardless of whether the process is running compiled code or a bytecode
engine (which is the real issue, not the implementation language).

> win32, I believe has an even more feature ridden facility for secure memory.
> 
> on the receipt of abnormal termination signals this memory can be cleared, thus
> keeping the secret safe, so you could produce a process crash dump that is
> sanitized for sending to a support group.

Yes, that is present in my environment as well.  Is the problem that the
bytecode engine used with languages like Java do not have a function to
exclude certain parts of memory from process crash dumps ?  That was not
clear from the prior statement.
-- 
Larry Kilgallen

From ljknews at mac.com  Wed Nov 15 12:33:50 2006
From: ljknews at mac.com (ljknews)
Date: Wed, 15 Nov 2006 12:33:50 -0500
Subject: [SC-L] Could I use Java or c#? [was: Re: re-writingcollegebooks]
In-Reply-To: <CF8B26B8B49184429CB084616B00193003C76B31@itomae2km05.AD.QINTRA.COM>
References: <CF8B26B8B49184429CB084616B00193003C76B31@itomae2km05.AD.QINTRA.COM>
Message-ID: <p05200f06c180fde6bba3@[192.168.1.254]>

At 10:55 AM -0600 11/15/06, Wall, Kevin wrote:
> Larry Kilgallen wrote:
>> At 8:18 PM -0600 11/14/06, Wall, Kevin wrote:
>> 
>> > That makes a Java inappropriate for a lot of
>> > system-level programming tasks. Simple example: There's no
>> > way in pure Java that I can lock a process in memory. Wrt this 
>> > list, that has a lot of security ramifications especially on
>> > shared processors. Sure makes hiding secrets a lot harder.
>> 
>> Please explain that issue.
>> 
>> Is there some multiuser operating system that does not clear 
>> memory before retasking it for another  process ?

> I wasn't referring to the OS not clearing memory between use by
> different processes. Instead consider a case where there's a secret
> such as an encryption key, password, etc. in a chunk of memory that
> has been paged out to a swap device (*nix) or pagefile.sys (Windows).
> The process them terminates abnormally because of a signal, abrupt
> power outage, etc. From a security POV, this is a bad thing since
> now your secret is somewhere on the hard drive.

But a cryptographic secret should not be in user-readable memory in the
first place, due to the risk of a trojan horse.  That belongs in OS memory
dedicated to the user but protected from them (i.e., inner mode) and at
that point the operating system can mark such memory as not being subject
to dumping.

The user might enter a password to _unlock_ that secret key, and some
trojan horse (or wiretap) might intercept that password and use it in
a malicious fashion, but the trojan horse cannot export the secret key
to another machine.  (By secret key, I mean the secret half of a public
key pair.)

> Overall, I find these types limitations with Java or C# more frustrating
> than I do with the performance issues.

A native compiler should have no problem calling any system service.
It would seem your objection is really to the bytecode engine version
of Java rather than to the language itself.
-- 
Larry Kilgallen

From mark.dowd at gmail.com  Thu Nov 16 18:00:04 2006
From: mark.dowd at gmail.com (Mark Dowd)
Date: Fri, 17 Nov 2006 10:00:04 +1100
Subject: [SC-L] The Art of Software Security Assessment (book release)
Message-ID: <816ef1ca0611161500t7d8ca675nbe49f7a84e13ceea@mail.gmail.com>

Hi,

Justin Schuh, John McDonald and I recently finished a book on software
security assessment. The three of us have put quite a bit of time and effort
into this project; essentially, it's a 1200 page book about how to audit
code to find vulnerabilities, based on our own experience. We present
high-level strategies for performing design and implementation reviews, but
the bulk of the content is dedicated to the technical details of
vulnerabilities and how they appear in real-world applications.

We've attempted to structure this book so it will prove useful for a variety
of audiences: developers assessing their own work (or the work of their
peers), consultants performing professional application security reviews, or
researchers looking to find the showstoppers that will appear in next
month's Patch Tuesday.

Here are some links:
http://www.amazon.com/gp/product/0321444426/
http://www.awprofessional.com/bookstore/product.asp?isbn=0321444426&rl=1

There's a sample chapter on the AW site that will give you a feel for what
the rest of the book is like. It's our chapter on C language issues, and it
has lots of examples of integer overflows and type conversion flaws, as well
as some fun C puzzles. The book will be hitting stores within the next few
days. Any thoughts/comments would be appreciated.

Enjoy!

Mark Dowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061117/9590bcac/attachment.html 

From ljknews at mac.com  Thu Nov 16 22:38:12 2006
From: ljknews at mac.com (ljknews)
Date: Thu, 16 Nov 2006 22:38:12 -0500
Subject: [SC-L] The Art of Software Security Assessment (book release)
In-Reply-To: <816ef1ca0611161500t7d8ca675nbe49f7a84e13ceea@mail.gmail.com>
References: <816ef1ca0611161500t7d8ca675nbe49f7a84e13ceea@mail.gmail.com>
Message-ID: <p05200f03c182def55663@[192.168.1.254]>

At 10:00 AM +1100 11/17/06, Mark Dowd wrote:

> There's a sample chapter on the AW site that will give you a feel for
>what the rest of the book is like. It's our chapter on C language issues,
>and it has lots of examples of integer overflows and type conversion
>flaws, as well as some fun C puzzles. The book will be hitting stores
>within the next few days. Any thoughts/comments would be appreciated.

What other languages have chapters ?
My particular interests are PL/I, Pascal and Ada.
-- 
Larry Kilgallen

From gem at cigital.com  Fri Nov 17 14:57:06 2006
From: gem at cigital.com (Gary McGraw)
Date: Fri, 17 Nov 2006 14:57:06 -0500
Subject: [SC-L] Silverbullet: Brian Chess
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FB938@va-mail.cigital.com>

Hi all,

Episode 8 of the silver bullet security podcast with yours truly is an
interview with Brian Chess, chief scientist of Fortify Software.  Brian
has been doing static analysis for years (his PhD work was in that area,
building a system called Eau Claire).  We spent most of this episode
discussing software security.  My bet is you'll find it relevant:

http://www.cigital.com/silverbullet/

As always, feedback on the podcast website is welcome.  Please tell
others about this free podcast if you think they'll like it.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ravid.work at gmail.com  Mon Nov 20 07:41:40 2006
From: ravid.work at gmail.com (Ravid L)
Date: Mon, 20 Nov 2006 14:41:40 +0200
Subject: [SC-L] Need some numbers about application security
Message-ID: <d1c41fae0611200441m22966a46gb53a310bd6e8b275@mail.gmail.com>

Hi everyone!

I am looking for some numbers about application security for a presentation.
I need data about how many organization experienced application based attack
recently?
What is the frequency of application based attacks?
How many application in the real Internet environment will need this kind of
protection?
What is the financial damage in real numbers for companies that has been a
target to such attacks? (damage in numbers and damage to stock for example).

If anyone has any data (from reliable sources) about this questions i will
be so grateful...

Thanks,
Ravid.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061120/e2848b6b/attachment.html 

From gunnar at arctecgroup.net  Mon Nov 20 09:02:39 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Mon, 20 Nov 2006 08:02:39 -0600
Subject: [SC-L] Need some numbers about application security
In-Reply-To: <d1c41fae0611200441m22966a46gb53a310bd6e8b275@mail.gmail.com>
Message-ID: <C187119F.5F42%gunnar@arctecgroup.net>

Hi Ravid,

You may want to review the MetriCon digest an related presentations

http://www.securitymetrics.org/content/attach/Welcome_blogentry_010806_1/met
ricon.notes.PDF

It has a lot of information about security and risk metrics, and there was
also a software security metrics track.

-gp


On 11/20/06 6:41 AM, "Ravid L" <ravid.work at gmail.com> wrote:

> Hi everyone!
>  
> I am looking for some numbers about application security for a presentation.
> I need data about how many organization experienced application based attack
> recently?
> What is the frequency of application based attacks?
> How many application in the real Internet environment will need this kind of
> protection?
> What is the financial damage in real numbers for companies that has been a
> target to such attacks? (damage in numbers and damage to stock for example).
>  
> If anyone has any data (from reliable sources) about this questions i will be
> so grateful...
>  
> Thanks,
> Ravid.
>  
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061120/41119315/attachment.html 

From ljknews at mac.com  Mon Nov 20 09:21:59 2006
From: ljknews at mac.com (ljknews)
Date: Mon, 20 Nov 2006 09:21:59 -0500
Subject: [SC-L] Need some numbers about application security
In-Reply-To: <d1c41fae0611200441m22966a46gb53a310bd6e8b275@mail.gmail.com>
References: <d1c41fae0611200441m22966a46gb53a310bd6e8b275@mail.gmail.com>
Message-ID: <p05200f0dc1876a5ed345@[192.168.1.254]>

At 2:41 PM +0200 11/20/06, Ravid L wrote:
> Hi everyone!
>
> I am looking for some numbers about application security for a presentation.
> I need data about how many organization experienced application based
>attack recently?
> What is the frequency of application based attacks?
> How many application in the real Internet environment will need this kind
>of protection?

Does this mean you want to ignore attacks unrelated to the Internet ?

> What is the financial damage in real numbers for companies that has been
>a target to such attacks? (damage in numbers and damage to stock for
>example).
>
> If anyone has any data (from reliable sources) about this questions i
>will be so grateful...

-- 
Larry Kilgallen

From ref66 at yahoo.com  Mon Nov 20 12:39:03 2006
From: ref66 at yahoo.com (Roman H.)
Date: Mon, 20 Nov 2006 09:39:03 -0800 (PST)
Subject: [SC-L] Need some numbers about application security
Message-ID: <20061120173903.59399.qmail@web32414.mail.mud.yahoo.com>

Ravid,

We would all love to get the data you are asking for.  However, most organizations aren't willing to publicize their security problems, so this kind of data is hard to obtain.  That said, there are nuggets of information here and there if you are willing to do some work.  A couple of things that come to mind:
 
Compilations of public vulnerabilities that probably represent only the tiniest fraction of the tip of the iceberg:
http://www.webappsec.org/projects/whid/
 http://www.us-cert.gov/cas/bulletins/SB2005.html

For actual dollar amounts, the Chipotle Prospectus discusses security breaches and regulatory compliance starting on page 27.  If you are looking for purely risk-based numbers rather then compliance issues, this won't help you.  Plus this is only a single source:
 http://www.chipotleexchange.com/Prospectus.pdf
 
Look around for more things like these and you can start compiling numbers.  Keep in mind that when you are done, you will have a collection of anecdotes rather than meaningful data.  For example, calculating the "frequency of application based attacks" would require that all application based attacks are actually reported to some central authority, which they are not.  With the recent "security breach notification" laws that are being passed in the United States, perhaps some useful data will begin to surface.  Even that will be limited to incidents in which personal data was lost or stolen, and will also include non-application-based attacks like laptop theft.  

You might also skim the first chapter of any of the recent books on application and software security, which generally address the questions you have.

Hope this helps, 
 Roman

----- Original Message ----
From: Ravid L <ravid.work at gmail.com>
To: SC-L at securecoding.org
Sent: Monday, November 20, 2006 4:41:40 AM
Subject: [SC-L] Need some numbers about application security

Hi everyone!
  
 I am looking for some numbers about application security for a presentation.
 I need data about how many organization experienced application based attack recently?
 What is the frequency of application based attacks?
 How many application in the real Internet environment will need this kind of protection?
 What is the financial damage in real numbers for companies that has been a target to such attacks? (damage in numbers and damage to stock for example).
  
 If anyone has any data (from reliable sources) about this questions i will be so grateful...
  
 Thanks,
 Ravid.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061120/06c03df0/attachment.html 

From mcgegick at ncsu.edu  Tue Nov 21 12:44:50 2006
From: mcgegick at ncsu.edu (Michael Gegick)
Date: Tue, 21 Nov 2006 12:44:50 -0500
Subject: [SC-L] Need some numbers about application security
In-Reply-To: <mailman.3.1164128401.52621.sc-l@securecoding.org>
Message-ID: <200611211744.kALHioFe001345@server-autogenerated.uni02mr.unity.ncsu.edu>

Try this:
http://www.gocsi.com/forms/fbi/csi_fbi_survey.jhtml (you'll need to fill out
the form)

michael

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of sc-l-request at securecoding.org
Sent: Tuesday, November 21, 2006 12:00 PM
To: sc-l at securecoding.org
Subject: SC-L Digest, Vol 2, Issue 202

Send SC-L mailing list submissions to
	sc-l at securecoding.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://krvw.com/mailman/listinfo/sc-l
or, via email, send a message with subject or body 'help' to
	sc-l-request at securecoding.org

You can reach the person managing the list at
	sc-l-owner at securecoding.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of SC-L digest..."


Today's Topics:

   1. Re: Need some numbers about application security (Roman H.)


----------------------------------------------------------------------

Message: 1
Date: Mon, 20 Nov 2006 09:39:03 -0800 (PST)
From: "Roman H." <ref66 at yahoo.com>
Subject: Re: [SC-L] Need some numbers about application security
To: Ravid L <ravid.work at gmail.com>, SC-L at securecoding.org
Message-ID: <20061120173903.59399.qmail at web32414.mail.mud.yahoo.com>
Content-Type: text/plain; charset="us-ascii"

Ravid,

We would all love to get the data you are asking for.  However, most
organizations aren't willing to publicize their security problems, so this
kind of data is hard to obtain.  That said, there are nuggets of information
here and there if you are willing to do some work.  A couple of things that
come to mind:
 
Compilations of public vulnerabilities that probably represent only the
tiniest fraction of the tip of the iceberg:
http://www.webappsec.org/projects/whid/
 http://www.us-cert.gov/cas/bulletins/SB2005.html

For actual dollar amounts, the Chipotle Prospectus discusses security
breaches and regulatory compliance starting on page 27.  If you are looking
for purely risk-based numbers rather then compliance issues, this won't help
you.  Plus this is only a single source:
 http://www.chipotleexchange.com/Prospectus.pdf
 
Look around for more things like these and you can start compiling numbers.
Keep in mind that when you are done, you will have a collection of anecdotes
rather than meaningful data.  For example, calculating the "frequency of
application based attacks" would require that all application based attacks
are actually reported to some central authority, which they are not.  With
the recent "security breach notification" laws that are being passed in the
United States, perhaps some useful data will begin to surface.  Even that
will be limited to incidents in which personal data was lost or stolen, and
will also include non-application-based attacks like laptop theft.  

You might also skim the first chapter of any of the recent books on
application and software security, which generally address the questions you
have.

Hope this helps, 
 Roman

----- Original Message ----
From: Ravid L <ravid.work at gmail.com>
To: SC-L at securecoding.org
Sent: Monday, November 20, 2006 4:41:40 AM
Subject: [SC-L] Need some numbers about application security

Hi everyone!
  
 I am looking for some numbers about application security for a
presentation.
 I need data about how many organization experienced application based
attack recently?
 What is the frequency of application based attacks?
 How many application in the real Internet environment will need this kind
of protection?
 What is the financial damage in real numbers for companies that has been a
target to such attacks? (damage in numbers and damage to stock for example).
  
 If anyone has any data (from reliable sources) about this questions i will
be so grateful...
  
 Thanks,
 Ravid.



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://krvw.com/pipermail/sc-l/attachments/20061120/06c03df0/attachment-0001
.html 

------------------------------

_______________________________________________
SC-L mailing list
SC-L at securecoding.org
http://krvw.com/mailman/listinfo/sc-l


End of SC-L Digest, Vol 2, Issue 202
************************************



From jjchryan at gwu.edu  Tue Nov 21 13:28:12 2006
From: jjchryan at gwu.edu (Julie Ryan)
Date: Tue, 21 Nov 2006 13:28:12 -0500
Subject: [SC-L] Need some numbers about application security
In-Reply-To: <200611211744.kALHioFe001345@server-autogenerated.uni02mr.unity.ncsu.edu>
References: <200611211744.kALHioFe001345@server-autogenerated.uni02mr.unity.ncsu.edu>
Message-ID: <e47dfd0e12089e6c7e8036006d53de16@gwu.edu>

If you want to rely on the CSI/FBI survey for numbers, you should  
definitely read the attrition.org page on statistics first.

http://attrition.org/errata/statistics/introduction.html


On Nov 21, 2006, at 12:44 PM, Michael Gegick wrote:

> Try this:
> http://www.gocsi.com/forms/fbi/csi_fbi_survey.jhtml (you'll need to  
> fill out
> the form)
>
> michael
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org  
> [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of sc-l-request at securecoding.org
> Sent: Tuesday, November 21, 2006 12:00 PM
> To: sc-l at securecoding.org
> Subject: SC-L Digest, Vol 2, Issue 202
>
> Send SC-L mailing list submissions to
> 	sc-l at securecoding.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://krvw.com/mailman/listinfo/sc-l
> or, via email, send a message with subject or body 'help' to
> 	sc-l-request at securecoding.org
>
> You can reach the person managing the list at
> 	sc-l-owner at securecoding.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SC-L digest..."
>
>
> Today's Topics:
>
>    1. Re: Need some numbers about application security (Roman H.)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 20 Nov 2006 09:39:03 -0800 (PST)
> From: "Roman H." <ref66 at yahoo.com>
> Subject: Re: [SC-L] Need some numbers about application security
> To: Ravid L <ravid.work at gmail.com>, SC-L at securecoding.org
> Message-ID: <20061120173903.59399.qmail at web32414.mail.mud.yahoo.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Ravid,
>
> We would all love to get the data you are asking for.  However, most
> organizations aren't willing to publicize their security problems, so  
> this
> kind of data is hard to obtain.  That said, there are nuggets of  
> information
> here and there if you are willing to do some work.  A couple of things  
> that
> come to mind:
>
> Compilations of public vulnerabilities that probably represent only the
> tiniest fraction of the tip of the iceberg:
> http://www.webappsec.org/projects/whid/
>  http://www.us-cert.gov/cas/bulletins/SB2005.html
>
> For actual dollar amounts, the Chipotle Prospectus discusses security
> breaches and regulatory compliance starting on page 27.  If you are  
> looking
> for purely risk-based numbers rather then compliance issues, this  
> won't help
> you.  Plus this is only a single source:
>  http://www.chipotleexchange.com/Prospectus.pdf
>
> Look around for more things like these and you can start compiling  
> numbers.
> Keep in mind that when you are done, you will have a collection of  
> anecdotes
> rather than meaningful data.  For example, calculating the "frequency  
> of
> application based attacks" would require that all application based  
> attacks
> are actually reported to some central authority, which they are not.   
> With
> the recent "security breach notification" laws that are being passed  
> in the
> United States, perhaps some useful data will begin to surface.  Even  
> that
> will be limited to incidents in which personal data was lost or  
> stolen, and
> will also include non-application-based attacks like laptop theft.
>
> You might also skim the first chapter of any of the recent books on
> application and software security, which generally address the  
> questions you
> have.
>
> Hope this helps,
>  Roman
>
> ----- Original Message ----
> From: Ravid L <ravid.work at gmail.com>
> To: SC-L at securecoding.org
> Sent: Monday, November 20, 2006 4:41:40 AM
> Subject: [SC-L] Need some numbers about application security
>
> Hi everyone!
>
>  I am looking for some numbers about application security for a
> presentation.
>  I need data about how many organization experienced application based
> attack recently?
>  What is the frequency of application based attacks?
>  How many application in the real Internet environment will need this  
> kind
> of protection?
>  What is the financial damage in real numbers for companies that has  
> been a
> target to such attacks? (damage in numbers and damage to stock for  
> example).
>
>  If anyone has any data (from reliable sources) about this questions i  
> will
> be so grateful...
>
>  Thanks,
>  Ravid.
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://krvw.com/pipermail/sc-l/attachments/20061120/06c03df0/ 
> attachment-0001
> .html
>
> ------------------------------
>
> _______________________________________________
> SC-L mailing list
> SC-L at securecoding.org
> http://krvw.com/mailman/listinfo/sc-l
>
>
> End of SC-L Digest, Vol 2, Issue 202
> ************************************
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -  
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at -  
> http://www.securecoding.org/list/charter.php
>
Julie J.C.H. Ryan, D.Sc.
Assistant Professor
Engineering Management and System Engineering
George Washington University

An NSA certified Center of Academic Excellence in Information Assurance  
Education

http://www.seas.gwu.edu/~jjchryan/
http://www.seas.gwu.edu/~infosec/

From gunnar at arctecgroup.net  Thu Nov 30 17:47:54 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Thu, 30 Nov 2006 16:47:54 -0600
Subject: [SC-L] Ross Anderson reviews Building Security In
Message-ID: <C194BBBA.633E%gunnar@arctecgroup.net>

Found on the web -- local boy makes good:

Review by Ross Anderson

to appear in Jan/Feb 2007 IEEE S&P Magazine
Gary McGraw, "Software Security - Building Security In"
Addison-Wesley, 2006
`We must first agree that software security is not security software',
writes Gary McGraw in the first chapter of his new book. Spot on! Things
break because software is just about everywhere, and we rely on it for just
about everything; we had software before the Internet, but we couldn't have
the Internet until there was software. Software has bugs, and some of them
cause vulnerabilities. Trying to compensate for bugs by adding a layer of
special security software can only get you so far - often not far enough.

But how can you train programmers to stop writing vulnerabilities? The
explosion of the software industry over the past fifty years has created far
more programming jobs than there are CS graduates to fill them. Most of my
teenage contemporaries who studied science subjects - any science, from
physics to geology to physiology - ended up writing code of one kind or
another. Having run out of trainable people in the USA and Europe, we now
have hundreds of thousands of folks in the developing world writing code.
And as processors and communications spread from office equipment to
domestic appliances and eventually to most inedible things costing more than
a few dollars, the software quality gap can only get worse. So people who
understand security and know how to write have an opportunity - one might
even say a duty - to try to close this gap.
...

http://www.swsec.com/press/ra-ieeesp.php

-gp



From gem at cigital.com  Mon Dec 11 14:02:24 2006
From: gem at cigital.com (Gary McGraw)
Date: Mon, 11 Dec 2006 14:02:24 -0500
Subject: [SC-L] Software security != security software
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FBC00@va-mail.cigital.com>

Hi all,

The furvor over Microsoft's entry into the security software business is
confusing some people about their software security designs.   Or maybe
people who know better are trying to confuse the market??!  Note word
order.

I wrote about this in my latest darkreading column that you can find
here:
http://www.darkreading.com/document.asp?doc_id=112402

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From brian at fortifysoftware.com  Tue Dec 12 01:09:59 2006
From: brian at fortifysoftware.com (Brian Chess)
Date: Mon, 11 Dec 2006 22:09:59 -0800
Subject: [SC-L] Java Open Review Project
Message-ID: <C1A387B7.21FB8%brian@fortifysoftware.com>

Hello all, I'm pleased to announce that we've just launched the Java Open
Review Project (http://opensource.fortifysoftware.com).  We're reviewing
open source Java code all the way from Tomcat down to PetStore looking for
bugs and security vulnerabilities.  We're using two static analysis tools to
do the heavy lifting: FindBugs and Fortify SCA.  We can use plenty of human
eyes to help sort through the results.  We're also soliciting ideas for
which projects we should be reviewing next.  Please help!

Brian


From Greenarrow1 at msn.com  Tue Dec 12 01:18:05 2006
From: Greenarrow1 at msn.com (Greenarrow 1)
Date: Mon, 11 Dec 2006 22:18:05 -0800
Subject: [SC-L] Software security != security software
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FBC00@va-mail.cigital.com>
Message-ID: <BAY124-DAV106F6299222E5E52030B9CF6D70@phx.gbl>

Hi Gem,

Microsoft still suffers from the lack of properly correcting flaws within 
their operating systems in a mannerly fashion.  Myself, I feel until 
Microsoft proves to me that they can safe guard the system I would never 
allow them to secure my computer(s).  I have tested Vista, Window Defender 
and other security programs MS has created, and while Vista I applaud the 
lock down of the kernel I have found Defender to be lacking in security. 
Creating a program like this must protect against all malware and not what 
Microsoft decides is malware, ie, some third party partner programs which 
garner information which would be considered spy ware are not blocked by 
Defender.  This is one illustration of guarding the henhouse.  I could name 
a few more but that still would not deter the inevitable.

Regards,
George
Greenarrow1
InNetInvestigations-Forensic


----- Original Message ----- 
From: "Gary McGraw" <gem at cigital.com>
To: <SC-L at securecoding.org>
Sent: Monday, December 11, 2006 11:02 AM
Subject: [SC-L] Software security != security software


> Hi all,
>
> The furvor over Microsoft's entry into the security software business is
> confusing some people about their software security designs.   Or maybe
> people who know better are trying to confuse the market??!  Note word
> order.
>
> I wrote about this in my latest darkreading column that you can find
> here:
> http://www.darkreading.com/document.asp?doc_id=112402
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> book www.swsec.com
>
>
>
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive 
> this
> message by the intended recipient), any disclosure, copying, distribution 
> or
> use of the contents of the information is prohibited.  If you have 
> received
> this electronic message transmission in error, please contact the sender 
> by
> reply email and delete all copies of this message.  Cigital, Inc. accepts 
> no
> responsibility for any loss or damage resulting directly or indirectly 
> from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - 
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> 

From sbradcpa at pacbell.net  Mon Dec 11 22:40:03 2006
From: sbradcpa at pacbell.net (Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP])
Date: Mon, 11 Dec 2006 19:40:03 -0800
Subject: [SC-L] Software security != security software
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FBC00@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FBC00@va-mail.cigital.com>
Message-ID: <457E2493.3070002@pacbell.net>

"The problem is that security software vendors including Symantec and 
McAfee have used the very same techniques for years in the name of good. 
Antivirus software and personal firewall software pulls all sorts of 
fancy kernel-interpositioning kung fu."

..... and for every good..... there is also a bad:  
http://www.securiteam.com/windowsntfocus/6Z0032AH5U.html 

"The reason we need security software like antivirus tools and personal 
firewalls is that OSes have traditionally suffered from all kinds of 
security problems (both bugs and flaws)."
Hmmm let's see lately we've had these bugs http://secunia.com/vendor/6/  
and these http://secunia.com/vendor/70/  and these 
http://secunia.com/vendor/56/ and these ones 
http://secunia.com/vendor/54/ and these http://secunia.com/vendor/51/ 
and..... well you get the idea that it's not just OS's that have 
security flaws.. sometimes it's the very things we buy to make us secure 
that have their own issues


"Microsoft may be too responsible to manipulate its security defect 
density intentionally in order to create demand for its security 
software, but the fact that this is even possible is a great worry. This 
is like allowing the fox to design and build the henhouse, not just 
guard it."

Microsoft "rogue" developer says in development meeting of Forefront 
products:  "Say... I think I'm going to manipulate security defects just 
'cause I want to drive more sales of Forefront products...yeah that's 
the ticket... "

Okay so with tinfoil in place... that's going to need a "Security defect 
Density Product Manager" (Microsoft doesn't do anything without a PM or 
two you know), at least an entire WagEd (Waggoner Edstrom [however you 
spell that] marketing division to do a 'spin' and marketing blitz on how 
Forefront needs to be the software of choice... numerous conference 
calls  and committee meetings, not to mention a User Interface testing 
... etc etc...

You know this reminds me of when my Dad would respond to the folks that 
said that the Government did "fill in the blank" such as kill Kennedy, 
pretend to go to the moon but really did not, and other assorted odds 
and ends.

1.  From the outside it appears that they are not that well organized to 
pull something like this off (it took them 5 years to get Vista out the 
door... do you honestly think that Microsoft can selectively code a 
"security defect density" without causing some other issue?  That the 
Forefront team gets together with the Vista team and the watercooler and 
swaps and coordinates places to put defects in?

2.  Do you honestly think there wouldn't be some honest whistle blower 
somewhere that wouldn't be on the Fox News Channel or Oprah in a heartbeat?

Is this possible?  When our own government put forth evidence of 
"weapons of mass destruction" and later it comes out there wasn't 
any...that showcases that people talk and the truth gets out. Maybe I 
just grew up too much in the era of Watergate and believe too strongly 
in the power of free speech... but it's a little hard for me to think 
that someone like MiniMicrosoft wouldn't be screaming their head off if 
someone in Microsoft even thought of such a thing. 

Someone would blog.  Trust me on that one.

Quite frankly, I've been burned a few times with those antivirus 
companies that have guarded my henhouse and have flagged things as 
viruses they shouldn't, and have brought my network to it's knees.  So 
even when they were protecting me, I've lost confidence in them too.

Right now my biggest concern is that we still aren't caring enough about 
software security at all.

Susan... who's convinced that the bad guys have gotten over these petty 
turf wars a long time ago and are way more cooperating/coordinating that 
the good guys are.

Gary McGraw wrote:
> Hi all,
>
> The furvor over Microsoft's entry into the security software business is
> confusing some people about their software security designs.   Or maybe
> people who know better are trying to confuse the market??!  Note word
> order.
>
> I wrote about this in my latest darkreading column that you can find
> here:
> http://www.darkreading.com/document.asp?doc_id=112402
>
> gem
>
> company www.cigital.com
> podcast www.cigital.com/silverbullet
> book www.swsec.com 
>
>
>
> ----------------------------------------------------------------------------
> This electronic message transmission contains information that may be
> confidential or privileged.  The information contained herein is intended
> solely for the recipient and use by any other party is not authorized.  If
> you are not the intended recipient (or otherwise authorized to receive this
> message by the intended recipient), any disclosure, copying, distribution or
> use of the contents of the information is prohibited.  If you have received
> this electronic message transmission in error, please contact the sender by
> reply email and delete all copies of this message.  Cigital, Inc. accepts no
> responsibility for any loss or damage resulting directly or indirectly from
> the use of this email or its contents.
> Thank You.
> ----------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
>   

-- 
Letting your vendors set your risk analysis these days?  
http://www.threatcode.com

If you are a SBSer and you don't subscribe to the SBS Blog... man ... I will hunt you down...
http://blogs.technet.com/sbs


From gem at cigital.com  Thu Dec 14 11:39:23 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 14 Dec 2006 11:39:23 -0500
Subject: [SC-L] Silverbullet: Bruce Schneier
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7FBC3A@va-mail.cigital.com>

Hi all,

The 9th silver bullet podcast eposide went up last night.  This time my
victim, er I mean my guest, is Bruce Schneier.  I think you'll all agree
that Bruce is our most visible spokesmodel when it comes to security,
and thankfully he understands the importance of software security.  We
spend a little time talking directly about software security during the
interview.

Download the episode here: http://www.cigital.com/silverbullet/ (and
subscribe via RSS, itunes, etc).

It's hard to believe that this is the 9th podcast in the Silver Bullet
Security Podcast series!  Please help me spread the word by passing the
link on to your friends.

Thanks.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From Ken at krvw.com  Thu Dec 14 14:00:25 2006
From: Ken at krvw.com (Kenneth Van Wyk)
Date: Thu, 14 Dec 2006 14:00:25 -0500
Subject: [SC-L] heise Security - News - Security specialist leaves PHP
	security team
Message-ID: <B4C5B137-09E6-4C07-9348-746412550435@KRvW.com>

I guess this falls in to the "you can lead a horse to water, but you  
can't make him drink" category:

http://www.heise-security.co.uk/news/82500

A member of the PHP security team has left in apparent disgust over  
the team's security practices.

I doubt that anyone here on SC-L is surprised by the article, but PHP  
remains quite popular, and it seems sad to see it losing some vital  
and much-needed security support.

Well, there's always AJAX, I suppose.  ;-\

Cheers,

Ken

P.S. Hey, SC-L is 3 years old this month!
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061214/efc4f0b9/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20061214/efc4f0b9/attachment.bin 

From dinis at ddplus.net  Thu Dec 14 19:27:56 2006
From: dinis at ddplus.net (Dinis Cruz)
Date: Fri, 15 Dec 2006 00:27:56 +0000
Subject: [SC-L] heise Security - News - Security specialist leaves PHP
	security team
In-Reply-To: <B4C5B137-09E6-4C07-9348-746412550435@KRvW.com>
References: <B4C5B137-09E6-4C07-9348-746412550435@KRvW.com>
Message-ID: <701fd6b60612141627s17fe9d16padd367d56a78b087@mail.gmail.com>

This is a very good example of the security problems that Open Source
projects have.

Open Source projects need to have strong Secure Development Lifecicles for
their software. And here they could do worse than learn from Microsoft's
efforts.

One of the projects that I really want to do at the OWASP is an SDL project
which should be used on OWASP projects (39 at last count (
http://www.owasp.org/index.php/Category:OWASP_Project)) in order to ensure
that OWASP tools are as secure as they can be.

We need to make our software more secure and trustworthy and a solid SDL is
a good (first) step. Eventually we will need to move to the Sandboxing
model, but I won't start the thread again :)

Dinis Cruz
Chief OWASP Evangelist
http://www.owasp.org

On 12/14/06, Kenneth Van Wyk <Ken at krvw.com> wrote:
>
> I guess this falls in to the "you can lead a horse to water, but you can't
> make him drink" category:
>
> http://www.heise-security.co.uk/news/82500
> A member of the PHP security team has left in apparent disgust over the
> team's security practices.
> I doubt that anyone here on SC-L is surprised by the article, but PHP
> remains quite popular, and it seems sad to see it losing some vital and
> much-needed security support.
>
> Well, there's always AJAX, I suppose.  ;-\
>
> Cheers,
>
> Ken
>
> P.S. Hey, SC-L is 3 years old this month!
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
>
>
>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
>
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
>
> List charter available at - http://www.securecoding.org/list/charter.php
>
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> _______________________________________________
>
>
>
>


--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061215/2f8a9e9d/attachment.html 

From ken at krvw.com  Tue Dec 19 10:33:28 2006
From: ken at krvw.com (Kenneth Van Wyk)
Date: Tue, 19 Dec 2006 10:33:28 -0500
Subject: [SC-L] PHP security under scrutiny
Message-ID: <FAC0E05F-E7B7-48A8-AACD-99E14B298773@krvw.com>

Interesting article about PHP security:

http://www.securityfocus.com/news/11430

Among other things, NIST's vul database shows, "Web applications  
written in PHP likely account for 43 percent of the security issues  
found so far in 2006, up from 29 percent in 2005."

Happy reading...

Cheers,

Ken
-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061219/1e9487d1/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://krvw.com/pipermail/sc-l/attachments/20061219/1e9487d1/attachment.bin 

From jms at bughunter.ca  Tue Dec 19 10:50:40 2006
From: jms at bughunter.ca (J. M. Seitz)
Date: Tue, 19 Dec 2006 07:50:40 -0800
Subject: [SC-L] PHP security under scrutiny
In-Reply-To: <FAC0E05F-E7B7-48A8-AACD-99E14B298773@krvw.com>
Message-ID: <004601c72385$71595190$8119fea9@jseitz>

Yeah I can personally attest to that, after spending a few months on the
OSVDB as a mangler and developer, I quickly realized that the bevy of
vulnerabilities we worked on everyday were primarily PHP based. Now granted
setting "register_globals off"  (which essentially prevents a user from
overwriting variables in a page) will mitigate most of these vulnerabilities
it was still alarming to see. Not to mention the fact that most people are
spending their time looking for XSS or SQL injections, whereas the upward
trend looked more like remote file inclusion vulnerabilities which are more
dangerous to the host machine, rather than an unsuspecting end-user.
 
Maybe someone can remind me of who said "Once the bad guy is running code on
your machine, it's no longer your machine." :)
 
JS
 
 


  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Kenneth Van Wyk
Sent: Tuesday, December 19, 2006 7:33 AM
To: Secure Coding
Subject: [SC-L] PHP security under scrutiny


Interesting article about PHP security:

http://www.securityfocus.com/news/11430 

Among other things, NIST's vul database shows, "Web applications written in
PHP likely account for 43 percent of the security issues found so far in
2006, up from 29 percent in 2005." 


Happy reading...


Cheers,


Ken

-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061219/87513b9a/attachment.html 

From James.McGovern at thehartford.com  Thu Dec 21 10:30:50 2006
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 21 Dec 2006 10:30:50 -0500
Subject: [SC-L] Compilers
In-Reply-To: <FAC0E05F-E7B7-48A8-AACD-99E14B298773@krvw.com>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>

I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061221/8d808bd3/attachment.html 

From gunnar at arctecgroup.net  Thu Dec 21 10:55:12 2006
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Thu, 21 Dec 2006 09:55:12 -0600
Subject: [SC-L] Compilers
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>
Message-ID: <C1B00A80.6AB8%gunnar@arctecgroup.net>

Sure it should be built into the language, and I assume it will be
eventually. Heck it only took 30 or 40 years for people to force developers
to use Try...Catch blocks.

-gp


On 12/21/06 9:30 AM, "McGovern, James F (HTSC, IT)"
<James.McGovern at thehartford.com> wrote:

> I have been noodling the problem space of secure coding after attending a
> wonderful class taught by Ken Van Wyk. I have been casually checking out
> Fortify, Ounce Labs, etc and have a thought that this stuff should really be
> part of the compiler and not a standalone product. Understanding that folks do
> start companies to make up deficiencies in what large vendors ignore, how far
> off base in my thinking am I?
> 
> 
> *************************************************************************
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *************************************************************************
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> _______________________________________________


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061221/a756b883/attachment.html 

From gem at cigital.com  Thu Dec 21 10:56:20 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 21 Dec 2006 10:56:20 -0500
Subject: [SC-L] Compilers
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E81B0@va-mail.cigital.com>

Integration of some of the static techniques found in tools like fortify into compilers does make sense.  However, not all of the kinds of things should be put in the compiler (how many coders do you know that use the -Wall??!).  So one use case for some of the knowledge would be compiler enforcement.  Note that compilers are notorious for computing and then throwing out many things statically.  They are designed to get their transformation business done, not to do real analysis.

Still other things should be worked directly into the languages.  C and C++ suck for security.

And most importantly, rules tailored directly to the enterprise situation at hand require a platform like fortify.  At cigital we have developed sets of custom rules for customers with great results.  This cuts down false positives and makes it possible to enforce guidelines and standards that make sense for the business (think J2EE here).

Bottom line...we need it all, and we need it now.

gem

P.S. Ken's course was co-designed by me and is based on my book.  You might pick up a copy.

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 

 -----Original Message-----
From: 	McGovern, James F (HTSC, IT) [mailto:James.McGovern at thehartford.com]
Sent:	Thu Dec 21 10:47:50 2006
To:	Secure Coding
Subject:	[SC-L] Compilers

I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************





----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From ljknews at mac.com  Thu Dec 21 11:19:14 2006
From: ljknews at mac.com (ljknews)
Date: Thu, 21 Dec 2006 11:19:14 -0500
Subject: [SC-L] Compilers
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>
Message-ID: <p05200f12c1b06389fb82@[192.168.1.254]>

At 10:30 AM -0500 12/21/06, McGovern, James F (HTSC, IT) wrote:
> Content-class: urn:content-classes:message
> Content-Type: multipart/alternative;
> 	boundary="----_=_NextPart_001_01C72514.FE7A042C"
>
> I have been noodling the problem space of secure coding after attending a
>wonderful class taught by Ken Van Wyk. I have been casually checking out
>Fortify, Ounce Labs, etc and have a thought that this stuff should really
>be part of the compiler and not a standalone product. Understanding that
>folks do start companies to make up deficiencies in what large vendors
>ignore, how far off base in my thinking am I?

Isn't the whole basis of Spark a matter of adding proof statements in
the comments ?  I don't think the general compiler marketplace would
go for that built-in to compilers.  After all:

	1. The Praxis implementation can be used with multiple compilers

	2. The compiler market is so immature that some people are still
	   using C, C++ and Java.

But for the high-integrity market, Spark seems to fit the bill.
-- 
Larry Kilgallen

From James.McGovern at thehartford.com  Thu Dec 21 11:38:28 2006
From: James.McGovern at thehartford.com (McGovern, James F (HTSC, IT))
Date: Thu, 21 Dec 2006 11:38:28 -0500
Subject: [SC-L] Compilers
In-Reply-To: <C1B00A80.6AB8%gunnar@arctecgroup.net>
Message-ID: <773F863A6009244B87E6E866AFC7DB46019CA18A@AD1HFDEXC309.ad1.prod>

Gunnar, I think the problem space of secure coding will never be pervasively solved if it relies on the licensing of tools for every developer on the planet. Folks have been conditioned to not pay for developer level tools and now use Eclipse, etc. Putting it only in the hands of a few folks may be useful or it may be futile, only time will tell.
 
In terms of your analogy of using try/catch blocks, I would say the following: First, languages within the last ten years require you to use them and they are not optional for the developer to skip in many situations. Second, compilers actually check try/catch blocks which says that compilers can and do play an important role which the community should leverage vs avoid.
 
This does beg another question of should the community be helping the folks who design languages to build in security-oriented constructs that we can leverage instead of waiting for after-the-fact find-it utilities?
 
 

-----Original Message-----
From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
Sent: Thursday, December 21, 2006 10:55 AM
To: McGovern, James F (HTSC, IT); Secure Mailing List
Subject: Re: [SC-L] Compilers


Sure it should be built into the language, and I assume it will be eventually. Heck it only took 30 or 40 years for people to force developers to use Try...Catch blocks. 

-gp


On 12/21/06 9:30 AM, "McGovern, James F (HTSC, IT)" <James.McGovern at thehartford.com> wrote:



I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************


  _____  

_______________________________________________
Secure Coding mailing list (SC-L) SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC ( http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061221/8df67565/attachment.html 

From jms at bughunter.ca  Thu Dec 21 12:27:21 2006
From: jms at bughunter.ca (J. M. Seitz)
Date: Thu, 21 Dec 2006 09:27:21 -0800
Subject: [SC-L] Compilers
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA18A@AD1HFDEXC309.ad1.prod>
Message-ID: <00a401c72525$46c03dd0$8119fea9@jseitz>

Once again though, using security-oriented constructs requires that the
developers use them and use them correctly. Static code analysis tools (like
Fortify) aren't after-the-fact, they should be inline during the process of
development. If you can create a development process and environment of
security you have won 90% of the war and the Klingons shall subside when the
mighty static analysis ship sails into port. Now relying solely on a black
box testing suite or a fuzzer, is just validating the code your attackers
already know is weak. Don't get me wrong, I incorporate some fuzzing in our
testing process, but this is only because its repeatable, automated, and it
enables me to spend some time answering emails to interesting mailing lists.
:)
 
</2cents>
 
JS

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of McGovern, James F (HTSC, IT)
Sent: Thursday, December 21, 2006 8:38 AM
To: Gunnar Peterson
Cc: Secure Mailing List
Subject: Re: [SC-L] Compilers


Gunnar, I think the problem space of secure coding will never be pervasively
solved if it relies on the licensing of tools for every developer on the
planet. Folks have been conditioned to not pay for developer level tools and
now use Eclipse, etc. Putting it only in the hands of a few folks may be
useful or it may be futile, only time will tell.
 
In terms of your analogy of using try/catch blocks, I would say the
following: First, languages within the last ten years require you to use
them and they are not optional for the developer to skip in many situations.
Second, compilers actually check try/catch blocks which says that compilers
can and do play an important role which the community should leverage vs
avoid.
 
This does beg another question of should the community be helping the folks
who design languages to build in security-oriented constructs that we can
leverage instead of waiting for after-the-fact find-it utilities?
 
 

-----Original Message-----
From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
Sent: Thursday, December 21, 2006 10:55 AM
To: McGovern, James F (HTSC, IT); Secure Mailing List
Subject: Re: [SC-L] Compilers


Sure it should be built into the language, and I assume it will be
eventually. Heck it only took 30 or 40 years for people to force developers
to use Try...Catch blocks. 

-gp


On 12/21/06 9:30 AM, "McGovern, James F (HTSC, IT)"
<James.McGovern at thehartford.com> wrote:



I have been noodling the problem space of secure coding after attending a
wonderful class taught by Ken Van Wyk. I have been casually checking out
Fortify, Ounce Labs, etc and have a thought that this stuff should really be
part of the compiler and not a standalone product. Understanding that folks
do start companies to make up deficiencies in what large vendors ignore, how
far off base in my thinking am I?


*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************


  _____  

_______________________________________________
Secure Coding mailing list (SC-L) SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061221/140a9adc/attachment.html 

From stephen at corsaire.com  Thu Dec 21 12:30:02 2006
From: stephen at corsaire.com (Stephen de Vries)
Date: Fri, 22 Dec 2006 00:30:02 +0700
Subject: [SC-L] Compilers
In-Reply-To: <p05200f12c1b06389fb82@[192.168.1.254]>
References: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod> 
	<p05200f12c1b06389fb82@[192.168.1.254]>
Message-ID: <200612211730.kBLHUvgN051275@ratsass.krvw.com>


On 21 Dec 2006, at 23:19, ljknews wrote:
>
> Isn't the whole basis of Spark a matter of adding proof statements in
> the comments ?

You can achieve very similar goals by using unit tests.  Although the  
tests are not integrated into the code as tightly as something like  
Spark (or enforcing rules in the compiler), they are considered part  
of the source.   IMO unit and integration testing are vastly  
underutilised for performing security tests which is a shame because  
all the infrastructure, tools and skills are there - developers (and  
security testers) just need to start implementing security tests in  
addition to the functional tests.

[shameless plug] I wrote a paper about this for OWASP a few months back:
http://www.corsaire.com/white-papers/060531-security-testing-web- 
applications-through-automated-software-tests.pdf



-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com






----------------------------------------------------------------------
CONFIDENTIALITY:  This e-mail and any files transmitted with it are
confidential and intended solely for the use of the recipient(s) only.
Any review, retransmission, dissemination or other use of, or taking
any action in reliance upon this information by persons or entities
other than the intended recipient(s) is prohibited.  If you have
received this e-mail in error please notify the sender immediately
and destroy the material whether stored on a computer or otherwise.
----------------------------------------------------------------------
DISCLAIMER:  Any views or opinions presented within this e-mail are
solely those of the author and do not necessarily represent those
of Corsaire Limited, unless otherwise specifically stated.
----------------------------------------------------------------------
Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey, GU23 7EF
Telephone: +44(0)1483-226000  Email:info at corsaire.com


From ljknews at mac.com  Thu Dec 21 13:24:37 2006
From: ljknews at mac.com (ljknews)
Date: Thu, 21 Dec 2006 13:24:37 -0500
Subject: [SC-L] Compilers
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA18A@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB46019CA18A@AD1HFDEXC309.ad1.prod>
Message-ID: <p05200f14c1b080f3e4bb@[192.168.1.254]>

At 11:38 AM -0500 12/21/06, McGovern, James F (HTSC, IT) wrote:

> This does beg another question of should the community be helping the
> folks who design languages to build in security-oriented constructs that
> we can leverage instead of waiting for after-the-fact find-it utilities?

Language designers do what suits their purpose.  Some language designers
have security as their purpose.  If your goal is to convince the other
language designers they should take a different attitude, the best path
is to patronize those languages that have taken security seriously.

Today, very few language users are willing to do that.
-- 
Larry Kilgallen

From atemin at mitre.org  Thu Dec 21 13:38:28 2006
From: atemin at mitre.org (Temin, Aaron L.)
Date: Thu, 21 Dec 2006 13:38:28 -0500
Subject: [SC-L] Compilers
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>
Message-ID: <EAD5C58F27640B429D87C4663AFE3535011239A2@IMCSRV1.MITRE.ORG>

It would be worth knowing more about the basis you use for drawing the
conclusion, but if it's just the overlap between compilers and static
analyzers represented by the abstract syntax tree, I don't think that's
enough to warrant building one into the other (it might argue for
having a shared parser, but I don't think parsers are hard enough to
build to make that worthwhile).  I would also suggest that looking for
security weaknesses fits more into the unit testing part of development
rather than the compiling part.  As for "standalone," I think Jtest is
built as an Eclipse plug-in; I don't know if you'd consider that
standalone or not, but at least the developer doens't have to start up
another shell to run it.
 
Also, depending on the customer's organization, it might not be the
developer who is running the security static analysis.  I was talking
with an organization that was thinking of having the security group run
the static analysis, as part of the acceptance phase of an iteration.
 
- Aaron


________________________________

	From: sc-l-bounces at securecoding.org
[mailto:sc-l-bounces at securecoding.org] On Behalf Of McGovern, James F
(HTSC, IT)
	Sent: Thursday, December 21, 2006 10:31 AM
	To: Secure Coding
	Subject: [SC-L] Compilers
	
	
	I have been noodling the problem space of secure coding after
attending a wonderful class taught by Ken Van Wyk. I have been casually
checking out Fortify, Ounce Labs, etc and have a thought that this
stuff should really be part of the compiler and not a standalone
product. Understanding that folks do start companies to make up
deficiencies in what large vendors ignore, how far off base in my
thinking am I?
	
	
	
***********************************************************************
**
	This communication, including attachments, is
	for the exclusive use of addressee and may contain proprietary,
	confidential and/or privileged information. If you are not the
intended
	recipient, any use, copying, disclosure, dissemination or
distribution is
	strictly prohibited. If you are not the intended recipient,
please notify
	the sender immediately by return e-mail, delete this
communication and
	destroy all copies.
	
***********************************************************************
**
	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061221/6cf1a382/attachment.html 

From rcs at cert.org  Thu Dec 21 13:57:28 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Thu, 21 Dec 2006 13:57:28 -0500
Subject: [SC-L] Compilers
In-Reply-To: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>
References: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>
Message-ID: <458AD918.8040101@cert.org>


James,

Response below.
> I have been noodling the problem space of secure coding after
> attending a wonderful class taught by Ken Van Wyk. I have been
> casually checking out Fortify, Ounce Labs, etc and have a thought that
> this stuff should really be part of the compiler and not a standalone
> product. Understanding that folks do start companies to make up
> deficiencies in what large vendors ignore, how far off base in my
> thinking am I?
Tom Plum (from Plum Hall, Inc.) is developing a solution called
Safe/Secure C/C++ (SSCC) that might interest you
(http://www.plumhall.com/sscc.html).  SSCC incorporates static-analysis
methods into the compiler as well adding as run-time protections schemes
to eliminate buffer overflows as well as mitigate against other types of
vulnerabilities.  (I know that the claim seems exaggerated, but the
approach seems quite sound and I have yet to identify a case that SSCC
can not eliminate). 

Anyway, there is more information on his web site and I have cc'd Tom on
this message in case you would like to contact him directly.

rCs

From info at secappdev.org  Thu Dec 21 14:59:40 2006
From: info at secappdev.org (Johan Peeters)
Date: Thu, 21 Dec 2006 20:59:40 +0100
Subject: [SC-L] secure application development course
Message-ID: <458AE7AC.8090109@secappdev.org>

Katholieke Universiteit Leuven organizes an intensive course on secure 
application development for experienced software practitioners, in 
partnership with Solvay Business School and L-Sec (Leuven Security 
Excellence Consortium), from February 26th to March 2nd 2007.
The course is aimed at software architects, designers, developers, 
testers and technical project managers and is limited to 25 places for 
optimal interaction. The world class instructors have wide-ranging 
experience in academia and industry and are experts in application 
security. They include prof. Bart Preneel who heads COSIC, the renowned 
crypto lab, prof. Frank Piessens of K.U.L. who pioneered teaching 
application security at university level, Ken van Wyk, co-founder of the 
CERT Coordination Center, prof. Dan Wallach of Rice University who is 
well-known for his seminal work on the Java sandbox and Danny De Cock, a 
COSIC researcher, whose web site is the foremost repository of technical 
information on the Belgian eID card.

The course focuses on secure software engineering principles and 
techniques for countering threats and vulnerabilities in today's target 
environments. It provides participants with a thorough grounding in 
application security.

The course takes place in the Groot Begijnhof in Leuven, Belgium, a 
UNESCO World Heritage site.

Registration is on a first-come, first-served basis.
For more information visit the web site: http://secappdev.org.

-- 
Johan Peeters
program director
http://www.secappdev.org
+32 16 649000

From dwheeler at ida.org  Thu Dec 21 17:05:03 2006
From: dwheeler at ida.org (David A. Wheeler)
Date: Thu, 21 Dec 2006 17:05:03 -0500
Subject: [SC-L] Compilers
In-Reply-To: <mailman.1.1166720401.50104.sc-l@securecoding.org>
References: <mailman.1.1166720401.50104.sc-l@securecoding.org>
Message-ID: <458B050F.4070309@ida.org>

"McGovern, James F \(HTSC, IT\)"

> I have been noodling the problem space of secure coding after attending
 > a wonderful class taught by Ken Van Wyk. I have been casually checking
 > out Fortify, Ounce Labs, etc and have a thought that this stuff should
 > really be part of the compiler and not a standalone product.
 > Understanding that folks do start companies to make up deficiencies
 > in what large vendors ignore, how far off base in my thinking am I?

You're on-track.  Indeed, you can see little pieces of it happening.
I'll use gcc as an example, because it's one of the most
widely used C/C++ compilers in the world.  In the last few
years much has been added to gcc, including the ability to
detect format string errors and many mechanisms to help counter
buffer overflows (randomization, StackGuard & later IBM's
ProPolice sort-of-reimplementation, etc.).  I expect more detection
and prevention mechanisms to go into gcc C/C++ compilers in the future.

But I think you're not going far enough back.  Compilers or interpreters
are very much limited by the language (notation) they're trying to
support.  It's hideously hard to retrofit many kinds of
detection into C/C++, because programs written in those notations
just don't have enough information to easily determine if things
are okay.  Buffer overflows are an obvious example; they can't
even OCCUR in most languages, but are rife in C/C++ because
information about buffer size is not necessarily available to
a buffer user (yes, I know about C++'s STL, but you don't HAVE
to use it).  Which is why separate tools are used -- the analysis
work can be hideously hard.

It's better to have a language (including its library)
where the problem can't occur (e.g., because it's trivial to
detect it) or is at least unlikely/hard (e.g., make the "easy"
way the secure way).  Java (and its clone C#)
avoid many problems by DESIGN instead of happenstance, e.g.,
you can't (normally) have buffer overflows (in normal protected
code they can't happen).  Even stupid stuff like = vs. ==
mixing goes away (mostly).  If a language is designed to make it
EASY to do the right thing, the right thing is more likely to occur.

PHP, especially old versions, is an obvious case in point.
Old versions (where global_registers was true by default) are
almost impossible to write secure software for.  I will say that
at least the PHP folks were willing to change their language when
it was realized that their language's design made it nearly
impossible to be secure.  I wish they'd take more steps, but on
the other hand, other language communities are unwilling to take
even small steps to eliminate sharp edges from their languages.

--- David A. Wheeler



From gem at cigital.com  Thu Dec 21 21:27:01 2006
From: gem at cigital.com (Gary McGraw)
Date: Thu, 21 Dec 2006 21:27:01 -0500
Subject: [SC-L] Compilers
Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E81E0@va-mail.cigital.com>

I have a better idead.  Stop using C++.  Jeeze.

gem



 -----Original Message-----
From: 	Robert C. Seacord [mailto:rcs at cert.org]
Sent:	Thu Dec 21 20:40:35 2006
To:	McGovern, James F (HTSC, IT)
Cc:	Thomas Plum; Secure Coding
Subject:	Re: [SC-L] Compilers


James,

Response below.
> I have been noodling the problem space of secure coding after
> attending a wonderful class taught by Ken Van Wyk. I have been
> casually checking out Fortify, Ounce Labs, etc and have a thought that
> this stuff should really be part of the compiler and not a standalone
> product. Understanding that folks do start companies to make up
> deficiencies in what large vendors ignore, how far off base in my
> thinking am I?
Tom Plum (from Plum Hall, Inc.) is developing a solution called
Safe/Secure C/C++ (SSCC) that might interest you
(http://www.plumhall.com/sscc.html).  SSCC incorporates static-analysis
methods into the compiler as well adding as run-time protections schemes
to eliminate buffer overflows as well as mitigate against other types of
vulnerabilities.  (I know that the claim seems exaggerated, but the
approach seems quite sound and I have yet to identify a case that SSCC
can not eliminate). 

Anyway, there is more information on his web site and I have cc'd Tom on
this message in case you would like to contact him directly.

rCs
_______________________________________________
Secure Coding mailing list (SC-L) SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------


From michaelslists at gmail.com  Fri Dec 22 08:14:08 2006
From: michaelslists at gmail.com (mikeiscool)
Date: Sat, 23 Dec 2006 00:14:08 +1100
Subject: [SC-L] Compilers
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E81E0@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E81E0@va-mail.cigital.com>
Message-ID: <5e01c29a0612220514g5936e98cqd6c4975ee34a7f3@mail.gmail.com>

On 12/22/06, Gary McGraw <gem at cigital.com> wrote:
> I have a better idead.  Stop using C++.  Jeeze.

Even better then that; stop programming insecurely.


> gem

*rolleyes*

-- mic

From james.walden at gmail.com  Fri Dec 22 14:20:48 2006
From: james.walden at gmail.com (James Walden)
Date: Fri, 22 Dec 2006 14:20:48 -0500
Subject: [SC-L] Compilers
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E81E0@va-mail.cigital.com>
References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E81E0@va-mail.cigital.com>
Message-ID: <21c655860612221120q6532e82ag5ecda5be6f2735ca@mail.gmail.com>

On 12/21/06, Gary McGraw <gem at cigital.com> wrote:
>
> I have a better idead.  Stop using C++.  Jeeze.


I'll second that recommendation.  Given the abundance of better languages,
there are few good reasons to use dangerous languages like C++ on new
projects.  It's easier and less time consuming to learn a new safe language
than to use C++ securely.

James Walden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061222/bca61141/attachment.html 

From james.walden at gmail.com  Fri Dec 22 14:30:02 2006
From: james.walden at gmail.com (James Walden)
Date: Fri, 22 Dec 2006 14:30:02 -0500
Subject: [SC-L] Compilers
In-Reply-To: <200612211730.kBLHUvgN051275@ratsass.krvw.com>
References: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>
	<p05200f12c1b06389fb82@192.168.1.254>
	<200612211730.kBLHUvgN051275@ratsass.krvw.com>
Message-ID: <21c655860612221130s439e245fl69d2aa12d2adee59@mail.gmail.com>

On 12/21/06, Stephen de Vries <stephen at corsaire.com> wrote:

> You can achieve very similar goals by using unit tests.  Although the
> tests are not integrated into the code as tightly as something like
> Spark (or enforcing rules in the compiler), they are considered part
> of the source.   IMO unit and integration testing are vastly
> underutilised for performing security tests which is a shame because
> all the infrastructure, tools and skills are there - developers (and
> security testers) just need to start implementing security tests in
> addition to the functional tests.


I agree that it's important to test the security of your software and I like
test-driven development, but unit tests are not a replacement for static
analysis assisted code reviews.  Likewise, static analysis and code reviews
aren't a substitute for security testing.

Security tests attempt to find bad input and verify that the program handles
it correctly, but you can't guarantee that you've found every possible type
of bad input.  Unit tests have the additional problem that input which may
be safe for the current unit may become dangerous when interpreted
differently in a different unit of the program (e.g., ' OR 1-1--' is just
text to your web application, but your database may interpret it as code.)

Code reviews find different bugs than tests do, and they typically find them
faster, so good testing practices are not an excuse to ignore static
analysis and code reviews.  Tests also find different bugs than code reviews
do.  If your static analysis tool doesn't have a rule to detect a particular
class of security bug, it obviously won't find it, but your testers might
have the experience to test for it.

 James Walden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061222/92e2ceac/attachment.html 

From crispin at novell.com  Mon Dec 25 18:39:59 2006
From: crispin at novell.com (Crispin Cowan)
Date: Mon, 25 Dec 2006 15:39:59 -0800
Subject: [SC-L] Compilers
In-Reply-To: <p05200f12c1b06389fb82@[192.168.1.254]>
References: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>
	<p05200f12c1b06389fb82@[192.168.1.254]>
Message-ID: <4590614F.5040108@novell.com>

ljknews wrote:
> 	2. The compiler market is so immature that some people are still
> 	   using C, C++ and Java.
>   
I'm with you on the C and C++ argument, but what is immature about Java?
I thought Java was a huge step forward, because for the first time, a
statically typesafe language was widely popular.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hacking is exploiting the gap between "intent" and "implementation"



From tholleb at teknowledge.com  Wed Dec 27 13:50:55 2006
From: tholleb at teknowledge.com (Tim Hollebeek)
Date: Wed, 27 Dec 2006 10:50:55 -0800
Subject: [SC-L] Compilers
In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB7E81B0@va-mail.cigital.com>
Message-ID: <200612271854.kBRIsWc2035342@ratsass.krvw.com>

 
> However, not 
> all of the kinds of things should be put in the compiler (how 
> many coders do you know that use the -Wall??!).

All the decent ones???  I remember people talking about "Warning 
free with -Wall" as a minimal requirement, and personally using 
that standard, over 15 years ago.  And that was just for code
quality reasons.  Granted, many monkeys with keyboards were
pulled into the industry during the 90s IT boom, but are shops
that insist on warning free compiles really that rare?

I'm not sure "How can we create secure software in an environment
where people don't even conform to minimalist software engineering
principles?" is a helpful topic for discussion as a way forward,
no matter how useful it may be as a source for tool and consulting
revenue.

Tim Hollebeek
Research Scientist
Teknowledge Corp.



From secureCoding2dave at davearonson.com  Wed Dec 27 14:59:59 2006
From: secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)
Date: Wed, 27 Dec 2006 19:59:59 +0000
Subject: [SC-L] Compilers
Message-ID: <W48901297477251167249599@webmail2>

Tim Hollebeek [mailto:tholleb at teknowledge.com] wonders:

 > are shops that insist on warning free compiles really that rare?

Yes.  I've worked for or with many companies over the years, totalling probably somewhere in the mid-teens or so.  In all that, there was, to the best of my recollection, only ONE that insisted on it, other than my own "one man show".  Add to that, numerous open source apps I've compiled; I haven't kept track of how many were warning-free, but it's rare enough that I consider it a pleasant surprise.

In several projects, I fixed some nasty bugs (inherited from other people) by turning warnings on (they were often totally suppressed!), and fixing the things that the warnings were trying to warn me about.  This is of course obvious to you and me, and probably to most of this list, but apparently not to the vast majority of programmers (even so-called software engineers), let alone people in any position of authority to set such policies.  :-(

-Dave

-- 
Dave Aronson
"Specialization is for insects."  -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/




From leichter_jerrold at emc.com  Wed Dec 27 17:30:21 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Wed, 27 Dec 2006 17:30:21 -0500 (EST)
Subject: [SC-L] Compilers
In-Reply-To: <W48901297477251167249599@webmail2>
References: <W48901297477251167249599@webmail2>
Message-ID: <Pine.SOL.4.61.0612271710590.7389@mental>

|  > are shops that insist on warning free compiles really that rare?
| 
| Yes.  I've worked for or with many companies over the years, totalling 
| probably somewhere in the mid-teens or so.  In all that, there was, to the 
| best of my recollection, only ONE that insisted on it, other than my own 
| "one man show".  Add to that, numerous open source apps I've compiled; I 
| haven't kept track of how many were warning-free, but it's rare enough that 
| I consider it a pleasant surprise.
| 
| In several projects, I fixed some nasty bugs (inherited from other people) 
| by turning warnings on (they were often totally suppressed!), and fixing the 
| things that the warnings were trying to warn me about.  This is of course 
| obvious to you and me, and probably to most of this list, but apparently not 
| to the vast majority of programmers (even so-called software engineers), let 
| alone people in any position of authority to set such policies.  :-(
I have no idea how common it actually is, but based on my own experience -
where I required it from my guys and we enforced it on software written
by others - it's not very common.  Unless you push  for it, very few
programmers will even think about it.  (In fact, unless you're in a
position to control the compiler options - I was - most programmers
will set them to just shut the damn compiler up.)

A couple of issues are relevant here, however:

	- The level of warnings available in compilers varies, and
		some of the warnings are ... dumb.  We built on
		maybe 5 different compilers, and you could easily
		find examples where only one compiler would warn on
		something.  On the other hand, you ran into things
		like Microsoft compilers that warned about "u == 1"
		when u was unsigned, or compilers that got confused
		about control flow and warned about unreachable code
		that wasn't, or alternatively about loops with no
		exits (which had them).  These are allo annoyances
		one can work around with sufficient will, but you
		have to *want* to.

	- If you're not *really* careful in teaching people about
		how to fix warnings, they will hide them.  In C
		and C++, all too many warnings get hidden by a
		cast here and there.  (I always quote Henry Spencer's
		classic comment:  If you lie to the compiler it
		will get its revenge.)  A more subtle problem I've
		seen is "fixing" a warning tht some variable isn't
		initialized along some path by simply setting it
		to some arbitrary value - almost always 0, actually -
		in its declaration.  This one is particularly bad
		because many style guides recommend that you always
		initialize every value on declaration.  (Note that
		in C++, everything but the basic types inherited
		from C is always initialized - even if to a value
		that may be meaningless in context.  As a result,
		you lose a valuable potential warning.  The advice
		that you never declare a variable until you know
		what to initialize it to fails in the common code
		sequence:

		T v;
		if (condition)
			v = f1();
		else	v = f2();

		where both f1() and f2() are expensive, so you can't
		make either the default.

		This isn't a C++ issue, BTW - safe languages generally
		require that a variable *always* receive some valid
		value.  (Java does do a lot of work to recover the
		notion of a variable being "undefined" before its use.
		Bravo.)

							-- Jerry



From dwheeler at ida.org  Thu Dec 28 13:56:57 2006
From: dwheeler at ida.org (David A. Wheeler)
Date: Thu, 28 Dec 2006 13:56:57 -0500
Subject: [SC-L] Compilers
In-Reply-To: <mailman.1.1167325201.76540.sc-l@securecoding.org>
References: <mailman.1.1167325201.76540.sc-l@securecoding.org>
Message-ID: <45941379.6000103@ida.org>

I _strongly_ encourage development with "maximal" warnings turned on.
However, this does have some side-effects because many compilers
give excessive spurious warnings.  It's especially difficult to
do with pre-existing code (the effort can be herculean).

An interesting discussion about warning problems in the Linux kernel
can be found here:
http://lwn.net/Articles/207030/

Ideally compiler writers should treat spurious warnings as serious bugs,
or people will quickly learn to ignore all warnings.
The challenge is that it can be difficult to determine what is
"spurious" without also making the warning not report what it SHOULD
report.  It's a classic false positive vs. false negative problem
for all static tools, made especially hard in languages where
there isn't a lot of information to work with.

--- David A. Wheeler



From leichter_jerrold at emc.com  Fri Dec 29 09:46:16 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Fri, 29 Dec 2006 09:46:16 -0500 (EST)
Subject: [SC-L] Compilers
In-Reply-To: <45941379.6000103@ida.org>
References: <mailman.1.1167325201.76540.sc-l@securecoding.org>
	<45941379.6000103@ida.org>
Message-ID: <Pine.SOL.4.61.0612290916420.8074@mental>

| I _strongly_ encourage development with "maximal" warnings turned on.
| However, this does have some side-effects because many compilers
| give excessive spurious warnings.  It's especially difficult to
| do with pre-existing code (the effort can be herculean).
Agreed.  Writing for maximum freedom from warnings is a learned skill,
and a discipline.  Mainly it involves avoiding certain kinds of
constructs that, when all is said and done, are usually as confusing
to human readers as they are to compilers.  There is a great deal of
overlap among "writing for no warnings", "writing for maximum
portability", "writing for clarity", and "writing for provability".
What they all come down to is:  The code sticks to the meaning of
the language definition and avoids all ambiguity; it has only one
possible interpretation, and coming to that interpretation requires
minimum work.

That said, there will always be cases where maximum speed, minimum
size, or some other external constraint drive you to do things that
don't meet these constraints.  Some of these are reasonable.  Bubble
sort is "obviously correct"; no O(N log N) sort is.  There are
places where you have to use comments to refer to a proof and the
kind of checking required becomes very different.  And there are
places where every nanosecond and every byte really matters.  The
conceit of all too many programmers is that *their* code is
*obviously* one of those cases.  It almost certainly isn't.
 
| An interesting discussion about warning problems in the Linux kernel
| can be found here:
| http://lwn.net/Articles/207030/
There's example given there of:

    bool flag = false;
    some_type* pointer;

    if (some_condition_is_true()) {
       flag = true;
       pointer = expensive_allocation_function();
    }
    do_something_else();
    if (flag) {
       use_the_fine(pointer);
    }

The compiler will warn that the call to use_the_fine() might be
called with an uninitialized pointer.  Noticing the tie between
flag being true and pointer being initialized is beyond gcc,
and probably beyond any compiler other than some research tools.

Then again, it's not so easy for a human either beyond a trivial
example like this!

There's an obvious way to change this code that is simultaneously
warning-free, clearer - it says exactly what it means - and smaller
and equally fast on all modern architectures:  Get rid of flag,
initialize pointer to NULL, then change the test of flag to test
whether pointer is non-NULL.  (Granted, this is reading into the
semantics of "expensive_allocation_function()".)  Someone mentions
this in one response, but none of the other respondents pick up
on the idea and the discussion instead goes off into very different
directions.

There's also no discussion of the actual cost in the generated code
of, say, initializing pointer to NULL.  After all, it's certainly
going to be in a register; clearing a register will be cheap.  And
the compiler might not even be smart enough to avoid a pointless
load from uninitialized memory of pointer is *not* given an
initial value.

(There is one nice idea in the discussion:  Having the compiler
tell you that some variable *could* have been declared const,
but wasn't.)

I find this kind of sideways discussion all too common when you
start talking about eliminating warnings.

| Ideally compiler writers should treat spurious warnings as serious bugs,
| or people will quickly learn to ignore all warnings.
| The challenge is that it can be difficult to determine what is
| "spurious" without also making the warning not report what it SHOULD
| report.  It's a classic false positive vs. false negative problem
| for all static tools, made especially hard in languages where
| there isn't a lot of information to work with.
Having assertions actually part of the language is a big help here.
This is all too rare.
							-- Jerry
 
| --- David A. Wheeler

From rcs at cert.org  Fri Dec 29 13:41:38 2006
From: rcs at cert.org (Robert C. Seacord)
Date: Fri, 29 Dec 2006 13:41:38 -0500
Subject: [SC-L] temporary directories
In-Reply-To: <Pine.SOL.4.61.0612290916420.8074@mental>
References: <mailman.1.1167325201.76540.sc-l@securecoding.org>	<45941379.6000103@ida.org>
	<Pine.SOL.4.61.0612290916420.8074@mental>
Message-ID: <45956162.1060405@cert.org>


I've seen advice here and there to use the mkdtemp() function to create
temporary directories, for example:

- Kris Kennaway email at http://lwn.net/2000/1221/a/sec-tmp.php3
recommends them

- David Wheeler's Secure Programming for Linux and Unix HOWTO at
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html
mentions it may not be a good idea if tmp cleaners are in use (but this
sort of suggests maybe it is ok if they are not.)

- HP 03 Tru64 UNIX Protecting Your System Against File Name Spoofing
Attacks. January 2003. 
http://h30097.www3.hp.com/docs/wpapers/spoof_wp/symlink_external.pdf

- etc.

The mkdtemp() function generates a uniquely-named temporary directory
from template.  This function appears to work exactly like mktemp()
works for files, except of course mktemp() has been widely discredited
because of possible TOCTOU conditions and problems generating unique,
unpredictable names.

So my question is, why is mkdtemp() considered safe?  Isn't it also
susceptible to race conditions?  Is there a reason why these race
conditions are not at issue in this case?  Or is it only considered safe
because there is no alternative?

Thanks,
rCs


From ljknews at mac.com  Fri Dec 29 15:28:13 2006
From: ljknews at mac.com (ljknews)
Date: Fri, 29 Dec 2006 15:28:13 -0500
Subject: [SC-L] temporary directories
In-Reply-To: <45956162.1060405@cert.org>
References: <mailman.1.1167325201.76540.sc-l@securecoding.org>
	<45941379.6000103@ida.org> <Pine.SOL.4.61.0612290916420.8074@mental>
	<45956162.1060405@cert.org>
Message-ID: <p05200f16c1bb2a6437cf@[192.168.1.254]>

At 1:41 PM -0500 12/29/06, Robert C. Seacord wrote:
> I've seen advice here and there to use the mkdtemp() function to create
> temporary directories, for example:
> 
> - Kris Kennaway email at http://lwn.net/2000/1221/a/sec-tmp.php3
> recommends them
> 
> - David Wheeler's Secure Programming for Linux and Unix HOWTO at
> http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html
> mentions it may not be a good idea if tmp cleaners are in use (but this
> sort of suggests maybe it is ok if they are not.)
> 
> - HP 03 Tru64 UNIX Protecting Your System Against File Name Spoofing
> Attacks. January 2003. 
> http://h30097.www3.hp.com/docs/wpapers/spoof_wp/symlink_external.pdf
> 
> - etc.
> 
> The mkdtemp() function generates a uniquely-named temporary directory
> from template.  This function appears to work exactly like mktemp()
> works for files, except of course mktemp() has been widely discredited
> because of possible TOCTOU conditions and problems generating unique,
> unpredictable names.
> 
> So my question is, why is mkdtemp() considered safe?  Isn't it also
> susceptible to race conditions?  Is there a reason why these race
> conditions are not at issue in this case?  Or is it only considered safe
> because there is no alternative?

Not on Unix, but I tend to use temporary names based on the Process ID
that is executing.  And of course file protection prevents malevolent
access.

But for a temporary file, I will specify a file that is not in any
directory.  I presume there is such a capbility in Unix.
-- 
Larry Kilgallen

From fw at deneb.enyo.de  Fri Dec 29 17:53:25 2006
From: fw at deneb.enyo.de (Florian Weimer)
Date: Fri, 29 Dec 2006 23:53:25 +0100
Subject: [SC-L] Compilers
In-Reply-To: <4590614F.5040108@novell.com> (Crispin Cowan's message of "Mon,
	25 Dec 2006 15:39:59 -0800")
References: <773F863A6009244B87E6E866AFC7DB46019CA177@AD1HFDEXC309.ad1.prod>
	<p05200f12c1b06389fb82@[192.168.1.254]> <4590614F.5040108@novell.com>
Message-ID: <87hcvemhzu.fsf@mid.deneb.enyo.de>

* Crispin Cowan:

> ljknews wrote:
>> 	2. The compiler market is so immature that some people are still
>> 	   using C, C++ and Java.

> I'm with you on the C and C++ argument, but what is immature about Java?
> I thought Java was a huge step forward, because for the first time, a
> statically typesafe language was widely popular.

Java is not statically typesafe, see the beloved ArrayStoreException
(and other cases, depending what you mean by "statically typesafe").

And if you allow for more dynamic typing, Visual Basic gained more
widespread usage even earlier. 8-P

From leichter_jerrold at emc.com  Fri Dec 29 18:56:53 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Fri, 29 Dec 2006 18:56:53 -0500 (EST)
Subject: [SC-L] temporary directories
In-Reply-To: <p05200f16c1bb2a6437cf@[192.168.1.254]>
References: <mailman.1.1167325201.76540.sc-l@securecoding.org>
	<45941379.6000103@ida.org> <Pine.SOL.4.61.0612290916420.8074@mental>
	<45956162.1060405@cert.org> <p05200f16c1bb2a6437cf@[192.168.1.254]>
Message-ID: <Pine.SOL.4.61.0612291846040.8074@mental>

| Not on Unix, but I tend to use temporary names based on the Process ID
| that is executing.  And of course file protection prevents malevolent
| access.
| 
| But for a temporary file, I will specify a file that is not in any
| directory.  I presume there is such a capbility in Unix.
You presume incorrectly.  You're talking about VMS, where you can
open a file by file id.  The Unix analogue of a file id is an
inode number, but no user-land call exists to access a file that
way.  You can only get to a file by following a path through the
directory structure.

In fact, all kinds of Unix code would become insecure if such a
call were to be added:  It's a common - and reasonable - assumption
that accessing a file requires access to the (well, a) directory in
which that file appears (not that it isn't prudent to also control
access to the file itself).

One can argue this both ways, but on the specific matter of safe
access to temporary files, VMS code that uses FID access is much
easier to get right than Unix code that inherently has to walk
through directory trees.  On the other hand, access by file id
isn't - or wasn't; it's been years since I used VMS - supported
directly by higher-level languages (though I vaguely recall that
C had a mechanism for doing it).  A mechanism that requires
specialized, highly system-specific low-level code to do something so
straightforward is certainly much better than no mechanism at all,
but it's not something that will ever be used by more than a
small couterie of advanced programmers.
							-- Jerry


From ljknews at mac.com  Fri Dec 29 20:49:01 2006
From: ljknews at mac.com (ljknews)
Date: Fri, 29 Dec 2006 20:49:01 -0500
Subject: [SC-L] temporary directories
In-Reply-To: <Pine.SOL.4.61.0612291846040.8074@mental>
References: <mailman.1.1167325201.76540.sc-l@securecoding.org>
	<45941379.6000103@ida.org> <Pine.SOL.4.61.0612290916420.8074@mental>
	<45956162.1060405@cert.org> <p05200f16c1bb2a6437cf@[192.168.1.254]>
	<Pine.SOL.4.61.0612291846040.8074@mental>
Message-ID: <p05200f1ac1bb6db909c2@[192.168.1.254]>

At 6:56 PM -0500 12/29/06, Leichter, Jerry wrote:

> | Not on Unix, but I tend to use temporary names based on the Process ID
> | that is executing.  And of course file protection prevents malevolent
> | access.
> |
> | But for a temporary file, I will specify a file that is not in any
> | directory.  I presume there is such a capability in Unix.

> You presume incorrectly.  You're talking about VMS, where you can
> open a file by file id. 

Actually, I was talking about using the FAB$V_TMD bit when creating
the file.

> One can argue this both ways, but on the specific matter of safe
> access to temporary files, VMS code that uses FID access is much
> easier to get right than Unix code that inherently has to walk
> through directory trees.  On the other hand, access by file id
> isn't - or wasn't; it's been years since I used VMS - supported
> directly by higher-level languages (though I vaguely recall that
> C had a mechanism for doing it).

In Ada invoking <packagename>.CREATE with a null name will do the
trick, although if your VMS experience ended before 1983 you would
not have run into that.  But how to program easily against VMS V4.1
when the latest version is VMS V8.3 is not a typical problem.

I gather you are saying that the innards of Unix will force creation
of an unwanted directory entry on the Ada implementation of the required
null name support for <packagename>.CREATE .  The Ada implementation
could rely on exclusive access to the file (surely Unix has that, right?)
coupled with whatever Unix has that passes for the FAB$V_DLT bit to
delete the file on Close (such as at <insert Unix words for image rundown>).

But these are problems that have been solved by those who provided the
Ada implementation (ACT and Aonix come to mind for Unix), and thus are
not an issue for the high level language programmer.
-- 
Larry Kilgallen

From mouse at Rodents.Montreal.QC.CA  Sat Dec 30 00:58:08 2006
From: mouse at Rodents.Montreal.QC.CA (der Mouse)
Date: Sat, 30 Dec 2006 00:58:08 -0500 (EST)
Subject: [SC-L] temporary directories
In-Reply-To: <Pine.SOL.4.61.0612291846040.8074@mental>
References: <mailman.1.1167325201.76540.sc-l@securecoding.org>
	<45941379.6000103@ida.org> <Pine.SOL.4.61.0612290916420.8074@mental>
	<45956162.1060405@cert.org> <p05200f16c1bb2a6437cf@[192.168.1.254]>
	<Pine.SOL.4.61.0612291846040.8074@mental>
Message-ID: <200612300604.BAA08439@Sparkle.Rodents.Montreal.QC.CA>

>> But for a temporary file, I will specify a file that is not in any
>> directory.  I presume there is such a capbility in Unix.
> You presume incorrectly.

Yes and no.

Unix does have files that do not have names in any directory.  What it
does not have is creation of such files without the existence (even
transiently) of any name for them.

To the extent that "Unix" is a single thing, that is.  It wouldn't
surprise me if some Unix variants had a way to do this.  (If you're
willing to accept a name in a directory which does not have a name
anywhere except for its own ".", many of them do.)

> You're talking about VMS, where you can open a file by file id.  The
> Unix analogue of a file id is an inode number, but no user-land call
> exists to access a file that way.

On many Unix variants, such a call does exist.  See NetBSD's (and
probably others') fhopen, for example.  It's restricted to root, but it
exists.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From mrockman at acm.org  Sat Dec 30 05:03:51 2006
From: mrockman at acm.org (Mark Rockman)
Date: Sat, 30 Dec 2006 05:03:51 -0500
Subject: [SC-L] temporary directories
References: <mailman.1.1167325201.76540.sc-l@securecoding.org><45941379.6000103@ida.org>
	<Pine.SOL.4.61.0612290916420.8074@mental><45956162.1060405@cert.org>
	<p05200f16c1bb2a6437cf@[192.168.1.254]>
	<Pine.SOL.4.61.0612291846040.8074@mental>
Message-ID: <001201c72bf9$cf662f20$ce00000a@mdrsesco.com>

The old Sperry operating system from Unisys for successors to the 1108 computer has temporary files that are accessible only to the process that creates them.  Such files can be treated as "directories," even though the file system on such machines is not tree-structured.  Space allocated to temporary files is reclaimed when the file is no longer needed (as when the process terminates) and when the system unexpectedly reboots with processes running.  This is interesting as there is no record of such files in the file naming system except, perhaps, for a few orphaned "granule" tables that map file relative addresses to device relative addresses.  The security of temporary files on such systems is absolute as they cannot be accessed through the file naming system.  Yet they are named exactly as are files that are accessible through the file naming system.  The beauty of such temporary files is that they take care of themselves when abandoned:  they don't hang around as entries in a catalogue waiting for some process to dispose of them.
  ----- Original Message ----- 
  From: Leichter, Jerry 
  To: ljknews 
  Cc: sc-l at securecoding.org 
  Sent: Friday, December 29, 2006 18:56
  Subject: Re: [SC-L] temporary directories


  | Not on Unix, but I tend to use temporary names based on the Process ID
  | that is executing.  And of course file protection prevents malevolent
  | access.
  | 
  | But for a temporary file, I will specify a file that is not in any
  | directory.  I presume there is such a capbility in Unix.
  You presume incorrectly.  You're talking about VMS, where you can
  open a file by file id.  The Unix analogue of a file id is an
  inode number, but no user-land call exists to access a file that
  way.  You can only get to a file by following a path through the
  directory structure.

  In fact, all kinds of Unix code would become insecure if such a
  call were to be added:  It's a common - and reasonable - assumption
  that accessing a file requires access to the (well, a) directory in
  which that file appears (not that it isn't prudent to also control
  access to the file itself).

  One can argue this both ways, but on the specific matter of safe
  access to temporary files, VMS code that uses FID access is much
  easier to get right than Unix code that inherently has to walk
  through directory trees.  On the other hand, access by file id
  isn't - or wasn't; it's been years since I used VMS - supported
  directly by higher-level languages (though I vaguely recall that
  C had a mechanism for doing it).  A mechanism that requires
  specialized, highly system-specific low-level code to do something so
  straightforward is certainly much better than no mechanism at all,
  but it's not something that will ever be used by more than a
  small couterie of advanced programmers.
  -- Jerry

  _______________________________________________
  Secure Coding mailing list (SC-L) SC-L at securecoding.org
  List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
  List charter available at - http://www.securecoding.org/list/charter.php
  SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
  as a free, non-commercial service to the software security community.
  _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20061230/183fcad1/attachment-0001.html 

From leichter_jerrold at emc.com  Sat Dec 30 08:45:56 2006
From: leichter_jerrold at emc.com (Leichter, Jerry)
Date: Sat, 30 Dec 2006 08:45:56 -0500 (EST)
Subject: [SC-L] temporary directories
In-Reply-To: <p05200f1ac1bb6db909c2@[192.168.1.254]>
References: <mailman.1.1167325201.76540.sc-l@securecoding.org>
	<45941379.6000103@ida.org> <Pine.SOL.4.61.0612290916420.8074@mental>
	<45956162.1060405@cert.org> <p05200f16c1bb2a6437cf@[192.168.1.254]>
	<Pine.SOL.4.61.0612291846040.8074@mental>
	<p05200f1ac1bb6db909c2@[192.168.1.254]>
Message-ID: <Pine.SOL.4.61.0612300816470.8074@mental>

[MJoderator:  This is likely beyond the point of general interest to sc-l]

On Fri, 29 Dec 2006, ljknews wrote:

| Date: Fri, 29 Dec 2006 20:49:01 -0500
| From: ljknews <ljknews at mac.com>
| To: sc-l at securecoding.org
| Subject: Re: [SC-L] temporary directories
| 
| At 6:56 PM -0500 12/29/06, Leichter, Jerry wrote:
| 
| > | Not on Unix, but I tend to use temporary names based on the Process ID
| > | that is executing.  And of course file protection prevents malevolent
| > | access.
| > |
| > | But for a temporary file, I will specify a file that is not in any
| > | directory.  I presume there is such a capability in Unix.
| 
| > You presume incorrectly.  You're talking about VMS, where you can
| > open a file by file id. 
| 
| Actually, I was talking about using the FAB$V_TMD bit when creating
| the file.
The way one would get the effect of TMD on Unix is to create the file
normally and, while keeping a descriptor open on it, delete it.  The
file will then "live" and be completely usable to this process or to
any other process that either (a) already has it open (legitimately
or because they snuck in on the race condition); (b) receives the open
dexriptor by inheritance after a fork(); (c) receives the open descriptor
by an explicit pass through a Unix-mode socket (a relatively little
used facility).  However, no one would be able to find the file
through any file system entry, and no user-land code could get to
it through its inode number even if it got its hands on that number.

| > One can argue this both ways, but on the specific matter of safe
| > access to temporary files, VMS code that uses FID access is much
| > easier to get right than Unix code that inherently has to walk
| > through directory trees.  On the other hand, access by file id
| > isn't - or wasn't; it's been years since I used VMS - supported
| > directly by higher-level languages (though I vaguely recall that
| > C had a mechanism for doing it).
| 
| In Ada invoking <packagename>.CREATE with a null name will do the
| trick, although if your VMS experience ended before 1983 you would
| not have run into that.  But how to program easily against VMS V4.1
| when the latest version is VMS V8.3 is not a typical problem.
I think the last VMS version I actively used was 5.4 or so.

| I gather you are saying that the innards of Unix will force creation
| of an unwanted directory entry on the Ada implementation of the required
| null name support for <packagename>.CREATE .  The Ada implementation
| could rely on exclusive access to the file (surely Unix has that, right?)
Not typically, no.  (There are extensions, but standard Unix has only
advisory locking - i.e., locking enforced between processes that
choose to make locking calls.)

| coupled with whatever Unix has that passes for the FAB$V_DLT bit to
| delete the file on Close (such as at <insert Unix words for image rundown>).
There's no direct analogue.  Unix inode's are reference-counted - a
directory entry is a reference.  There's no explicit way to delete a
file - all you can do is get rid of all the references you can.  If
that gets the ref count down to 0, the file will disappear "eventually".
(There's a separate count of open file descriptors to implement that
"sticks around while open" semantics.)

| But these are problems that have been solved by those who provided the
| Ada implementation (ACT and Aonix come to mind for Unix), and thus are
| not an issue for the high level language programmer.
Presumably they do the create-the-file-and-immediately-delete-it trick.
Since the file must, however briefly, have an entry in some directory.
General purpose code can't make assuptions about what directories
are available for writing, so pretty much has to put the entry in
a known, public place - almost always /tmp or /var/tmp.  Unless one
does this very carefully, it's open to various attacks.  (For one
trivial example, there is no way to tell the open() call to *always*
create a new file - you can only tell it "if the file already exists,
don't open it, return an error instead".  The code had better check
for that error and do something appropriate or it can be fooled into
using a file an attacker created and already has access to.)

The techniques for doing this are complex enough - and the attacks
if you don't do it *exactly* right obscure enough - that after all
these years, attacks based on "insecure temporary file creation"
are still reported regularly.  (Frankly, even though I know that
these problems exist, if you were to ask me to write a secure
temporary file creator right now, I wouldn't try - I'd look for
some existing code, because I doubt I'd get it right.)

							-- Jerry

| -- 
| Larry Kilgallen
| _______________________________________________
| Secure Coding mailing list (SC-L) SC-L at securecoding.org
| List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
| List charter available at - http://www.securecoding.org/list/charter.php
| SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
| as a free, non-commercial service to the software security community.
| _______________________________________________
| 
| 

From fw at deneb.enyo.de  Sat Dec 30 11:11:06 2006
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 30 Dec 2006 17:11:06 +0100
Subject: [SC-L] temporary directories
In-Reply-To: <p05200f1ac1bb6db909c2@[192.168.1.254]> (ljknews@mac.com's
	message of "Fri, 29 Dec 2006 20:49:01 -0500")
References: <mailman.1.1167325201.76540.sc-l@securecoding.org>
	<45941379.6000103@ida.org> <Pine.SOL.4.61.0612290916420.8074@mental>
	<45956162.1060405@cert.org> <p05200f16c1bb2a6437cf@[192.168.1.254]>
	<Pine.SOL.4.61.0612291846040.8074@mental>
	<p05200f1ac1bb6db909c2@[192.168.1.254]>
Message-ID: <87tzzd749x.fsf@mid.deneb.enyo.de>

> I gather you are saying that the innards of Unix will force creation
> of an unwanted directory entry on the Ada implementation of the required
> null name support for <packagename>.CREATE .  The Ada implementation
> could rely on exclusive access to the file (surely Unix has that, right?)

You can create files in a way that fails if the file already exists,
using the O_EXCL flag.  (Rumors have it that this won't work reliably
over NFS, though, but I don't see why.)

> coupled with whatever Unix has that passes for the FAB$V_DLT bit to
> delete the file on Close (such as at <insert Unix words for image rundown>).

You can delete open files on Unix, so you could in theory unlink it
after creation.

But the whole discussion is moot because existing Ada code seems to
require that temporary files have names. 8-/

> But these are problems that have been solved by those who provided the
> Ada implementation (ACT and Aonix come to mind for Unix), and thus are
> not an issue for the high level language programmer.

AdaCore's implementation used mktemp and featured the usual race
condition.

From ljknews at mac.com  Sat Dec 30 13:25:58 2006
From: ljknews at mac.com (ljknews)
Date: Sat, 30 Dec 2006 13:25:58 -0500
Subject: [SC-L] temporary directories
In-Reply-To: <Pine.SOL.4.61.0612300816470.8074@mental>
References: <mailman.1.1167325201.76540.sc-l@securecoding.org>
	<45941379.6000103@ida.org> <Pine.SOL.4.61.0612290916420.8074@mental>
	<45956162.1060405@cert.org> <p05200f16c1bb2a6437cf@[192.168.1.254]>
	<Pine.SOL.4.61.0612291846040.8074@mental>
	<p05200f1ac1bb6db909c2@[192.168.1.254]>
	<Pine.SOL.4.61.0612300816470.8074@mental>
Message-ID: <p05200f1ec1bc5eefb5db@[192.168.1.254]>

At 8:45 AM -0500 12/30/06, Leichter, Jerry wrote:

> [MJoderator:  This is likely beyond the point of general interest to sc-l]

Actually, I disagree, in that it seems to expose a set of vulnerabilities
not known even to language implementors.

> On Fri, 29 Dec 2006, ljknews wrote:

> | But these are problems that have been solved by those who provided the
> | Ada implementation (ACT and Aonix come to mind for Unix), and thus are
> | not an issue for the high level language programmer.

> Presumably they do the create-the-file-and-immediately-delete-it trick.
> Since the file must, however briefly, have an entry in some directory.
> General purpose code can't make assuptions about what directories
> are available for writing, so pretty much has to put the entry in
> a known, public place - almost always /tmp or /var/tmp.  Unless one
> does this very carefully, it's open to various attacks.  (For one
> trivial example, there is no way to tell the open() call to *always*
> create a new file - you can only tell it "if the file already exists,
> don't open it, return an error instead".  The code had better check
> for that error and do something appropriate or it can be fooled into
> using a file an attacker created and already has access to.)

Certainly code that does not check for errors is inadequate.

> The techniques for doing this are complex enough - and the attacks
> if you don't do it *exactly* right obscure enough - that after all
> these years, attacks based on "insecure temporary file creation"
> are still reported regularly.  (Frankly, even though I know that
> these problems exist, if you were to ask me to write a secure
> temporary file creator right now, I wouldn't try - I'd look for
> some existing code, because I doubt I'd get it right.)

Which is what one does when using the existing language implementation
(except for the defect reported by Florian Weimer in this thread.
-- 
Larry Kilgallen

From ljknews at mac.com  Sat Dec 30 13:28:13 2006
From: ljknews at mac.com (ljknews)
Date: Sat, 30 Dec 2006 13:28:13 -0500
Subject: [SC-L] temporary directories
In-Reply-To: <87tzzd749x.fsf@mid.deneb.enyo.de>
References: <mailman.1.1167325201.76540.sc-l@securecoding.org>
	<45941379.6000103@ida.org> <Pine.SOL.4.61.0612290916420.8074@mental>
	<45956162.1060405@cert.org> <p05200f16c1bb2a6437cf@[192.168.1.254]>
	<Pine.SOL.4.61.0612291846040.8074@mental>
	<p05200f1ac1bb6db909c2@[192.168.1.254]>
	<87tzzd749x.fsf@mid.deneb.enyo.de>
Message-ID: <p05200f1fc1bc5fbce610@[192.168.1.254]>

At 5:11 PM +0100 12/30/06, Florian Weimer wrote:

>> I gather you are saying that the innards of Unix will force creation
>> of an unwanted directory entry on the Ada implementation of the required
>> null name support for <packagename>.CREATE .  The Ada implementation
>> could rely on exclusive access to the file (surely Unix has that, right?)
> 
> You can create files in a way that fails if the file already exists,
> using the O_EXCL flag.  (Rumors have it that this won't work reliably
> over NFS, though, but I don't see why.)
> 
>> coupled with whatever Unix has that passes for the FAB$V_DLT bit to
>> delete the file on Close (such as at <insert Unix words for image rundown>).
> 
> You can delete open files on Unix, so you could in theory unlink it
> after creation.
> 
> But the whole discussion is moot because existing Ada code seems to
> require that temporary files have names. 8-/

The Ada language does not have such a requirement, and in fact has a
requirement that names are _not_ required for temporary files.

>> But these are problems that have been solved by those who provided the
>> Ada implementation (ACT and Aonix come to mind for Unix), and thus are
>> not an issue for the high level language programmer.
> 
> AdaCore's implementation used mktemp and featured the usual race
> condition.

Yucko !!!
-- 
Larry Kilgallen

From ge at linuxbox.org  Sun Dec 31 21:51:07 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Sun, 31 Dec 2006 20:51:07 -0600 (CST)
Subject: [SC-L] Luis Miras on automated exploit detection in binaries at CCC
Message-ID: <Pine.LNX.4.21.0612312047080.31978-100000@linuxbox.org>

CCC was amazing, and here is the video for one of the lectures.

http://video.google.com/videoplay?docid=-5897236579900914407&q=23c3