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. Fo
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
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
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
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 sy
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
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
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 call
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
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 produ
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
work
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 pro
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
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.
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,
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
st
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 d
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.
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
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
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
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 c
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 end
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)
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
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?
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
wher
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 im
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
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
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
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 i
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 mig
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 langua
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 cor
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 stu
<[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: Secu
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
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
39 matches
Mail list logo
