Interview Question: Determine Whether a Text includes all ASCII characters

import java.util.Arrays;

import java.util.Scanner;

import java.io.UnsupportedEncodingException;





public class ASCII {



 /**

  * @param args

  * @throws UnsupportedEncodingException 

  */

 static String text = "";

 static boolean[] counter = new boolean[256];



 public static void main(String[] args) throws UnsupportedEncodingException {



  while (text == "") { 

   System.out.println("Enter Your Text and Press ENTER:");

   text = readText();

  }



  byte[] result = text.getBytes("US-ASCII");

  long[] intResult = new long[result.length];

  long value = 0;

  //Converting Byte Array to its Integer equivalence

  for (int i = 0; i < result.length; i++)

  {

     value = (value << 8) + (result[i] & 0xff);

     intResult[i]= value;

     value=0;

  }

  long[] sortResult = sortArray(intResult);



  if (hasAllASCIIChars(sortResult))

   System.out.println("Text has all ASCII characters");

  else

   System.out.println("Text does not have all ASCII characters");

 }



 



 /**

  * 

  * @param sortedArray: sorted array of ASCII Codes of characters (Long)

  * @return

  */

 private static boolean hasAllASCIIChars(long[] sortedArray) {



  for (int i = 0; i< sortedArray.length - 1; i++) 

   if (!counter[(int)sortedArray[i]])

    counter[(int)sortedArray[i]] = false;



  for (boolean bool : counter)

   if (bool == false)

    return false;

  return true;  

 }



 public static String readText() {

  Scanner sc = new  Scanner(System.in);

  if (sc.hasNext()) {

   return sc.nextLine();

  }

  else {

   return "";

  }

 }



 



 public static long[] sortArray(long[] array) {

  Arrays.sort(array);

  return array;

 }

}

Bug in Syntax Highlighter Integration with Dynamic Themes in Blogger

I was trying to get the syntax highlighter libraries to work on this blog and I was failing all the time. Apparently there is a bug on the script that both Prettify and SyntaxHighlighter are using . I did report them all to the issue tracking system. You can follow the status of the issue with following links:

Prettify: http://code.google.com/p/google-code-prettify/issues/detail?id=239&thanks=239&ts=1346094424
Syntax Highlighter: https://bitbucket.org/alexg/syntaxhighlighter/issue/292/issue-with-dynamic-themes-in-blogger

I also tweeted to Alex Gorbatchev about the bug tracking system but until this moment, I have not received any response from him. As soon as I will receive the response, I will also add the issue link at the bottom of this post.

Update: After no personal response, I finally found Syntax Highlighter issue tracking system and posted my issue there. You can follow the case with the added link.

Update 2: Syntax Highlighter has assigned "High" to the priority of this issue. No sign of assignment on severity of the bug in Prettify yet.

Portability is important for Cloud Software

3 cloud for developers

There are fundamental changes of how a software developer writes code inside a cloud. In past, a developer had a software package with specific operating environment to target and had to have knowledge around that operating environment APIs. However SaaS developers at the time being prefer popular and promising development standards which are open and platform-independent due to the fact that they want to target numerous users and in addition, they want their SaaS to be easily portable and extendable e.g. Paypal Online Component, Amazon Store API or Gmail API. Another issue for SaaP developers was that developers were faced with limitations on their clients computing resources inside client infrastructure. Finally, developers had to round ideas around a product, however in SaaS they are developing a service. More clearly, after software was delivered to customer, there were not much interaction between customers and developers unless in case of a bug fix or a new release which meant a new product in the sense of SaaP. While developing SaaS, customers frequently need improvement on their services and as long as they have a contract, this interaction exists. In service-based development, since software is being utilized by vast number

of users, therefore scalability is another issue for SaaS hosts.

3.1 Agile Development

One of most critical part of a SaaS project is the choice of development methodologies. Based on the unique features of a SaaS which was mentioned in section 1.2, agile methods are embraced inside SaaS projects. Reasons are that Agile methods are divided into a set of tasks and each task constitutes of several iterations. Each task consists of a set of goals and is completed within a number of iterations. More specifically, the benefit of using an agile method is that after the software designer will agree upon the task design, and the developers and tester start coding and testing respectively, since tasks can have more and more iteration, there can be additional features and perspectives in each cycle that can be added to the task over the time. The result of applying such process shall be that the changes are no longer infrequent, easy and financially sufficient to make. There exist numerous variants of Agile methodologies, some of which are XP, Scrum, Feature Driven Development and Lean Software Development.

CS Scalability, CS Portability

3.2 Portability and Scalability in SaaS

As mentioned in section 1.2, due to the scalability factor of a SaaS project, developers tend to utilize platform-independent frameworks in order to increase portability and cost efficient scalability inside their SaaS applications. As an example there will be developers preferring to work with Objective-C inside Apple’s iCloud, however since Objective-C is coupled to Apple’s products one cannot benefit from using it outside iCloud. As another example, Microsoft ASP.NET can also be a wise choice while working with Microsoft Azure service, however in case a company receives a better offer from deploying his service on Google App Engine, developers should re-writes at least some parts of application in Java or Python, if not all. For scalability, development team has two options available: Vertical and Horizontal Scalability. Vertical Scalability is the idea of enabling severs with CPU and memory power in order to handle a high load of requests. On the other hand, Horizontal Scalability is to have multiple unit of works and enabling them to handle loads of request, as if there are working as a single unit of work. Vertical Scalability is expensive however is an easy choice. On the other hand, Horizontal Scalability is financially cheap however requries some considerations. Considerations are on how all layers such as CPU (i.e. processing power), Storage layer (e.g. Clustered file systems or Amazon S3), the database layer, Application Layer(e.g. Tomcat clustering), the Web Layer, Load Balancer , Firewall can scale out synchronously. For more information on Scalability and Portability, see [2] .

Cloud Portability

References:

[1] Martin Fowler. Patterns of Enterprise Application Architecture. Addison- Wesley Professional, 2002.

[2] Armando Fox and David Patterson. Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing. Strawberry Canyon LLC, 2012.

[3] David S. Janzen and Hossein Saedian. Does test driven development really improve software quality. IEEE Software, 8(3):77–84, 2008.

[4]: Praising Gaw's blog, What is the difference between cloud computing and SaaS, http://cloudcomputing.sys-con.com/node/612033

[5]: STEVB's blog, Differences between SaaS and cloud software, http://www.mindtouch.com/blog/2008/05/28/differences-between-saas-and-cloud-software/

Interested in reading about Android OS Securitiy, check out the following posts:

Android Attacks in a Nutshell
  

Cloud Computing: Developer's View (Part III)

2 software development process

During 1980-2000, the industry was focusing on traditional development process methodologies such as Waterfall and Spiral methods. In these approaches, Rapid Application Development excluded, a stable version needed to be released firstly as alpha and beta versions. After that and in order to have the SaaP bugs fixed, customers had to either play around with the software or utilize it inside a production period. This was a long and risky process from customers’ point of view, since some bugs could have unrepeatable damages to data and Operating Systems beside the software itself. The latter was due to the fact that in traditional software development methodologies, verification phase and quality assurance was mainly being done after implementation phase. While there were some successful cases of software products with traditional methodologies, the following was a list of major issues in developing based on them.

• Before developing the software, designers needed to come up with a detailed full design plan. The issue was that some requirements were raised as the development process was evolving and could not be forecasted in the earlier design phase of the project.¹

• Beta releases needed months to become stable versions and attract all customers without worrying them.

• Changes in software were costly and infrequent, therefore customers could not have the set of features they needed in short period of time. Due to criticism of developer communities and many examples of software running over time and budget, this approach was nearly abandoned over time. In 2001, a group of developers aimed to come up with a lighter-touch lifecycle. Agile Alliance stated the following in the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan that is, while there is value in the items on the right, we value the items on the left more.

While working on a SaaS project, developers will be asked to change the code frequently. Customers signing a contract for a SaaS want constant improvement of their service. Frequently developers are greeted with new requirement which changes components of the project. Also, in case a SaaS developer develops a perfectly architectured and coded application, it shall not be accepted by the customers without his verification. That is the reason that in Agile methodologies, verification is separated from validation. Since validation is how to architect and code a software correctly, verification is the question of following scenarios as customer needs their service to be. It should be noticed that a service is coupled to a domain, bringing so much emphasis on agile verification methods.

1 Steve McConnell in his book ’Code Complete” refers to design as a ”wicked problem”, i.e. a

problem whose requirements and limitations cannot be entirely known before completion.

Cloud Computing Models: SaaS versus PaaS

1 SaaS vs. SaaP

1.1 History

Traditional SaaP developers was focusing on how to access Operating Systems (OS) APIs and how to handle those APIs in order to utilzie them inside a software via the development framework in use. After a while, the question of application portability came under discussion in early 90’s due to numerous

operating system segmenting the OS market. In 1995, James Gosling introduced the platform-independent Java and became the first scientist to tackle portability issues. Java programms were running on a virtual machine enabling applications to be ported in all Operating Systems. After that more

and more frameworks started to follow the path of Java to enable platform independency such as .NET framework by Microsoft, different implementation of Python and etc.

With Internet gaining huge popularity and profitability in the Dot-Com Bubble era during 1995-2000, IT industry started to invest remarkably in Web Infrastructure. However there was no disucussion about SaaS yet. A similar concept called Utility Computing was already introduced by John McCarthy in MIT in 1981 as ”an imagination of nearly infinite amount of computational resource”, however the SaaS dialect evolved after the release of Gmail, which was a successful implementation of SaaS. What was unique  about Gmail was the ability for the user to extend its API and utilize it as an email service inside his own applications. After Gmail gained popularity, companies started to invest more and more in SaaS engineering. In 2003, Amazon with its EC2 service truely started the Cloud industry. Not only Amazon  offered Infrastructure but also platforms to be used as a service. This initialized the cloud dialect after their service models were introduced, i.e. Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS). Recently, Microsoft has launched its Office 365 SaaS project, in order to allow users to pay for their use of software, instead of paying the whole license at the purchase time. This had made software development process to evolve in a complete different path than it used to be.

1.2 Features

While developing SaaP, vendor has an approximately large set of concerns in most cases. First is the application requirement regarding operating environment, hardware and software dependencies. Second is the application portability issue. Each framework has its own boundaries while dealing with system APIs and therefore either team members should be assigned to test the application against different operating environments, and re-write the software components or limit the user to specific functionalities in case of incompatibility. As a result, due to tight-coupled software and hardware package, changes in software are costly and are avoided in case of appearance of bugs that have low-severity level of destruction toward the system or customer dissatisfaction. Last concern of vendor is the customer’s data. Whether sensitive or not, customer’s data could be damaged by misuse or fatal bugs that SaaP-based applications could create.

With players involving more and more in the cloud market, it is apparent now that SaaS experience is completely different experience than it was in SaaP, either reviewed from a customer or a developer’s point of view. Some of the highlights of SaaS unique features can be listed as follows:

• There is no need for installation of any software rather than a standard Web Browser.

• Customers are working with the latest release of software. They may not even know this fact themselves, therefore they cannot choose not to.

• Customers do no longer have to worry about backing up their data as it is now the responsibility of SaaS providers to operate data back-up processes.

• SaaS software runs on a uniform and tightly coupled hardware, chosen by developer and therefore compatibility is no longer an issue. It should be remembered that no longer binaries are distributed amongst operating systems as it did in SaaP.

• Developers can upgrade the software and underlying hardware as frequent as they need to, without changing the API of the application.

Android Attacks in a Nutshell (Part III)

3  Permission Re-delegation Attack

3.1  What is Permission Re-delegation?

Browsers and smartphone operating systems, however, have shifted from associating privilages to their user accounts to a fundamentally new model where applications are treated as potentially malicious and mutually distrusting. Principals receive few privileges by default and are isolated from one another except for communication through explicit IPC channels. Inter Process Communication (IPC) in a system with per-application permissions leads to the threat of permission re-delegation. Permission re-delegation occurs when an application with a usercontrolled permission makes an API call on behalf of a less privileged application without user involvement. The privileged application is referred to as a deputy, handling authority on behalf of the user. According to Porter et. al, More than a third of the 872 surveyed Android applications in their study had requested permissions for sensitive resources and also had exposed public interfaces; i.e. they are therefore at risk of facilitating permission re-delegation. Moreover, the paper claims that 15 permission redelegation vulnerabilities in 5 core system applications were found. The permission re-delegation process is as follows: the deputy defines a public interface that exposes some of its functionality. After that, a malicious requester application lacks the permission that the deputy has. The requester invokes the deputy’s interface, causing the deputy to issue a system API call. The system will approve and execute the deputy’s API call because the deputy has the required permission. The requester has succeeded in causing the execution of an API call that it could not have directly invoked (Figure 1).

 

Figure 2: Permission re-delegation attack: The requester does not have the text message permission, but the deputy does. The deputy also defines a public interface with a Notify method, which makes an API call requesting to send a text message. When the requester calls the deputy’s Notify method, the system API will send the text message because the deputy has the necessary permissions. Consequently, the attack succeeds. [1]

3.2  Implementated Applications for Attacks

Porter et. al, built attacks using 5 of the 16 system applications. All of the attacks succeed in the background with no visible indication to the user. The filtered 5 applications provided 15 paths to 13 interfaces with permissions, one of which was SignatureOrSystem and nine of which were Dangerous permissions. Two example application in order to create permission redelegation attacks were also presented:

•     Settings serves as the phone’s primary control panel. When a user presses certain buttons, Settings’ user interface sends a message to a Settings BroadcastReceiver that turns WiFi, Bluetooth, and GPS location tracking on or off. However, Settings’ BroadcastReceiver accepts Intents from any application. An unprivileged application can therefore ask the Settings application to toggle the state of devices by sending its BroadcastReceiver the same Intents that it expects from its user interface. Turning these devices on or off is supposed to require Dangerous permissions (CHANGE_WIFI_STATE, BLUETOOTH_ADMIN,and ACCESS _FINE _LOCATION, respectively).

•     Desk Clock provides time and alarm functionality. One of its public Services accepts directions for playing alarms. If an unprivileged application sends an Intent requesting an alarm with no end time, then Desk Clock will indefinitely vibrate the phone, play an alarm, and prevent the phone from sleeping. The alarm will continue until until the user kills the Desk Clock process. Playing sound with a wake lock requires the Dangerous WAKE_LOCK permission, and vibrating the phone requires the Normal VIBRATE permission.

Concrete vulnerabilities were found with implementing the two previously mentioned applications in 5 of the 16 applications, which is equal to half of the 11 system applications identified as at-risk. Unfortunately, the authors did not disclose the code and therefore we cannot go further. Finally, Porter et. al discussed that to prevent permission re-delegation attacks, an IPC Inspection mechanism were presented, in which each deputy will accept Intents from the applications that already share the common permissions which is needed for the execution of that Intent. IPC inspection mechanism resides on top of already stack-inspection-enabled JVM and CLR. Since this topic is not in the scope of this report, for more details see [1].

4  Conclusion

This report is an introduction to Android OS security. While there exists a range of taxonomies of android attacks [2], their impact and possibility of occurance differs. We presented an XSS vulnerability on default web engine of Android, i.e. WebKit, after that a description of one of Android’s permission re-delegation attacks was presented and its implemented applications were discussed.

References

[1] Adrienne Porter Felt et. al. Proceedings of the 11th usenix conference on security. In Permission Re-Delegation: Attacks and Defenses.

[2] Asaf Shabtai et. al. Google android: A comprehensive security assessment. 2010.

[3] Sebastian Gerling Michael Backes and Philipp von Styp-Rekowsky. A local cross-site scripting attack against android phones. Technical report, Information Security and Cryptography Group, Saarland University.

[4] Patrick McDaniel William Enck, Damien Octeau and Swarat Chaudhuri. A study on android security. In Proceeding of 20th USENIX Security Symposium.

Android Attacks in a Nutshell ( Part II)

2 Local XSS Attack

2.1 Attacker Model

 Backes, gerling and Stype-Rekowsky [3] developed an android version 2.3.4 application that without requiring any permission can steal cookies stored in the web browser for Web sites of the attacker’s choice and automatically installing arbitrary applications from the Android Market without user consent. The three prerequisites for this attack is the following:
• User should install the malicious application, either by integrating the malicious code into an unsuspicious application, e.g. a small game. Since no permission is needed at install-time, there is a high chance that the user shall install an application that looks trustworthy.
 • The user needs to store login cookies in the browser, which is similar to normal cross-site request forgery attacks. In case we want to install other Android applications, it is further required that the user is already logged in to his Google account (the one he paired his phone with). Note that it suffices that the user is logged in to an arbitrary Google service based on Google policy.
• The WebKit-based browser shipped with Android needs to be the default receiver for http:/https: and javascript: VIEW Intents.

 2.2 Implementation

The attack exploits a flaw in the Intent handling mechanism of the Android browser. Naturally, this browser is configured to receive VIEW Intents that operate on http: and https: URIs. The browser will also handle VIEW Intents for javascript:URIs as well. Whenever the browser receives an Intent to view an http:/https: URI, it will open a new browser window and load the given Web site. However, upon reception of a view Intent for a javascript: URI, the browser will not open a new window but reuse the currently active window. Consequently, the javascript code given in the Intent URI will be executed in the context of the Web site that is currently loaded in the active window. This leads to a generic local XSS vulnerability, which works with arbitrary websites. As it can be seen in the following lines of code, the application first creates a VIEW Intent for the target Web site, in our example https://market.android.com and dispatches it to the system. This will cause Android to launch the default browser and load the specified Web site. The application then sleeps for 10 seconds to wait for the Web site to finish loading. It then dispatches an Intent containing javascript code to be executed within the context of the previously loaded Web site. here, the Intent will cause the browser to display the cookie information stored for https://market.android.com.

The following is the code sample in Java:

Uri uri = Uri.parse("https://market.android.com/");
Intent intent = new Intent (Intent.ACTION_VIEW, uri );
startActivity(intent) ;
Thread.sleep(10000);
uri = Uri.parse("javascript:alert(document.cookie);");
intent.setData(uri);
startActivity(intent);

Android Attacks in a Nutshell (Part I)

1.1 Android and Dalvik

Android is an OS designed for smartphones. It includes a sandbox application execution environment, and a customized embedded Linux system that interacts with the phone hardware and an off-processor cellular radio. The Binder and application API runs on top of Linux. Each application is executed within a Dalvik Virtual Machine (DVM).

Applications interact with each other and the phone through different forms of IPC. Intents are typed interprocess messages that are directed to particular applications or systems services, or broadcast to applications subscribing to a particular intent type. Persistent content provider data stores are queried through SQL-like interfaces. Background services provide RPC and callback interfaces that applications use to trigger actions or access data. Finally, user interface activities receive named action signals from the system and other applications. DVM runs .dex files that are designed to be more compact and memory-efficient than Java class files. DVM fucntions close to Java Virtual Machine (JVM), with differences in application structure, register architecture, instruction set, constant pool structure, ambigous primitive types, null reference and comparison of object references. [4]

Figure 1: The Android System Architecture [4]

1.2 Android Security Mechanism
Shabtai et. al [2] categorizes Android’s security mechanisms into three main categories:
 • Linux Mechanism
 • POSIX users
 • File Access
 • Environment features
 • Memory management unit (MMU)
 • Type safety
 • Mobile carrier security features
 • Android-specific mechanisms
 • Application permissions
 • Component encapsulation
 • Signing applications
 • Dalvik virtual machine

One of the most crucial elements inside the previously mentioned list is the application permission mechanism. Generally, Android permissions are categorized into 3 security levels: Normal, Dangerous, and Signature. Normal permissions protect API calls that could annoy but not harm the user (e.g., SET_WALLPAPER); these do not require user approval. Dangerous permissions let an application perform harmful actions (e.g., RECORD_AUDIO). Signature permissions regulate access to extremely dangerous privileges, e.g., CLEAR_APP_USER_DATA.

 Depending on which OS functionalities an application wants to access, the developer has to define the permissions that his application requires. All permissions an applications needs are specified in the AndroidManifest.xml file, which is part of the every application package. Typical permissions comprise e.g. android.permission.INTERNET permission, which allows applications to open network connections. The permissions that were defined by the developer are shown to the user during the installation process of the application. Upon seeing them, the user can either decide to install the application and grant it all requested permissions, or he can abort the installation process. Permissions can neither be granted individually nor can they be granted or revoked at runtime. This process is also called install time permission grant system, which is the opposite of Time-of-Use permission systems as in Apple iOS. The user either accepts all requested permissions, or he cannot install the application. 

In this report two attacks are presented. First is a Cross-Site Scripting (XSS) attack against WebKit Web engine. The attack is classfied under minor-impact attacks with high rate of occurance. Seocond attack is a permission re-delegation which is an intersect of taxanomies 4 and 6, each of which have severe-impact with medium and high rate of occurance, reprectively. For more details on security factors in Android, see [2].