Software Design Errors at the Borderline with Bugs

Hi there,

Today I’m going to write some my personal opinion about common Software Design Errors, that does not imply necessarly a Security Bug, but cause their Hybrid Nature could be placed at the borderline between a common Code Design Error.

The first basical and common error at the roots of a Design Error, or in the worst case of a Bug is the Input Validation, that became also the first Target to Attack, by generating in a first attempt Large Volume of Data to be received by the Software.

As you can imagine, the first Design Error is to Allow arbitrary lengths into File Formats or in every kind of interface disposed to received Data.

During time I’ve discovered some basical incongruences of well known applications, such ad in Visual Studio..

Visual Studio project file have a proprietary format, and are divided into various files: .sln, .user, .vcproj, .manifest

Each of this files has a particular structure, let’s see sln file format:

#Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
Project(“{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}”) = “NAME”, “PATH\PATH.vcproj”, “{17F30F81-3A72-40F0-85D5-9871C740B026}”
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Win32 = Debug|Win32
Release|Win32 = Release|Win32
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{17F30F81-3A72-40F0-85D5-9871C740B026}.Debug|Win32.ActiveCfg = Debug|Win32
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal

The directive Project(“{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}”) = “NAME”, “PATH\PATH.vcproj” and the fields Name and Path are totally unchecked, so an “attacker” can build evil versions of sln files by filling the Name field with large amounts of Data.

The result is a Memory Corruption Exploit, so as we have seen this Design Error became an effective bug..

Let’s see now .vcproj, that is an XML file which contains informations about compiling and linking options..

<VisualStudioProject
ProjectType=”Visual C++”
Version=”8,00″
Name=”NAME”
ProjectGUID=”{17F30F81-3A72-40F0-85D5-9871C740B026}”
RootNamespace=”MyNameSpace”
Keyword=”Win32Proj”

Also in this case Fields: Name, ProjectType, RootNamespace and Keyword are unchecked about the length aspect and checked about the Alowed Chars..

So an “attacker” can generate large ammounts of data which lead to Memory Consumpion, this is also valid for other fields of vcproj, such as

<Tool>
Name=”VCPreBuildEventTool”

Optimization=”0″
PreprocessorDefinitions=”WIN32;_DEBUG;_WINDOWS”
MinimalRebuild=”true”
BasicRuntimeChecks=”3″
RuntimeLibrary=”3″
UsePrecompiledHeader=”0″
WarningLevel=”3″
Detect64BitPortabilityProblems=”true”
DebugInformationFormat=”4″

<Tool/>

Same problem for .user files

<DebugSettings
Command=”$(TargetPath)”
WorkingDirectory=””
CommandArguments=””
Attach=”false”
DebuggerType=”3″
Remote=”1″

RemoteMachine=”ITX-C7″

RemoteMachine Field has unchecked length so big amounts of data, could block VisualStudio.

In the same way, an famous HTML Editor, 1stPage2000 could be easly crashed (due to an Heap Overflow) by producing large tags or large amounts of nidifications..

Is not necessary for an application like VS or 1stPage to allow so large names, should be better to avoid risks by ceching every length that should be manipulated..

See you to the next post..🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: