[SC-L] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code
This is not quite true. Java does not prevent integer overflows (it will not throw an exception). So you still have to be careful about array indexes. Andrew On 29/03/2006, at 12:49 PM, [EMAIL PROTECTED] wrote: no, a browser written in java would not have buffer overflow/stack issues. the jvm is specifically designed to prevent it ... -- Michael smime.p7s Description: S/MIME cryptographic signature ___ 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] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code
no, a browser written in java would not have buffer overflow/stack issues. the jvm is specifically designed to prevent it ... -- Michael On 3/29/06, Pavel Kankovsky <[EMAIL PROTECTED]> wrote: > On Mon, 27 Mar 2006, Brian Eaton wrote: > > > If I run a pure-java browser, for example, no web site's HTML code is > > going to cause a buffer overflow in the parser. > > Even a "pure-java browser" would rest on the top of a huge pile of native > code (OS, JRE, native libraries). A seemingly innocent piece of data > passed to that native code might trigger a bug (perhaps even a buffer > overflow) in it... > > Unlikely (read: less likely than a direct attack vector) but still > possible. > > --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] > "Resistance is futile. Open your source code and prepare for assimilation." > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ 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] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code
no, a browser written in java would not have buffer overflow/stack issues. the jvm is specifically designed to prevent it ... -- Michael On 3/29/06, Pavel Kankovsky <[EMAIL PROTECTED]> wrote: > On Mon, 27 Mar 2006, Brian Eaton wrote: > > > If I run a pure-java browser, for example, no web site's HTML code is > > going to cause a buffer overflow in the parser. > > Even a "pure-java browser" would rest on the top of a huge pile of native > code (OS, JRE, native libraries). A seemingly innocent piece of data > passed to that native code might trigger a bug (perhaps even a buffer > overflow) in it... > > Unlikely (read: less likely than a direct attack vector) but still > possible. > > --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] > "Resistance is futile. Open your source code and prepare for assimilation." > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > ___ 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: FW: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code
On 3/28/06, Michael S Hines <[EMAIL PROTECTED]> wrote: > Isn't it possible to break out of the sandbox even with managed code? (That > is, can't > managed code call out to unmanaged code, i.e. Java call to C++)? I was > thinking this was > documented for Java - perhaps for various flavors of .Net too? Java _can_ call c++ but the the way to do it can be restricted by the security manager. i.e. you can't call "System.loadLibrary" without permission. you "may" be able to call native functions of already loaded dll's though by registering their headers like: public native foo( ... ); not sure how far you'll get with that though. -- Michael ___ 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] Owasp SiteGenerator v0.70 (public beta release)
After much development and hard work here is the first stable (beta) release of the new Owasp SiteGenerator tool (whose Open Source development has been sponsored by Foundstone) Owasp SiteGenerator allows the creating of dynamic websites based on XML files and predefined vulnerabilities (some simple to detect/exploit, some harder) covering multiple .Net languages and web development architectures (for example, navigation: Html, _javascript_, Flash, Java, etc...). SiteGenerator can be used on the following projects: - Evaluation of Web Application Security Scanners - Evaluation of Web Application Firewalls - Developer Training - Web Honeypots - Web Application hacking contests (or evaluations) You can read an introduction to this tool here (http://sourceforge.net/mailarchive/message.php?msg_id=14547158), and download the latest version from here: Website installer: http://www.ddplus.net/projects/FoundStone/21-March-2006/SiteGenerator_IIS_Website_Setup v0.70.msi Gui Installer: http://www.ddplus.net/projects/FoundStone/21-March-2006/Owasp SiteGenerator v0.70.msi Some installation and configuration notes (which you only need to do once): Before you install the website do this (assuming a windows 2003 image) Create a new Application pool, call it SiteGeneratorSystemAppPool), and configure it to run under System Create a new website and point it to a local directory (the website installation files will be copied here) Configure the new website to run Asp.Net 2.0 Create a new Application in that website and set the application pool to SiteGeneratorSystemAppPool Add a IIS wildcard Application Mapping (accessible via Home Directory -> Configuration) to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll and untick the 'Verify that file exists' Make sure Default.htm is one of the files included in the default document list (in the 'Documents' tab) Configure the Website's IP Address to be 127.0.0.1, and click on the Advanced button to add a new host header mapping IPAddress: 127.0.0.1 TCP Port: 80 Host Header Value: SiteGenerator Install the WebSite (selecting as the target the website created in the previous step) Install the GUI Add this line to your hosts file (located in C:\window\system32\drivers\etc\hosts) SiteGenerator 127.0.0.1 Click on the SiteGenerator link that was placed on your desktop If all goes well you now can browse to http://SiteGenerator or http://127.0.0.1 (depending if you did the mappings or not) and see the default SiteGenerator's website. If you see a blank page, try http://127.0.0.1/Default.htm (you might be getting a cached version of http://127.0.0.1) Note that the SQL Injection vulnerabilities expect that you have the latest version of HacmeBank (v2.0) installed in your box. I am in the process of creating several videos (covering the installation and GUI) which I am sure will be very useful and practical. Also if you are interested in helping in the development of SiteGenerator or in its vulnerabilities database, then contact me directly. Best regards Dinis Cruz Owasp .Net Project www.owasp.net ___ 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: FW: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code
If you are able to make direct calls to unmanaged code, then yes you can jump out of the sandbox (assuming that you are in one in the first place) The environment that I am talking about is one where you have managed and verifiable code which is not allowed to perform dangerous actions (such as making direct calls to unmanaged code) Of course that you would still be affected if there was a hole in Microsoft's .Net Sandboxes or in the used Microsoft COM components (for example the .Net Framework was vulnerable to the WMF exploit). Coming back to your question, Verifiable .Net code is not allowed to perform (amongst other things) direct pointer or stack manipulation, all type conversions much be valid, and you cannot control the execution flow the way you can in C++. So basically, Verifiable .Net code is not able to jump out of the sandbox. Dinis Cruz Owasp .Net Project www.owasp.net Michael S Hines wrote: > Isn't it possible to break out of the sandbox even with managed code? (That > is, can't > managed code call out to unmanaged code, i.e. Java call to C++)? I was > thinking this was > documented for Java - perhaps for various flavors of .Net too? > > --- > Michael S Hines > [EMAIL PROTECTED] > ___ 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: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
Hello Eric (comments inline) Eric Swanson wrote: > Because I believe that Microsoft will never be as cooperative with .NET and > the developer community as Sun is with Java, is there an opportunity for > another company to step up to the plate on Microsoft's behalf? There is definitely an opportunity here. At the moment I see two big players that could move into that space: Novell and IBM. Both have the resources to do it, and the motivation. The main questions are: - Do they want to buy that 'war' with Microsoft? - Do they 'believe' that this a worthwhile project and one that will help their bottom line? - Can they do it in an open and transparent way that attracts a strong community to it? (note that this community will be critical to the project, since I believe that no company in the world has the resources to it by itself) This could also be done by a very dynamic and well funded Open Source project (maybe by several governments or by companies/corporations which decide that they need to be more proactive in the protection of their critical resources and assets) > The .NET > Framework is completely public, and, although Mono continues to have its > workload increased by each Framework release, I think there may be an > opportunity for a company or organization to step-in and take the reigns > where Microsoft left off. How possible is it to "plug-in" to the CLR and > make extensions to the core? > It is very doable. Note that there are already 4 different flavors of the CLR (Microsoft's .Net Framework, Rotor, Mono and DotGnu) See also the Postbuild commercial application (http://www.xenocode.com/Products/Postbuild/) which claims (I have not used it) to create Native x86 executables which allows .NET applications to run anywhere, with or without the Framework. This is something that I always wanted to do since it should (depending how it is done) allow the dramatic reduction of code (and dlls) that needs to be loaded in memory (the ultimate objective would be to create mini-VMs that were completely isolated from the host OS (or only having very specific interfaces / contact points)). Also while I was doing my 'Rooting the CLR' research, since Microsoft does provide the Symbols for core .Net Assemblies, there is a lot that can be done at that level. That said, this work would be greatly simplified if Microsoft released the source code of the entire .Net Framework :) > Perhaps a better project for OWASP.NET than security vulnerability detection > utilities is a security plug-in to the CLR engine for byte code signature > registration and verification? Agree, the problem we have is resources (and lack of funding) Btw, at Owasp .Net we have now much more than just 'Security Vulnerability Detection Utilities' :) Apart from those utilities (namely ANSA and ANBS) we now also have: * Owasp Site Generator : Dynamic website creator to test Web Application Scanners and Web Application Firewalls (and a great tool for developers to learn about security vulnerabilities) * Owasp PenTest Reporter : Tool that aids in the process of documenting, reporting and tracking security vulnerabilities discovered during Penetration Testing engagements * DefApp (Proof of Concept): Web Application Firewall Another project that I would love to do is to work on a plug-in manager for Firefox which would execute all Firefox plug-ins in a managed and verifiable .Net sandbox (maybe built around mono (which was were this idea was suggested to me)) > Would this task even be feasible? (Managed > code only?) Is it even worth the effort, considering the possibility of > further development from Microsoft? > I think that it would be worth the effort, the problem is 'who will fund this'. I don't think that this is a project that can be done on the backs of the odd spare times that its main developers would be able to allocate to it. > *Personally, I have never attempted to work below the top layers of .NET. > It's not that hard :) > But, it seems to me that plugging into the core would be a better option > than some kind of wrapper sandbox, especially with regard to change control > (top layers are likely to change more often and more drastically than lower > layers). > Absolutely, and remember that ideally this tool would also remove 95% of that 'top layer' since it is not required. I am also not convinced of the robustness of the current implementation of CAS in .Net 1.1 and 2.0. There are too many security demands in too many places. > Should it be a task of the OWASP.Java team to work with Sun "Mustang"? > Maybe, but first you need to create that Owasp.Java team :) There are a lot of Java guys at Owasp, but they all are working on separate projects > Could there ever be a silver bullet sandbox for all executables, regardless > of language? No I don't think so. You will need to look at each different type of executables (mobile code, web apps, desktop apps, windows services, 'r
Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
Hello Stephen , Stephen de Vries wrote: > I had the same intuition about the verifier, but have just tested this > and it is not the case. It seems that the -noverify is the default > setting! Thanks for confirming this (I wonder how many other other Java developers are aware of this (especially the ones not focused on security)). Stephen, do you have any idea of what is the current percentage of 'real world' Java applications are executed: a) with verification b) on a secure sandbox Note that for example I have seen several Java Based Financial Applications which are executed on the client which either require local installation (via setup.exe / App.msi) or require that the user grants that Java application more permissions that the ones allocated to a normal Sandboxed browser based Java App. > If you want to verify classes loaded from the local filesystem, then > you need to explicitly add -verify to the cmd line. I tested this by > compiling 2 classes where one accesses a public member of the other. > Then recompiled the other and changed the method access to private. > Tested on: > Jdk 1.4.2 Mac OS X > Jdk 1.5.0 Mac OS X > Jdk 1.5.0 Win XP > > all behave the same. > > [~/data/dev/applettest/src]java -cp . FullApp > Noone can access me!! > [~/data/dev/applettest/src]java -cp . -verify FullApp > Exception in thread "main" java.lang.IllegalAccessError: tried to > access field MyData.secret from class FullApp at > FullApp.main(FullApp.java:23) > Humm, this is indeed interesting. Ironically, the 1.1 and 2.0 versions of the CLR will thrown an exception in this case (even in Full Trust). Since verification is not performed on that .Net Assembly, the CLR might pick up this information when it is resolving the method's relative address into the real physical addresses (i.e. during JIT). > Using the same code with an Applet loaded from the filesystem throws > an IllegalAccessError exception as it should. > What do you mean by 'Applet loaded from the filesystem'? Where? In a Browser? Best regards Dinis Cruz Owasp .Net Project www.owasp.net ___ 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] Re: [Owasp-dotnet] Re: Is there any Security problem in Ajax technology?
As been said before in this thread, AJAX is just another 'architecture' for creating systems that allow end users to use online services (although due to the increased attack surface one more potentially dangerous than an website interface). But will AJAX dramatically increase or decrease the security vulnerabilities that exist in applications? I am not sure. More and more I am convinced that it is the 'development model' / 'development mindset' that has the greater impact in the security of the newly created applications. In an environment where: a) end clients (the ones paying for the development) don't care about (or don't know how to demand) secure applications, b) solution architects have limited time/budget to design a solution to 'ever-moving project objectives/deliverables' c) projects are so complex that nobody has a full technical understanding of the entire system d) there is no (or there is a weak) formal security process (from threat modeling, to secure by design/default/deployment designs, to code audits) e) developers don't have a strong understanding of the security implications of the programing techniques that they use f) developers are given unrealistic deadlines for the number of features requested g) the financial benefit in writing secure code, is much smaller than the financial benefits of writing feature rich applications which have good performance h) security incidents will be 'covered up', not publicly disclosed unless they really have to, and the responsible parties (which in my view, in most of the cases are not the developers) are not made accountable g) the ever changing of technologies used (where nobody really masters it, and even very experienced programmers are most of the time 'professional amateurs') i) the increased complexity and interconnectivity of our systems ...how do you expect secure applications to be developed? Ultimately we must look at the assets and answer the question "are they still being compromised?" regardless if the attack vector are buffer overflows, SQL injection, Authorization failures, etc... We also must note the 'depth' of the compromise. Are we a talking about a compromise of an Web Application, the server or the data center? With the current speed of the industry, unless the 'model' behind the Software Development Lifecycle promotes security, then there will always be multiple ways to create security vulnerabilities. Unfortunately it does not end with a good Secure Software Development Lifecycle (SSDL). For example Microsoft currently has a better SSDL than Oracle, but is still creating insecure applications, frameworks and operating systems that (for example) are not able to handle malicious code executed from within (namely Full Trust .Net code and Vista's UAC/LUA). Microsoft understands yesterday's security problems (buffer overflows, Sql injections, xss, crypto attacks,etc...) but doesn't understand (or wants to understand) tomorrow's security problems (securely execution of malicious code, authorization vulnerabilities, race-conditions, malicious developers, CLR attacks, etc...). So here we end up with the good-old Business case. When there is no short-term business case and strong client/government demand for a secure solution/product/operating system, the companies delivering applications will not do it voluntarily (even when they have a good understanding of security and have developers who understand secure coding practices) So coming back to AJAX I would say: Show me your development model, mindset, motivation and past exploitation record; add in the technologies used, and I will show you where security vulnerabilities are very likely to exist. Dinis Cruz Owasp .Net Project www.owasp.net Jeff Williams wrote: Hi Eric, I think you've nailed what's really going on here. There's this huge timelag between when new technologies are introduced and when we (as a software development community) are really using them securely. As several folks have pointed out, there's nothing fundamentally new about the security issues created by AJAX. As a *security* community, our challenge is to translate the principles and practices that we understand to the new technologies that come along. Our track record isn't particularly good here by the way. We never translated the extensive access control work from the 80's to the web environment. We're starting to translate what we've learned about web apps to web services. But, realistically, it's going to be a while before we are effectively securing AJAX apps. OWASP, as an all volunteer open-source project, has a role to play here. When new technologies arise, we approach them from a bunch of different angles. Generally, the presentations at local chapters and email threads like this happen first. The Guide captures the issues more completely and fully. WebScarab adds support for the technology, and WebGoat lessons get built to
Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
Jeff, as you can see by Stephen de Vries's response on this thread, you are wrong in your assumption that most Java code (since 1.2) must go through the Verifier (this is what I was sure it was happening since I remembered reading that most Java code executed in real-world applications is not verified) I think your answer shows clearly that the Java camp should also be participating in these discussions. In fact I also would like to ask "Where are the Java Guys/Girls?" I have been talking for two years now on the dangers of .Net Full Trust code, and have not seem much discussion on the dangers of 'Security Manager disabled Java code' (since the problems are exactly the same). Malicious Java code, executed with the Security Manager Disabled in a user's desktop or in a server, is as dangerous as Full Trust .Net code. This comes back to that great concept called 'Faith-based' Security (see Gunnar Peterson's post http://1raindrop.typepad.com/1_raindrop/2005/11/net_and_java_fa.html ), which is when people are told so many times that something is secure, that that they believe that it MUST be secure. Some examples: - "Java is more secure than .Net" (meaningless discussion unless we also talk about the Sandboxes the code is running under) - "IIS 6.0 is more secure that IIS 5.0" (today, is a fully patched IIS 5 (with urlscan ISAPI filter) more 'secure' than a IIS 6.0? Most people will automatically say yes, but if you do a Risk analysis to both, you will see that the risk is just about the same: both ARE able to sustain malicious 'Internet based' anonymous attacks (since there are no reported unpatched vulnerabilities and zero-days exploits), and both are NOT ABLE to sustain malicious Full Trust Asp.Net code executed from within one of its worker processes - "Open Source apps are more secure than Closed Source apps" (again, not an automatic truism) - "Linux and Mac are more secure than Windows" (that depends on how it is configured, deployed, maintained, and more importantly, how it is used). - "If only we could get the developers to write 'secure code' there would be no more vulnerabilities" (this is the best one, a good example of 'Faith Based Security' with 'Blame the guy in the trenches that doesn't complain (i.e. the developers)' (note that I don't think that developers have SOLE (or even MAIN) responsibility in the process that leads to the creation of insecure applications)) -"I.E. is more insecure than Firefox" (apart from the unmanaged code discussion we had earlier, I just say this: Firefox plug-ins. The best way to Own millions of computers is to write a popular Firefox plug-in (which to my understanding runs directly on Firefox's process space and not contained in any type of Sandbox)) I hope the Java camp will also join this discussion on how to create 'real world' applications which can be executed in safe Sandboxes. Ultimately my main frustration is that both .Net and Java have built into their framework technological solutions which COULD deliver such environments (CAS and Security Manager). The problem is that they were designed to handle a very specific type of code (the so called 'Mobile code') for a specific set of applications (browser based components and mobile devices), not the complicated,massively interconnected, feature-rich apps that we have today. What we need now is focus, energy and commitment to create a business environment where it is possible (and profitable) the creation, deployment and maintenance of applications executed in secure sandboxes. Dinis Cruz Owasp .Net Project www.owasp.net Jeff Williams wrote: I am not a Java expert, but I think that the Java Verifier is NOT used on Apps that >are executed with the Security Manager disabled (which I believe is the default >setting) or are loaded from a local disk (see "... applets loaded via the file system >are not passed through the byte code verifier" in http://java.sun.com/sfaq/) I believe that as of Java 1.2, all Java code except the core libraries must go through the verifier, unless it is specifically disabled (java -noverify). Note that Mustang will have a new, faster, better? verifier and that Sun has made the new design and implementation available to the community with a challenge to find security flaws in this important piece of their security architecture. https://jdk.dev.java.net/CTV/challenge.html. Kudos to Sun for engaging with the community this way. --Jeff - This List Sponsored by: SpiDynamics ALERT: "How A Hacker Launches A Web Application Attack!" Step-by-Step - SPI Dynamics White Paper Learn how to defend against Web Application Attacks with real-world examples of recent hacking methods such as: SQL Injection, Cross Site Scripting and Parameter Manipulation https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=70130003gRl
