> Maybe this was always clear, but along with that reassurance I guess
> you would recommend we all take your stated remedial action :
>[place] the following directive in sshd_config and ssh_config:
>"Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc"
> at the very next
> Not really - what I am not doing is trying to beat up a firmware
> problem that whilst being quite bad can be mitigated by using native
> features of Solaris. Too bad if OpenBSD cannot do the same - I am not
> really sure about the benefits of OpenBSD on that scale of hardware
> anyway consideri
>
> Yet you don't know what it is that causes the issue? What's Sun's
> support arrangement for OpenBSD on SPARC? If it is reproduced in
> Solaris, then I'm sure Sun would address it, but where is the benefit
> for them to do so at present?
It's not about OpenBSD on sparc - the OpenBSD
>
> Isn't it the case with every software created to add some protection
> to you computer? Firewalls, antiviruses, IDSes etc. are all adding
> code to your operating system that may, in the future, be found
> vulnerable to some attack. It is just the question whether protection
> they provide com
* Jex <[EMAIL PROTECTED]> [2007-03-09 13:27]:
...
> >rules similar to Snort ones to describe browser based attack
> >attempts.
> > All incoming HTTP and HTTPS traffic is scanned with these
> >rules. HTTPS and compressed responses are scanned after
> >decryption/decompression.
So the next s
> that vuln is about as useless as the dhcpd vuln I found. I guess it's good
> for practice, but why would you brag about finding that
Since it was a vulnerability that bugtraq could post immediately
since they didn't have to alert their corporate sugardaddies about it
first ;)
>
> You're confusing what I'm interested in (platform security) with
No, I'm not confusing it at all, I'm saying it's a non-issue. Any
Von Neuman type of architecture is "secure" - it does exactly what you
tell it to do. If you don't tell it to do insecure things. it does
not. If it's no
> > The simple fact is most of the MS/PHP/JAVA web development will be
> > being done by code monkeys, fresh out of school..
>
> You're confusing what I'm interested in (platform security) with
> the people who use the platform to develop on top of. If the
> foundations of what you're using
> And I think vulnerabilities disclosed are a much better indicator
> of the changes to QA/development of products than any hyperbole
> from those responsible (be it management or developers.)
No, I think vulnerabilities disclosed is simply a measure of how much
development and deployment
> If the number of vulnerabilities is graphed over time, is either
> heading down or both heading up or...?
>
> - I'm not asking for a "who's better", I just want to know if
> anyone has a good set of numbers and if they're graphed for easy
> comparison.
>
>
> p.s. LAMP = Linux/Apache/MySQL/PH
> As many of us know, handling such users on tech support is not very
> cost-effective to ISP's, as if a user makes a call the ISP already
> losses money on that user. Than again, paying abuse desk personnel just
> so that they can disconnect your users is losing money too.
>
> Which one would
ith a stick.
SSL/TLS applications are just the latest most fertile ground where
software designers have put in a crutches for lazy stupid people thereby
rendering something kinda ok into something mostly useless.
-Bob
--
Bob Beck
>> [users getting out of sync and passwords getting logged]
>Not always. I can think of one Windows SSH client off the top of my head
>that will prompt for the username and password seperately - SecureCRT. I'm
>sure there are others as well that I'm just not thinking of right now...
Well, th
> (1) Root installs the malicious roff source unknowingly.
>
> (2) During the process of building/installing the program,
X
> at which point the trojan
> horse does it dirty work.
s/X/configure runs some stuff/
s/X/Make runs some stuff/
s/X
14 matches
Mail list logo
