Re: [SC-L] Anyone looked at security features of D programming language compared to Spark?

[Blue Boar]

Crispin Cowan wrote:
Dynamic type checking (or any kind of run-time fail-stop checking) 
enhances security (attacks are halted) but degrades reliability 
(processes that might live with a harmlessly inconsistent state may be 
halted).
Degrades reliability of a "correct" program?  Or only degrades 
reliability of a program with bugs, harmless or not?  If it's the 
latter, I would assume QA would want to see the latter, so the bug could 
be squashed.  I'm assuming, of course, that one wants to also squash 
"harmless" bugs.

	BB

Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness

[Blue Boar]

ljknews wrote:
Okay, that's a bold statement.  I'd better back it up.  If you have a
string-handling library of any kind, someone's going to come up with a
program design that builds a twenty character string for a person's name,
putting first name in the first ten characters, and last name in the last
ten characters.  Eric Smith changes his first name to Navratilova, and he's
suddenly listed by the program as "Navratilovamith amith" - buffer overflow.
Sure, it doesn't overflow into the stack, but it overflows into important
data.
How does the buffer overflow "into important data" using "any language" ?
With Ada and Pascal a 20 character array just has no syntax for storing
a character into the 21st position.  While it is true you will get a
(possibly unanticipated) runtime exception rather than pleasing results,
there is no opportunity for pleasing results in this situation.  The
clever programmer may add an exception handler to display a user friendly
message like "get a name change" rather than the default "index out of
bounds" or whatever.  But neither the clever nor the lazy programmer
gets an overflow "into important data".  The boundary condition is
detected and prevented from causing totally obscure failures.
I think you failed to parse the example provided.  He gave an example 
where he has imposed an arbitrary structure on the built-in string, and 
violated it.  I think he blew the example, as I'm reading it.  I *think* 
he meant:

"Eric  Smith "
becomes
"Navratilovamith "
Thereby blowing his "buffer", and maybe screwing the rest of the program 
logic.  He didn't overflow at the string class level, he did so at the 
logic level.  Or his derived string class, or however you like to think 
of it.

BB

Re: [SC-L] Origins of Security Problems

[Blue Boar]

<[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Secured by aspStation
Sender: [EMAIL PROTECTED]
Precedence: bulk
Mailing-List: contact <[EMAIL PROTECTED]> ; run by MajorDomo
List-Id: Secure Coding Mailing List 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
List-Help: 
List-Archive: 
Delivered-To: mailing list [EMAIL PROTECTED]
Delivered-To: moderator for [EMAIL PROTECTED]

ljknews wrote:
> A significant difference from DECnet is that with TCP/IP any user on the
> system can open up a channel (to use a neutral term) to receive incoming
> traffic, potentially providing a capability to the outside world without
> the least bit of authentication.  With DECnet (Phase IV or Phase V) on
> VMS such actions require getting a special privilege from the system
> manager (potentially granted to a specific program rather than to the
> programmer).

Hm?  You mean they had to have privs on VMS to allocate a listening
port?  What does that matter?  DECNet doesn't only run on VMS.  Years
ago, I used to be a network admin at a place that had thousands of Win95
and Mac boxes running DECNet.  No such restriction, there.  Had it been
DECNet/OSI that won instead of IP, I don't believe there would be any
significant difference.

BB

Re: [SC-L] SPI, Ounce Labs Target Poorly Written Code

[Blue Boar]

Kenneth R. van Wyk wrote:
The article quotes SPI Dynamics' CTO 
as saying, "It doesn't require developers to learn about security," which 
strikes me as being a rather bold statement.
I seriously doubt that there is a programming language that can do 
anything useful that one can't do something stupid with.  Never bet 
against the quality of idiots available in the world. :)

BB

Re: [SC-L] SPI, Ounce Labs Target Poorly Written Code

[Blue Boar]

Peter Amey wrote:
I would assert that using SPARK it is very /hard/ to something stupid
and /impossible/ to do something stupid that wouldn't be obvious to
the SPARK Examiner tool.  In fact, the only way I can think of doing
so would be to construct a formal specification for stupidity and
then correctly implement it (which is clearly feasible).
To clarify, I'm talking about things like passing unfiltered user input 
to a system shell, or a native API, something like that.  I wasn't 
neccessarily referring to blowing up your buffers, etc...

If SPARK is designed to stop things like that, then I'll happily go and 
try to do something stupid in it...

My basic point (which I probably made poorly) is that a language that 
keeps one from blowing up their buffers, getting their signs wrong, 
etc... won't help logic errors and bad design.  I have nothing against 
"secure" languages, and I'd be happy to see them in wider use.  I was 
just sceptical about these libraries under discussion that can keep 
someone from introducing security holes.

BB

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

[Blue Boar]

Peter Amey wrote:
There are languages which are more suitable for the construction of
high-integrity systems and have been for years.  We could have
adopted Modula-2 back in the 1980s, people could take the blinkers of
prejudice off and look properly at Ada.  Yet we continue to use
C-derived languages with known weaknesses.
So we trade the known problems for a set of unknown ones?  It might be 
appropriate to do so; C may be "broken" enough that it's better to go 
for an unknown with a design that allows for a possible correct 
implementation.  I keep thinking of Java, for example.  It's a good 
paper design for security purposes (I'll leave functionality alone for 
now.)  But there are still all the issues with the VM implementation and 
libraries to deal with.

Language X may very well be a much better starting point, I don't know. 
 I do believe that it will never be properly looked at until the whole 
world starts using it for everything, though.

BB

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

[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

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

[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] Education and security -- another perspective (was "ACM Queue - Content")

[Blue Boar]

ljknews wrote:
What is wrong with this picture ?
I see both of you willing to mandate the teaching of C and yet not
mandate the teaching of any of Ada, Pascal, PL/I etc.
This seems like the teaching of "making do".
There's something better for teaching about stupid programming tricks 
than C?  The way I read it, they were both advocating teching what 
screwing up in C looks like in assembly.  This does not preclude 
teaching good programming in a safer language, and has the advantage 
that those who will be working in C can do better in that, too.  I would 
hope a secure programming course would cover what TO do and what NOT TO do.

BB

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

[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")

[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

[SC-L] Secure Coding Themes

[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] Programming languages used for security

[Blue Boar]

der Mouse wrote:
This is not to say that moving up levels is worthless.  But it sounds
to me as though everyone in this discussion is stuck in some kind of
mindset like "if we can just eliminate $CLASS_OF_ERROR, we'll have a
safe and secure programming language".  We won't; we'll just have one
where the unsafe and insecure errors are at a higher level.
Right, that's the game.  We want all the errors to be design and logic 
errors, with no help from the programming language.  (i.e. we don't want 
the programming language to be permitting us to make extra errors.)

The goals should be that 100% of the security problems are design 
errors. :)  Then we can go teach people to design properly...

BB

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

[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

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

[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] Mobile phone OS security changing?

[Blue Boar]

Michael Silk wrote:
> The last thing I want is my mobile phone updating itself. I imagine
> that sort of operation would take up battery power, and possibly cause
> other interruptions ... (can you be on a call and have it update
> itself?)

A larger issue for me (though I'm straying a bit from SC) is that phone
vendors tend to show a strong desire for lock-in, and I would fear
auto-update mostly because of loss of features, DRM, etc...

 Ryan

[Ed. Let's either stay on topic or let this thread die, please.  KRvW]

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

[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] Java keystore password storage

[Blue Boar]

john bart wrote:
> Hello to all the list.
> I need some advice on where to store the keystore's password.

I don't know the Java functions you're asking about.  Looks like it's
decrypting a file?

It's not possible to securely store the password.  If a program can
decrypt the file, then a program can decrypt the file.  Unless you want
to go for a very narrow definition of "securely store".

Windows has a facility for "secured storage" that becomes accessible
when the user logs in.  It's used for storing sensitive information,
like other passwords.  It's theoretically good for protecting your info
when the machine is off, or a different user is logged in.

Ryan

Re: [SC-L] Java keystore password storage

[Blue Boar]

David Crocker wrote:
> I'm by no means an expert in the field of security and Java, but I believe 
> that
> the usual technique is to encode the password that the user types using a 
> 1-way
> hashing algorithm, then store (and hide/protect) the encoded version and use
> that as the password. If an attacker manages to read the password hash, he 
> still
> has to construct a password that will encode to the same value.

That only works if you're the "server", or more accurately, the process
that needs to verify the password.  If you're the "client", or the
process that needs to supply the password, that doesn't help you.

Ryan

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

[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] Spot the bug

[Blue Boar]

der Mouse wrote:
>>http://msdn.microsoft.com/security/
> Heh.  They want us to do their code review for them?

Did you look at it?  The current one is a 4-line toy bug.  It's a
contrived example, and theposter obviously already knows there is a bug.

You think they are going to work their way up to:
"Umm... great so far, readers.  Now look at these 10,000 lines and tell
us where the bug is..."?

Ryan

Re: [SC-L] eWeek says "Apple's Switch to Intel Could Allow OS X Exploits"

[Blue Boar]

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
___
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

[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] Segments, eh Smithers?

[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] bumper sticker slogan for secure software

[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] On exploits, hubris, and software security

[Blue Boar]

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.)
___
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] On exploits, hubris, and software security

[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] Dark Reading - Discovery and management - Security Startups Make Debut - Security News Analysis

[Blue Boar]

ljknews wrote:
> Analyzing source code is independent of machine architecture.
> 
> My guess is that if a company actually is capable of analyzing
> binary code they only do it for the highest volume instruction
> sets.
> 
> My guess is that attackers will go after machines they feel are
> less protected.
> 
> Efforts which merely change attacker behavior are a waste of time.

Nope. If I'm running x86 boxes, I'd be more than happy to have to
attackers move to SPARC.

Besides, once a bug is found in the x86 binary, the problem gets fixed
in the source and/or compiler.

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?

[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] Disclosure: vulnerability pimps? or super heroes?

[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] [Full-disclosure] Chinese Professor Cracks Fifth Data Security Algorithm (SHA-1)

[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)

[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)

[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] Best practices for encrypting client-side data

[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.
___

[SC-L] Harvard vs. von Neumann

[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] Harvard vs. von Neumann

[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.
___

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

[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] how far we still need to go

[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] Insecure Software Costs US $180B per Year - Application and Perimeter Security News Analysis - Dark Reading

[Blue Boar]

Andy Steingruebl wrote:
> I like contractual approaches to this problem myself.  People buying
> large quantities of software (large enterprises, governments) should
> get contracts with vendors that specify money-back for each patch they
> have to apply where the root cause is of a given type.  For example, I
> get money back every time the vendor has a vulnerability and patch
> related to a buffer overflow.

That changes the incentive to hide security bugs and not patch them or
to slipstream them.

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.
___