Re: [SC-L] how far we still need to go

2007-07-25 Thread Blue Boar
William L. Anderson wrote:
 I am flabbergasted. When I first encountered Unix in 1983 I was taught that 
 you
 always run as an ordinary user, and only use admin (root) privileges when
 needed. If OS X developers are running as admin, and building and testing 
 their
 products as admin, well ... I'm still in shock. And I weep for the species.

Are you confusing the Mac specifics? Admin on OS X is not the same as
root. Members of the Admin group can elevate privs to do things as the
equivalent of root, and the Admin group can write to /Applications. The
app in question could improve, of course, but the fact the Admin has so
much power and that the first user you create is a member of that group
is the fault of OS X.

(At least, that's the way it worked not too long ago, Apple does seem to
occasionally fix these things over time.)

BB
___
Secure Coding mailing list (SC-L) SC-L@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.
___


Re: [SC-L] Harvard vs. von Neumann

2007-06-12 Thread Blue Boar
Crispin Cowan wrote:
 Do you suppose it is because of the different techniques researchers use
 to detect vulnerabilities in source code vs. binary-only code? Or is
 that a bad assumption because the hax0rs have Microsoft's source code
 anyway? :-)

I'm in the process of hiring an outside firm for security review of the
product for the day job. They didn't seem particularly interested in the
source, the binaries are sufficient. It appears to me that the
distinction between source and object is becoming a bit moot nowadays.


Ryan
___
Secure Coding mailing list (SC-L) SC-L@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.
___


Re: [SC-L] Harvard vs. von Neumann

2007-06-11 Thread Blue Boar
der Mouse wrote:
 Like it or not, the Web doesn't work right without Javascript now.
 
 Depends on what you mean by the Web and work right.  Fortunately,
 for at least some people's values of those, this is not true.

Obviously, I'm oversimplifying. I claim that there are enough web sites
that require active content to function right (in other words, that's a
big part of the reason they are popular) and that there is a big enough
critical mass of users who want to use those that it's going to stay.

Or another way to put it: First browser that drops support for
Javascript commits market suicide.

(Actually, the ratio of people who want flashy website to those who care
about disabling Javascript is probably 10,000:1, but I digress.)

Ryan
___
Secure Coding mailing list (SC-L) SC-L@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.
___


[SC-L] Harvard vs. von Neumann

2007-06-10 Thread Blue Boar
ljknews wrote:
 It amazes me that someone in a discussion of software security would point
 to a page that requires Javascript to be viewed.

I'm on a couple of mailing list with Dr. Solly, an early antivirus
researcher. he likes to talk about this idea of Grannyx an
(hypothetical) operating system for Grannies that just does what they
need, doesn't have security problems due to simplicity and missing
unneeded features, and doesn't mix data and code.

Then I point to the Web.

Like it or not, the Web doesn't work right without Javascript now. The
world has encoded von Neumann architecture into the standards.

Ryan
___
Secure Coding mailing list (SC-L) SC-L@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.
___


Re: [SC-L] Best practices for encrypting client-side data

2007-05-09 Thread Blue Boar
Robin Sheat wrote:
 Basically, I needed to encrypt the on-disk format of some data that is 
 accessed as a seekable file (it's actually a Lucene index, but the details 
 aren't too relevant). The use case for this is to ensure the data is kept 
 private, even if the disk or computer the data is on is taken (it's a 
 network-aware client app, so they log in to the program using a username and 
 password).

You go on to describe (I think) crypto operations that take place
completely on the client site. What is the relationship between the
encrypted data and server client-server communications?

 * The salt is currently hard-coded. It should be regenerated for every 
 encryption operation in order to make it that much harder (question: should 
 it be a different salt used for every file encrypted by a user, or one salt 
 across all files by that user? Does it matter?)

You should have a random salt every time you generate a hash or key.

 * Is it wise to use the user's password directly, or should that perhaps be 
 used to encrypt a key, and that key used to encrypt the files? This would 
 certainly make changing the password easier, but if that key is ever 
 compromised, it's a bigger issue.

You can get a little extra security with an encrypted keyfile for
certain attack scenarios if done properly. With your design, if I have
only the encrypted file, I can start brute-forcing passwords
immediately. Might not be practical, depending on how big the salt is,
and whether I got that too.

If there's an encrypted keyfile, I have to steal that too, plus I still
have the exact same amount of brute forcing to do. So, the decisions
depends on whether stealing the encrypted data almost always allows me
to steal the keyfile, or if you can do something significant;y better,
like having the user store the keyfile on a USB drive or the remote
server or something.

In order to not have created an irrevocable encryption key, every time
the user changes their password, you should create a new encryption key
and re-encrypt the data with that key, rendering the old stolen keyfile
useless.

 
 * The Java crypto system looks like black-magic. I haven't seen many things 
 that talk about how to use it well. How do I know I'm not using it in some 
 vulnerable fashion?

I can't help you there. I know nothing about Java's implementation
details, nor can I tell if you've created a stream cipher that can be
decrypted by XORing with itself or something else silly.

Ryan
___
Secure Coding mailing list (SC-L) SC-L@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.
___


Re: [SC-L] [Full-disclosure] Chinese Professor Cracks Fifth Data Security Algorithm (SHA-1)

2007-03-21 Thread Blue Boar
3APA3A wrote:
 First,  by  reading  'crack'  I thought lady can recover full message by
 it's signature. After careful reading she can bruteforce collisions 2000
 times faster.

Cracking a hash would never mean recovering the full original message,
except for possibly messages that were smaller than the number of bits
in the hash value. There are an infinite number of messages that all
hash to the same value.

The best crack you can have for a hash is to be able collide with an
existing hash value and be able to choose most of the message contents.

BB
___
Secure Coding mailing list (SC-L) SC-L@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.
___


Re: [SC-L] [Full-disclosure] Chinese Professor Cracks Fifth Data Security Algorithm (SHA-1)

2007-03-21 Thread Blue Boar
3APA3A wrote:
 I  know  meaning  of  'hash  function'  term,  I  wrote  few articles on
 challenge-response   authentication   and   I  did  few  hash  functions
 implementations  for  hashtables  and  authentication  in FreeRADIUS and
 3proxy.  Can  I  claim  my  right  for  sarcasm after calling ability to
 bruteforce 160-bit hash 2000 times faster 'a crack'?

Fair enough, your sarcasm tags didn't render properly in my MUA. I was
fooled by you stating that the birthday attack would be 150 bits.

BB
___
Secure Coding mailing list (SC-L) SC-L@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.
___


Re: [SC-L] [Full-disclosure] Chinese Professor Cracks Fifth Data Security Algorithm (SHA-1)

2007-03-21 Thread Blue Boar
My understanding that the kind of birthday attack under discussion would
start at 80-bits if SHA-1 (at 160-bits) were 100% secure. The attack
under discussion is reported to reduce that to the neighborhood of
60-something bits.

I am not a mathematician though, so I would be perfectly willing to
believe I was wrong about that.

BB

3APA3A wrote:
 Dear Blue Boar,
 
 It's  not  clear  if  this 'crack' cam be applied to birthday attack. My
 in-mind computations were: because birthday attack requires ~square root
 of N computations where bruteforce requires ~N/2, impact of 2000 times N
 decrease  for birthday is ~64 times faster. 64 = 2^6. Because complexity
 is ~square root of possible combinations, it's equivalent of traditional
 birthday  attack,  with  160-(2*6)=148  bits  hash (150 is my mistake in
 in-mind computations).
 
 Of  cause,  since  I  completely  wasted 10 years after obtaining Master
 degree  in  Mathematics  and  3 years after loosing last pencil I may be
 completely wrong in computations :)
 
 --Wednesday, March 21, 2007, 9:48:55 PM, you wrote to [EMAIL PROTECTED]:
 
 BB 3APA3A wrote:
 I  know  meaning  of  'hash  function'  term,  I  wrote  few articles on
 challenge-response   authentication   and   I  did  few  hash  functions
 implementations  for  hashtables  and  authentication  in FreeRADIUS and
 3proxy.  Can  I  claim  my  right  for  sarcasm after calling ability to
 bruteforce 160-bit hash 2000 times faster 'a crack'?
 
 BB Fair enough, your sarcasm tags didn't render properly in my MUA. I was
 BB fooled by you stating that the birthday attack would be 150 bits.
 
 BB   BB
 
 
___
Secure Coding mailing list (SC-L) SC-L@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.
___


Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?

2007-03-06 Thread Blue Boar
Kenneth Van Wyk wrote:
 So, I applaud the public disclosure model from the standpoint of
 consumer advocacy.  But, I'm convinced that we need to find a process
 that better balances the needs of the consumer against the secure
 software engineering needs.  Some patches can't reasonably be produced
 in the amount of time that the vulnerability pimps give the vendors.

From the outside, it looks like the vast majority of the patches take as
long as the vendor feels like taking. With a small percentage of
vulnerabilities being released with no vendor warning at all. It's
relatively unusual that I see bulletins where the researcher releases
saying that the vendor took too long, so they are releasing now.

But that's just going from memory, I haven't done a proper survey or
anything.

BB
___
Secure Coding mailing list (SC-L) SC-L@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.
___


Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?

2007-02-27 Thread Blue Boar
J. M. Seitz wrote:
 On a related note, does anyone have an example where Company A was
 disclosing vulnerabilities about competing Company B's product and got into
 trouble over it? Is this something that could be litigated?

In fact, Tom Ptacek found a hole in one of Marcus' products while
working for a competitor. I suspect Tom reported it properly, though.

This research pissed MJR off to no end, which he made clear at one Black
Hat talk he gave, with Tom standing at the back of the room.

I suspect this was a key point in MJR's life when his code got touched
in an inappropriate way, and has led to his current level of curmudgeonry.

Or, for a more contemporary example, witness Symantec researchers
looking for holes in just about everything.

I fail to see any merit for a legitimate lawsuit. Of course, in the US,
you can sue whomever you please.

BB
___
Secure Coding mailing list (SC-L) SC-L@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.
___


Re: [SC-L] On exploits, hubris, and software security

2006-11-03 Thread Blue Boar
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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] bumper sticker slogan for secure software

2006-07-20 Thread Blue Boar
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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Segments, eh Smithers?

2006-04-04 Thread Blue Boar

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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Bugs and flaws

2006-02-03 Thread Blue Boar

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
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] re: Why Software Will Continue to Be Vulnerable

2005-05-03 Thread Blue Boar
Bill Cheswick wrote:

Probably like many of you, I'm the local friends-and-family computer
fixit guy.

 My father has repeatedly asked why he should care that his computer is totally
 owned.  I've told him that his CPU engine is blowing blue smoke all over the 
 Internet,
 but that doesn't help.

I think people would care if they knew, but they don't know.

 An outbreak of user-obvious malware might change the equation, but I am not 
 suggesting
 that someone run the experiment.

I think just about the only time I've been called out to lay hands on
someone's computer in the last two years (with one exception I can think
of), the problem has been malware/spyware.  I.e. it had misbehaved to
the point where it was untolerable.  The browser no longer works, the
machine grinds to a halt, the screen goes wonky (screwed up the video
drivers), it's popping porn ads at the kids, etc...

So my assertion is that much of the malware is very obvious.  I'll avoid
the temptation to rant at the poor quality of the malware/spyware code
itself.  I'll also add that I think this is the current big problem for
Windows users.  Windows itself (XP+) has become reliable *enough*, and
the hardware reliable enough (or cheap enough to suffer a forklift
upgrade), that it works great... except for the damn malware.

The typical reaction I get is incredulity that there are people who sit
around all day writing this stuff (malware/spyware.)  Any consideration
that there's a fault with the OS that allows it in is waaay down the list.

So if MS can find a way to make the effects of malware unobservable,
then they just about have that market sewn up.

Ryan




Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-07 Thread Blue Boar
Michael Silk wrote:
 See, you are considering 'security' as something extra again. This is
 not right.

It is extra.  It's extra time and effort.  And extra testing.  And extra
backtracking and schedule slipping when you realize you blew something.
 All before it hits beta.

Any solution that ends up with us having secure software will
neccessarily need to address this step as well as all others.  The
right answer just might end up being suck it up, and take the
resource hit.  It might be switch to the language that lends itself to
you coding securly at 75% the productivity rate of sloppy coding.  I
don't know enough about the languages involved to participate in that
debate.

Strangely enough, for the last year and a half or so, I've been sitting
here being QA at a security product company.  Doing software right takes
extra resources.  I are one.

 Ryan




Re: [SC-L] Programming languages used for security

2004-07-14 Thread Blue Boar
ljknews wrote:
At 11:38 AM -0700 7/13/04, Blue Boar wrote:
ljknews wrote:
The environment with which I am most familiar is VMS, and tradition
is what guides secure interfaces.  Inner mode code _must_ probe any
arguments provided from an outer mode, probe the buffers specified
by descriptors provided, etc.
What do you do when you're handed a bad pointer?

Return SS$_ACCVIO.
So you put in an error handler that catches access ciolation before you 
try to use the pointer?  OK, fair enough.  What if the pointer points to 
memory you own, but not the right kind?  I have always been under the 
impression that raw pointers could always cause you problems.  I've 
assumed that a secure language would have to eliminate that as a type.

BB



Re: [SC-L] Programming languages used for security

2004-07-13 Thread Blue Boar
ljknews wrote:
The environment with which I am most familiar is VMS, and tradition
is what guides secure interfaces.  Inner mode code _must_ probe any
arguments provided from an outer mode, probe the buffers specified
by descriptors provided, etc.
What do you do when you're handed a bad pointer?
BB



[SC-L] Secure Coding Themes

2004-07-12 Thread Blue Boar
So in all the discussions, I think I'm seeing several main themes:
-Some holes are design or logic errors (possible in any language)
-Some holes are failures to code safely in a given language (language 
specific; possibly addressable by switching to a safer language)
-Some holes are harder to implement in a safer language (library, 
class...)

And I'm sure I've missed a few important ones.
Point is, I think in a number of cases, we mix these concepts in the 
same discussion, and I'm not sure that's always useful.

If we're talking about logic problems... you can always get your boolean 
conditional jump backwards, doesn't matter what language you use.

If we're talking about one flavor of secure coding (coding safely in a 
dangerous language), then that discussion/class neccessarily needs to 
be very language specific.  This problem also extends to things like 
system APIs, libraries, and so on.  I don't know that any significant 
project can get away from that, regardless of the main language used.

If we're talking about secure coding in terms of picking a language that 
should help us not make whole classes of mistakes, then that's a 
different discussion.

		BB


Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

2004-07-08 Thread Blue Boar
Jose Nazario wrote:
rather than talking in a vacuum, make sure you've read the latest
ACM/IEEE-CS curriculum guidelines:
http://www.acm.org/education/curricula.html
http://sites.computer.org/ccse/
Hrm.  I checked both pages, and searched for secur, and got nothing. 
I didn't click every link... security is mentioned briefly in a couple 
of places in the ACM strawman.

Was that your point?
BB



Re: [SC-L] Education and security -- another perspective (was ACM Queue - Content)

2004-07-08 Thread Blue Boar
Fernando Schapachnik wrote:
I smell a discusion going nowhere. What is the point of teaching a languague?
Teach them to program in a paradigm (better, in all of them, and give them the
tools to make educated choices about which is better for each context), and
choose any language as an *example* of the paradigm.
Ah... but beyond design problems, aren't most security problems 
language-specific abuses and bugs?  I'm thinking things like I didn't 
realize it would let me mix signed and unsigned... I didn't realize it 
would let me right off the end of the buffer... I didn't realize I had 
to escape or filter certain characters

BB



Re: [SC-L] ACM Queue article and security education

2004-07-02 Thread Blue Boar
Peter Amey wrote:
I'm not entirely sure I follow this.  I _think_ you are saying:
since we can't be sure that X is perfect (because it might have 5
remaining flaws) then there is no point in adopting it.  You seem to
be saying that it doesn't matter if X is _demonstrably_much_better_
than Y, if it is not perfect then don't change.  Have I got that
right?
No.  I was claiming that languages that allow for safety and verifiction 
can't neccessarily be trusted 100%.  There will always be a last few 
bugs.  As I said in my note that you replied to, that doesn't 
neccessarily mean you don't use it.  The other part of my note had to do 
with the last few bugs not coming to light until *everyone* is using 
that language.  Also not a reason to not go ahead and use it now, since 
the sooner the world starts to switch, the sooner you kill the last few 
bugs.

I think you were reacting to the one sarcastic part of my note, which 
essentially says good luck getting the world to switch.

BB



Re: [SC-L] ACM Queue article and security education

2004-07-01 Thread Blue Boar
ljknews wrote:
I think it will be properly considered when the most strict portion
of the software world is using language X.   I have used many
programs where the flaws in the program make it clear that I care not
one whit about whether the authors of that program have opinion about
anything I might use. They are simply not competent, either as
individuals or else as an organization.
By most strict portion, do you mean people that care most about 
correct code, proofs, and such?  I don't deny that the bulk of the heavy 
lifting will be done by people well-qualified to do so.  However, I'm of 
the school of thought that certain types of people who like to break 
things, and whose chief skill is breaking things, will always have a 
decent shot at finding a problem.  There are people who couldn't build 
it, but they can sure break it.

You don't typically get their attention until something is really, 
really popular.  So yes, you can write your stuff in Language X, and 
assume it's secure.  It might not actually be until the whole world has 
had its way with Language X, but (hopefully) that's not a problem.  You 
can still do the dance of patching the last 5 problems in Language X, 
and end up better off that if you'd just used C.

Even Knuth has to write checks ocassionally, and he does a lot of proof 
work, doesn't he?

So, if Language X only has 5 problems total, even if it takes years to 
ferret them out, butthey are fixable, please proceed with getting the 
whole world to use Language X.

BB