Tom's Random Thoughts

4th German OWASP Security Day

2011-09-22T00:06:00.000-07:00

My submission to the 4th German OWASP Security Day was accepted. Now let's see if we can accept their OWASP license that needs to be signed...

kostenloser Counter

I am leaving the SUSE Security Team...

2011-09-21T02:14:00.000-07:00

After 12 years I am leaving the SUSE Security-Team... just to support them! :-)

Like a satellite I was spun-off from mother earth. Flying around the SUSE Security Team as project-manager to take care of our products before they get released working hand-in-hand with Marcus and his team that (mostly but not exclusively) takes care of the security of already released products.

kostenloser Counter

Scanny will replace the ror-sec-scanner

2011-07-26T02:10:00.000-07:00

David and Flavio created a new github project to replace my ror-sec-scanner. "Scanny" doesn't uses regex but the AST and emits fewer false positives. So lets start adding rules/checks to it to become more powerful.

kostenloser Counter

SUSE Manager Security Update

2011-06-17T02:38:00.000-07:00

Last Friday we released a security update for SUSE Manager. It eliminates four vulnerabilities which I will describe in detail here:

CSRF (CVE-2009-4139): This is the most dangerous issue fixed by this update. It was found during a penetration-test executed by me before we released the SUSE Manager. You may wonder why we released the fix after the "gold master" (GM) and why it has a CVE-ID from 2009. Red Hat was informed about this issue in 2009 already (by another person) and after some back and forth we decided to release it together with Red Hat and not earlier. But not only the release date was coordinated, we also coordinate fixing and testing.
The default SSL ciphersuite configuration that comes with our apache2 package (this also affects the SM proxy) was made up to support as much and as old client as possible. This results in a config that is insecure because it support "export ciphers", SSLv2, short keys, etc. If you install this update before you configured your SM you will have a up-to-date and secure config. Use sslscan to verify your setup. If it is still insecure go to /etc/apache2/ssl-global.conf and change it to something like:
ssl_protocols TLSv1
ssl_ciphers ALL:!aNULL:!eNULL:!SSLv2:!LOW:!EXP:!MD5:@STRENGTH
Open Redirect (CVE-2011-1594): A hidden field named "url_bounce" allows HTTP redirects and therefore phishing attacks. Found during penetration-test, released after GM because it was too minor to hold release.
XML remote denial of service (CVE-2011-1755): jabber2 server can be dos'ed ("billion laughs attack"), not found by us.

kostenloser Counter

SAD 4: Security Day

2011-05-24T00:00:00.000-07:00

Three weeks ago the SUSE Studio team had its first "Security Day" to fix the possible security vulnerabilities found by ror-sec-scanner. (a Rails static code analyzer)
The team eliminated:

161 false positives
28 real bugs

Thank you folks! :-)

Note: Earlier this year another team consolidated its forces to fix potential security problems in their code and reduced the number of bugs per KLOC to 0.

I hope we can have a "Security Day" prior every new release.

kostenloser Counter

SAD 3: At the Beginning there was a Thought

2011-05-03T12:57:00.000-07:00

Last night I stumbled over some old docs of the Security Review Board. More than 5 years ago T.G. puts much effort in enhancing the development processes to create more secure products. I never saw numbers about that project to compare pre and past states of the products. Unfortunately she left a few years later but AFAIK some of her work is still in use today.

Today I browsed Google Docs and found a 2 year old presentation I wrote during a train journey from Nuremberg to my home town. I never want to show the slides to other people I just brainstormed about how we could integrate security into our products. Let me show you some slides here because they describe where we were 2-3 years ago. As I said I forgot the slides but funnily various things from them are real now or are on my TODO list.

Slide 1: Where we are.
- We have four different sources of code
-- 1.) Mainly FLOSS
-- 2.) In-house development
-- 3.) 3rd-party commercial free binary code (like RealPlayer, acroread, etc.)
-- 4.) 3rd-party code developed by contractors
- We review FLOSS code but there is too much and we have not much
influence on the developers beside sending patches upstream
- We have much influence on our own developers but we have to develop
a better security awareness as well as technical knowledge
- We have no influence on the 3rd-party free binary code and just need
to trust it.
- Code developed by contractors can be reviewed by us

Today source 1. is still the main source for code contributions, the in-house development (2.) increases a lot over the past years, we try to reduce (openSUSE is completely free of them, see the NonFree repo) the number of binary-only packages (3.), I am not aware of current contributions from source 4.
In the past we provided workshops for secure programming (C, C++, Shell, Perl, Ruby on Rails, Web-security in general).

Slide 2: Where others are.
- Microsoft
-- founder of the Secure Software development Life Cycle (SDL)
-- Separate, specialized teams
-- Own and optimized tools for stress-testing (fuzzing) as well as code analysis
-- See BSIMM study [1], [2]
- Cisco
-- CMSDL
- Adobe
-- See BSIMM study [1], [2]
- Google
-- specialists/teams working on research topics and develop tools as well as guidelines
-- See BSIMM study [1], [2]
- Red Hat
-- Specialized teams/persons
-- Much more people working on security
-- Better contact to developers?
-- Only re-active not pro-active AFAIK

Currently we are introducing secure SDLC techniques and testing tools for our in-house products. Teams are planned to grow.

Slide 3: We need to catch up because...
- Releasing patches for avoidable bugs is a big waste of money and time
- Customers critically watch software vendor's product quality and security vulnerabilities
- These observations play a big role in buying new products or continuing support contracts because installing patches costs the customer money (see study "The Total Cost of Security Patch Management") and therefore increases the cost of the product.

Slide 4: What we can do now!
- Increase awareness by:
-- Showing consequences by providing examples of security problems in our code
- Increase code quality by:
-- Online teaching of security best practice rules for common programming languages like C, C++, C# and Java (see CERT's SDI)
-- Adopt secure SDLC processes for our in-house development
-- Provide a standard development environment that includes easy-to-use code analysis tools for our programmers
-- Teach how to use this tools.
-- Do more sophisticated code analysis

We are on the right track.

Slide 5: What we need to do in the future.
- Develop/acquire better tools for code analysis, fuzzing, etc.
- Incrementally refine our coding standards
- Have separate teams for handling bugs (response team), create new tools and keep track of current software security development (research team), a team for shepherding code development (mentor team) and a pen-testing team to verify in-house, FLOSS code
- Being part of secure development initiatives/groups/workshops

Well different teams is a dream that will never become true, but we will try to reach our goals using another way.

Slide 6: Where we should be.

kostenloser Counter

SAD 2: Security Awareness or melting Realities together

2011-03-25T10:33:00.000-07:00

Most people know that smoking causes cancer, that eating too much and not doing sports increases the probability of a cardiovascular disease, that drinking too much is bad for your psyche and lever and so on.

But does just knowing about it change their behavior? No, it does not!

The reason is that these "invisible" negative effects do not influence their living, the integrity of their reality is intact until it is too late and the disease dramatically decrease the quality of their life.

Only a few people are clever and strong enough to reflect about their bad behaviors and change them. I assume more people change their bad habits as soon as they see what happens to their body. Seeing means measuring the cardiovascular levels, taking x-ray pictures of organs, making chemical analysis of body liquids and tissue and so on.

I see a strong analogy here to software development and security.

Developers and project-managers often do not have security in mind, or do not have the technical background and daily practice to make the resulting product a nightmare for penetration-testers and hackers. (How often do you read this already?)

Let's not stress this doctor vs. patient analogy too far. This blog entry is not about good vs. bad or dumb vs. clever... it's about the experience I made and psychology.

First of all, measurement (of the right things) is the key to success! You do not have to create a bulletproof plan, just some goals, continue measurement, and adapt your plan (Hello agile development/management!).

I hold three talks/workshops in 2010, every talk has the same topic: "secure design and development" and I got the same result: Code quality did not increase! The number of potential security bugs per 1000 "physical" LOC (Hits/KSLOC) stayed the same or even increased.
Based on the responses from my audience I experimented with the content and with the methodology. The first workshop was very long and mostly theoretical with threat models, potential problems in Rails, risk assessment, showing some tools (which gets the most attention, because it potentially helped solving their problems).
The second one was much more practical, I had shown real examples from the in-house software projects, real attacks and presenting some tools. The session was much shorter and caused more attention by the developers and a bit more attention by the technical managers (Still, tools caused the the most attention). And the last one... the last one was a wake-up call, less technical, analogies and examples, cost of security updates (Attention!) and I hit the target.

Result: The first talk was a waste of time, my statistics had shown no decrease in the potential vulnerabilities, the second one also had no affect on quality but the awareness and communication (developers) increased, and the third talk... well the code quality did not increase but awareness and maybe acceptance in the upper food chain increased.

Retrospectively I can say I should have done the talks/workshops in reverse order but when I started is was a "fire-fighter job" and I had no time for a real plan.

Code quality is still a critical issue and therefore I took the next, more aggressive step by sending the (cleaned-up) results of my code scanner to the developers mailing list. And at least one team responded to it and we reduced the number of potential security problems and false positives to a minimum within just two weeks. In the meanwhile all teams responded in some way and I hope code fixing will start soon.

On balance:

If you want to increase awareness, invite the right people and omit technical details, speak the language of the audience, use numbers (costs) and statistics, use analogies instead of theoretical information. Melt realities by creating feelings and concernment! (The last point is not easy to do of course.)
If you want to increase code quality, use tools that directly show the problematic code with a description and help fixing it! Don't create too much confusion and don't steal the developer's time.

BTW, the increase of awareness or the expertise of the developers resulted in adding security features and fixing existing security features...

kostenloser Counter

Oops, RSA hacked and SecurID code stolen?

2011-03-18T03:43:00.000-07:00

http://www.rsa.com/node.aspx?id=3872

kostenloser Counter

Forgotten Password and Birthday Attacks

2011-03-16T08:02:00.000-07:00

I just stumbled over a piece of code that might be interesting for you as well. A web-app let's click you on a "forgotten password" link and will send a token to the (valid/known) email address you specified. When you return to the web-app and provide the token that was mailed to you, and the token was found by looking it up for ANY user, you are allowed to set a new password. So, theoretically (I didn't test it) this code is vulnerable to a birthday attack (random pair collision), the impact depends on the number of users and the length of the token.

For example, and I hope I get the math correct here, if the token is 8 bit long (8 bit of entropy, equally distributed) an attacker only needs to call the "forgotten password" functionality for 16 (birthday bound, 2^{n/2}) users and try 16 different tokens to have a probability of success close to 50%.

The solution is to look-up the user by email address or another unique identifier and verify if the token for this user matches or not.

Here is an example diagram for a 16 bit token (DNS TRXID) to compare brute force vs. birthday attack.

kostenloser Counter

Comdirect bank TAN handling

2011-03-10T02:15:00.000-08:00

Just recognized that the web-app for Comdirect online banking does not ask for another TAN if you choose back and change the bankwire details like the recipient. Execution flow:

Enter bankwire details ---> click next ----> asked to enter TAN n ---> click back ----> change bankwire details ----> click next ---> again asked for TAN n

I would generate a new TAN...

kostenloser Counter

Mail: recent security breaches of open-source sites

2011-01-28T06:08:00.000-08:00

This mail was sent out to some opensuse mailing lists to increase awareness.

Dear community members and contributors,

in the last few month we saw security breaches at gnu.org[1], at
sourceforge.net[2] and at fedora[3].

Even if it is believed that the integrity of the hosted projects
was not affected I want to take the opportunity to remind you to
always verify the cryptographic checksums of downloaded archive
files, review patches and keep a healthy relationship/communication
to the upstream authors.

It is good practise to change your password from time to time and make
it hard to guess[4][5]. Take extra care using public wifi hotspots,
crowded places[6], like trains, and other peoples computer etc.

Cheers,
Thomas

[1] http://blog.sucuri.net/2010/11/savannah-gnu-org-hacked-and-currently-offline.html
[2] http://sourceforge.net/apps/wordpress/sourceforge/2011/01/27/service-downtime/
[3] http://lists.fedoraproject.org/pipermail/announce/2011-January/002911.html
[4] http://en.wikipedia.org/wiki/Password_strength
[5] http://sourceforge.net/projects/pwgen/
[6] http://en.wikipedia.org/wiki/Shoulder_surfing_%28computer_security%29

kostenloser Counter

Tool: OWASP test-suite

2011-01-12T05:44:00.000-08:00

A happy new year!

I quickly hacked a test-suite based on the OWASP testing-guide. You can find the code here: http://gitorious.org/sectestsuite/websec

Take care, this time it is untested, incomplete and unfancy.

prompt> src/websec.pl myconfig.ini output=short
=====> OWASP_CM_001::sslv2: CWE-XYZ (): code = 0 (msg = 'PASS')
=====> OWASP_CM_001::weak_ciphers: CWE-327 (Use of a Broken or Risky Cryptographic Algorithm): code = 0 (msg = 'PASS')
=====> OWASP_CM_008::http_dangerous_methods: CWE-749 (Exposed Dangerous Method or Function): code = 0 (msg = 'PASS')
=====> OWASP_CM_008::http_arbitrary_methods: CWE-749:CWE-650 (Exposed Dangerous Method or Function:Trusting HTTP Permission Methods on the Server Side): code = 1 (msg = 'FAIL:HTTP arbitrary/dangerous methods allowed (UNLOCK)')
=====> OWASP_CM_008::http_bypass_head: CWE-650 (Trusting HTTP Permission Methods on the Server Side): code = 0 (msg = 'PASS')
=====> OWASP_AT_002::user_enumerate: CWE-204 (Response Discrepancy Information Exposure): code = 0 (msg = 'PASS')
=====> OWASP_AT_002::uri_probing: CWE-204 (Response Discrepancy Information Exposure): code = 1 (msg = 'FAIL:URI probing emits different HTTP status code (200 vs 404)')
=====> OWASP_AT_007::user_really_logged_out: CWE-672 (Operation on a Resource after Expiration or Release): code = 1 (msg = 'FAIL: Still able to access private page even after logging out.')
OWASP_AT_007::session_timeout_used: wait for 120 + 10 seconds
=====> OWASP_AT_007::session_timeout_used: CWE-613 (Insufficient Session Expiration): code = 0 (msg = 'FAIL: Private page was still accessible after timeout (120 + 10 secs).')
=====> OWASP_AZ_001::path_traversal: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')): code = 0 (msg = 'PASS')
=====> OWASP_SM_002::cookie_security: CWE-614 (Sensitive Cookie in HTTPS Session Without 'Secure' Attribute): code = 1 (msg = 'FAIL:Path attribute points to '/'')
=====> OWASP_SM_003::session_fixation_public: CWE-384 (Session Fixation): code = -2 (msg = 'INFO: Unable to get Cookie from public page')
=====> OWASP_SM_003::session_fixation_private: CWE-384 (Session Fixation): code = 1 (msg = 'FAIL:Vulnerable to Session Fixation Attack by authenticated users')
=====> OWASP_SM_004::cookie_not_fresh: CWE-323 (Reusing a Nonce, Key Pair in Encryption): code = 1 (msg = 'FAIL: Vulnerable of re-using session cookies')
=====> OWASP_SM_004::cookie_secure_storage: CWE-312:CWE-613 (Cleartext Storage of Sensitive Information:Insufficient Session Expiration): code = 1 (msg = 'FAIL:'Expires' header not set:Cache-Control header not set.')
=====> OWASP_SM_004::cookie_via_get: (): code = 0 (msg = 'PASS: Unable to login via GET.')
=====> OWASP_SM_005::csrf: CWE-352 (Cross-Site Request Forgery (CSRF)): code = 1 (msg = 'FAIL:Vulnerable to CSRF Attack (HTTP code 200)')

17 test in 155 secs.

kostenloser Counter

SAD 1: The Change... and no, we are not in the "House of Flies" here

2010-12-03T01:49:00.000-08:00

I told you that future isn't predictable, that it is dominated by change. So here is what has to change: First (maybe) you!

Power is what most people lack of, people that feel the time for a change is now, or that see the disadvantages in their private and/or working life, often are too powerless. Either their psyche/mind is powerless, or maybe they don't have the executive power, or they do not have ever made the social connections to the right people with the power and mind needed to go a new way.

Well your way of getting your job and more done should be based on a strong mind. If your psychological hygienic is in a bad shape you are lost either way. Stop reading here! Go and change (or start loving!) the ill parts of your character before it is too late.

Will I come to a point in this post. Yes! Read on... :-)

When you are not happy about the security awareness in your company's software department or alike and your boss does not equip you with the power to do the job, the alternative is not to bury your head in the sand but just do it! (Warning: In big companies games are played differently as in small companies, means: Changes in big companies are often not wanted because they introduce risk. "Loser's Game" vs. "Winner's Game")

Of course you cannot go up to the software development department and force them to change their processes to an industry standard (MS SDL, SAMM, etc.). But you can offer the project- or team-leads your HELP. By it I mean you can offer them the parts of your favorite secure code development process that don't cost them much time and money, this means they cost your time of course. Go ahead!

Starting points.

The most less invasive and helpful tasks IMO are:

doing code reviews and filing bugs in their bug tracking system
provide security documents (secure coding, secure design, helpful links) in a wiki or any other internal CMS
offer security trainings directly related to their work
ask project leaders to include you in the application design process

Take care: Don't be a nit-picker or too restrictive. :)

Tips: Presentation, Training

What I found most useful and which is no magic is:

be short
only the most dangerous/important vulnerabilities
don't get lost in details
many examples, try use the team's code
live-sessions

The secure development trainings are really important (I often miss that *sigh*) because you stay in-front of the team and can influence their view on security and the way they develop code in the future. So, be friendly and helpful but also mandatory. Take a look in your soft-skill toolbox to see what techniques might be useful. (I always forget it... unfortunately)

Techniques: The appeal.

Five steps to formulate a clear appeal:

introduction: In the introduction phase you have to set the context by telling your dialog partner (dp) about the topic you are talking about. "I beg you to keep security in mind when developing our applications because security updates cost everybody's time, costs money, and put the customer at risk."
facts: Who should do what when exactly. But take care with the competencies here. Sounding too harsh is too easy. "During my penetration-test I saw simple flaws with high impact like cross-site scripting bugs in our social-network solution. Additionally I also stumbled over design issues like sending credential over the network without using SSL. Please review your code to fix all cross-site scripting vulnerabilities before the next beta-release. Tools for testing and descriptions of the bug as well as possible solutions are described in our Intranet wiki. For the next major version or re-design of our product xyz, I can offer you to be part of it and review the design."
context: People accept and fulfill additional tasks better if they know about he corresponding context. "When we deliver the code as-is with all it's big security holes, hackers will have a lot of fun stealing personal information easily from your customer's servers . We will chip away our image and have additional work releasing security updates. Not releasing bugs is cheaper than providing security updates."
comprehension: Do not ask so called closed questions like "Is everything clear?" or "Is something unclear?" you will get "Yes." respectively "No." as a reflex from your dialog partner. Better use open questions: "I know this kind of vulnerability is very abstract. Where are open questions I can answer for you?", "What can I do for you to make this work?", "Which questions do you have?" And after each question make a long pause, this encourages your dp to react.
acceptance: At the end you need to verify if your appeal was really accepted by your dialog partner. There is a gap between understanding and accepting. The first 4 steps of a clear appeal try to bridge over this gap and at the end you need to verify if you were successful. If you don't like it you can omit this final step and hope for the best. You may also received signals from your dp that shows acceptance or reluctance and adopt the final step based on that. The easiest way would be to ask: "Will you fulfill this task until the next beta-release?" This is of course not the right way if you work on an equal footing. Alternatives might be: "Where can I help you to get this done until next beta-release?" etc.

I should start following my own advises and... also never write a novel. ;)

(for the topic see the following lyrics)

kostenloser Counter

Rails Security Articles... nice to read

2010-11-08T06:24:00.000-08:00

http://www.kalzumeus.com/2010/09/22/security-lessons-learned-from-the-diaspora-launch/
http://www.railsinside.com/tips/486-14-bare-minimum-security-checks-before-releasing-a-rails-app.html

kostenloser Counter

Tool: Login Brute-Forcer for the Web

2010-10-29T05:29:00.000-07:00

plain, simple, stupid, unfancy, working. Get it from gitorious.org.

kostenloser Counter

Tool: Web-Spider released

2010-10-28T06:17:00.001-07:00

Well I did it again. I didn't find a spider tool that fits my needs and wrote my own. Check it out at gitorious.org.
It crawls a web site to a defined depth, downloads docs, sheets, multi-media files, etc, checks if a URL is fuzzable or accessible without authentication (CWE-425, Forced Browsing).

kostenloser Counter

Secure Development Workshop at Nuremberg

2010-10-27T00:29:00.001-07:00

My last working week was really busy and started at Sunday noon because I was in Nuremberg to hold a web-security workshop for my colleagues at Monday morning. Traveling at Sunday feels a bit strange, no business people, but much party people with hangovers. OOo Impress hung X completely by eating up all available resources. Nevertheless the live sessions worked better than expected and seem to be the salt in the stale slide soup.

The "it-sa Sicherheitsmesse" (security trade show), OWASP conference, and the openSUSE conference were the overlapping highlights of this week. Unfortunately I missed the OWASP conference... :(

This week is the last chance to do web-application penetration-testing of in-house products before I have to take over the incidents handling next Tuesday.

I still need to find a good way to bring threat modeling and secure development to Web 2.0 without using bloated text documents and reusing text blocks all the time.

Tool: simple XSS fuzzer

2010-10-26T08:15:00.000-07:00

just found none that worked for me and wrote my own. check out fuzz-xss

kostenloser Counter

Ruby on Rails: URI.unescape() and bypassing authZ

2010-10-25T05:44:00.000-07:00

pseudo code:

def change_pwd
  if !@http_user
    ERROR
  else if not params[:login] or not params[:password]
    ERROR
   end
  unless @http_user.is_admin? or params[:login] == @http_user.login
    ERROR
  end

  login = URI.unescape( params[:login] )
  newpassword = Base64.decode64(URI.unescape( params[:password]))

  #  change password in users db
  @user = User.find_by_login(login)
  @user.password = newpassword
  @user.save!
end


URI.unsecape("thomas%OO") --> "thomas"

kostenloser Counter

Ruby on Rails 2.3 vulnerable to Padding Oracle Attack

2010-09-14T03:35:00.000-07:00

JFYI: http://netifera.com/research/poet/PaddingOracleBHEU10.pdf

cite slide 15:

Vulnerability: encrypt and decrypt functions.
Use encrypt_and_sign and decrypt_and_verify instead.

CVE-2010-3299

Update: I am not sure that this claim is really true because the encrpyt function is not mandatoy and there is still a digest at the end of the cookie string to ensure integrity. Still waiting for an answer from the authors... stay tuned!

2010-10-27: No clarifying answer from the authors yet. We assume this is a non-issue for Rails.

kostenloser Counter

SAD 0: Secure Code Development in an Open-Source World

2010-08-26T08:51:00.000-07:00

What does SAD mean? I will clarify it later, it does not matter now... don't be sad about it.

Since some years big software companies like Microsoft (2002) or Cisco (2010) start changing their software development procedures to address the massive amount of vulnerabilities in their products. MS seems to be successful with this strategy and all the charts, numbers and articles look promising. "But what about the open-source world, the world of Linux distributions, what did they do?" you might ask. Led me shed some light on it.

It is much different for us and I will go into the details later. Let me first enumerate some vital steps in the secure development process that correlate to the steps of various software development "philosophies":

secure system design principals
risk assessment (aka threat modeling or security profiling)
choosing the right technology (programming language, compiler, etc.)
secure-coding training for developers
security-testing training for testers
tools (static analysis and compilers with security options) for developers
security-related testcases and tools (fuzzers, scanners, etc.) for the QA team
partial code-review by specialists
penetration-testing by specialists
maintenance (update publishing, customer notification)

All steps are important and some, like secure design and risk assessment, are even so important that without it an application can never be secure without completely re-writing large parts of it.

If you develop code in-house you have influence on each of the development steps (not for free of course). But if you are a distributor of open-source software you just collect the software, bundle it and hand it over to your customers (I hope no one will bash me for this simplification). This puts us in the penetrate-and-patch wheel (aka "hamster wheel" by A. Jaquith) which is known to be costly and ineffective. But you can be sure our "hamster wheel" is well oiled and our teams of "hamster-engineers" is in good shape. Maintenance is one of the main and most important services we provide because software will never come without bugs... that is the reality.

We, as distributor, could of course be so crazy and try to force open-source developers to follow a set of principals of secure software development by letting them answer questionnaires and verify their code quality. And if they fail, we will drop their package(s). Believe me, this would neither help us nor the community nor any enterprise customer. SUSE: "Oops, we have to drop X and the kernel. Well, be it so...", developer: "SUSE sux!" (BTW, untrue... we dropped "sux".)

What really helps in this situation is:

a healthy and effective communication between distributions, and between distributions and the OSS developers as well as the user community/customers
kernel, glibc and gcc options to avoid memory corruptions, enable non-executable memory sections, address space randomization etc.
security-related testcases and tools (fuzzers, scanners, etc.), for example for the QA team
secure default configuration of the system and its services by enforcing our security policy for all packages
code review and pen-testing of high-risk components
processes and interfaces well-known and accepted by customers
and a highly optimized "hamster wheel", vulgo: maintenance (bug fixing, update publishing, customer notification)

So much for the process and current state. Let me dive into the shiny waters of history before I will take a look into the future.

About 12 to 10 years ago, when Marc (ret.), I and Sebastian (chronological order) started working for S.u.S.E., our main focus was code-reviews (our wu-ftpd was great!) and to establish a process for security updates.
We improved the way code reviews were done in the last decade and came to something like Threat Modeling (Security Profiling) but in a much less noisy way by combining design reviews, results of code reviews and runtime (penetration) tests with real bugs (incl. severity rating). Beside of that there is a real change in code quality of high-profile open-source software, we found much less simple or severe bugs. The bugs in libraries, client- as well as in web-applications increases dramatically (remember PHP, PDF libs, font libs, ImageMagick, ...).

But code-reviews alone did not protect you against unknown bugs. A secure default configuration (SUSE Linux Enterprise Server as well as openSUSE) is vital. Our strict policy (processes and technology) is mainly enforced by Ludwig and Marcus.

The general security awareness in our company as well as in the whole digital society changed positively compared to the time before the dot-com bubble imploded. ("A long, long, long, long time ago - Before the wind before the snow ...")
And therefore we receive more security bug reports from customers, community memebers and colleagues as well as from code reviews by others people and companies. And that is good.

A negative effect of the massive web-based (web 2.0) development is complexity and openness. Todays web-applications are highly exposed, have different standard and non-standard interfaces, talk to several other semi-trusted systems, are dynamic and mainly process untrusted data. They are always the low-hanging fruit... imagine what would happen if the paradise was full of apple trees!

New challenges to counter!

(Ah, I promised to take a look into the future, I can't! :) The only constant in life is change. Enjoy!)

kostenloser Counter

Two new articles in openSUSE wiki

2010-07-23T02:53:00.000-07:00

enjoy and enhance!

Secure Coding Checklist: C and C++
Secure Coding Checklist: Ruby on Rails

kostenloser Counter

SELinux, opensuse 11.3 milestone 7 and sysvinit

2010-05-21T03:31:00.000-07:00

Just a short note: We switched back from upstart to the good old sysvinit and everything works fine.

kostenloser Counter

OSVDB.org entry submitted

2010-05-14T00:16:00.000-07:00

Hm, our entries in www.osvdb.org are incomplete, I submitted updated contact information...
Update: http://osvdb.org/vendors/search?name=suse

kostenloser Counter

openSSUE 11.3 and funny Dots

2010-05-06T05:36:00.000-07:00

The good news first: No, your shiny new LED doesn't have pixel failures!
The dot you see at the end of the file permissions of the ls(1) output comes from additional ACLs, in this case SELinux.

http://www.gnu.org/software/coreutils/manual/coreutils.html states:

"Following the file mode bits is a single character that specifies whether an alternate access method such as an access control list applies to the file. When the character following the file mode bits is a space, there is no alternate access method. When it is a printing character, then there is such a method.
GNU ls uses a ‘.’ character to indicate a file with an SELinux security context, but no other alternate access method"

kostenloser Counter