Monday, 25 June 2012

XPath & XPath Filter 2.0 Transform Injection

Attack surface: Key resolution, reference resolution

Attack impact: Denial of service

Exploit scenario: Complex XPath expressions can be costly to process. XPath Filters allow Union, Intersection and Subtraction operations on an XML node set using multiple XPath selections. Intended as a performance optimization, large filter sets specifying many complex XPath expressions can quickly consume many system resources.

Mitigation: Do not process KeyInfo, or keys identified by RetrievalMethod. Restrict the total number of transforms. Reject, via out-of-band schema or DTD validation, any Reference or RetrievalMethod specifying XPath or XPath Filter 2.0 transforms unless required. Identifying content by a whole document reference or by ID is preferable.

Applies to XML Encryption? Yes

Saturday, 23 June 2012

Parallelization of the Application Program

While machines like Teradata and Gamma separate the application
program running on a host processor from the database software
running on the parallel processor, both the Tandem and Bubba systems
use the same processors for both application programs and the parallel
database software. This arrangement has the disadvantage of requiring a
complete, full-function operating system on the parallel processor, but it
avoids any potential load imbalance between the two systems and allows
parallel applications. Missing, however, are tools that would allow the 
application programs themselves to take advantage of the inherent
underlying parallelism of these integrated parallel systems. While automatic
parallelization of applications programs written in Cobol may not be
feasible, library packages to facilitate explicitly parallel application programs
are needed. Support for the SQL3 NOWAIT option in which the application
can launch several SQL statements at once would be an advance. Ideally the
SPLIT and MERGE operators could be packaged so that applications
could benefit from them.

Wednesday, 20 June 2012

Next-generation parallel database systems

The penetration of database technology into new application areas with different
requirements than traditional business data processing has motivated the notion
of next-generation database systems. One major objective is that
the data model to be supported must be more powerful than the relational
model, without compromising its advantages (data independence and high-level
query languages). When applied to more complex application domains such as
engineering, office information systems, and expert systems, the relational data
model exhibits limitations in terms of rule management, type system and complex
object support.

To address these issues, two important technologies, KBMSs and
OODBMSs, are currently being investigated. Initially considered antagonistic,
many believe today that a combination of their capabilities into deductive and
object-oriented database (DOOD) systems will shape next-generation, universal
database systems. For the same reasons which led to parallel relational database
systems, implementing KBMSs and OODBMSs on parallel computers can be
cost-effective. Obviously, this presents new, challenging research problems in
addition to the current issues of KBMSs and OODBMSs.

Monday, 11 June 2012

Retargetable API generation

The generator has been designed to be retargetable to different host languages by
separating the implementation in a generic front-end, which produces an abstract
representation of an API, and a host language specific back-end. For each host
language, code templates need to be provided for generating automata, escaping,
and pretty-printing. For the Java and PHP back-ends the templates amount to
420 and 400 lines of code respectively.

To make the implementation of a new back-end as lightweight as possible, the
generator back-ends produces parse trees of the host API, which can be unparsed
to a source API without the need for a pretty printer for the host language. In this
way, only a syntax definition of the host language is required.

Wednesday, 25 April 2012

Geometry Rendering

The sensing techniques described above produce a collection of point samples
on the surface of objects. The point cloud is usually transformed into a triangle
mesh for graphical rendering via standard mesh rendering techniques. Laser
scanning, stereo vision, and spacetime stereo can additionally capture images
of the scene which can be used to associate color with the point samples or as
a texture map for the resulting mesh. The simplest approach is to create
a triangulation of the points by connecting a point with its neighbors as determined
by the sensor layout. For example, a point corresponding to a pixel in the
camera of a structured light, stereo vision, or shaped light pulse system would
be connected to points corresponding to the neighboring pixels.

More advanced and complex procedures can fill holes, align, and merge multiple
depth maps of the same object. This creates a model that has more
complete geometry. A single depth map will only show the geometry of one
side and will have holes wherever there is occlusion. Multiple depth maps from
different viewpoints will reduce occlusion and the merging algorithm can also
guess to fill in holes. Unfortunately, most of these techniques do not work
with deformable objects because aligning the depth maps depends on the object
being rigid. A recent advance in geometry processing is able to extract
correspondences and merge point clouds of deforming objects. However, the
size of the dataset that can be processed is limited.

Monday, 2 April 2012

Updating Relational Data by SPARUL Statements

In many cases, an RDF view contains quad map patterns that maps all columns
of some table into triples in such a way that sets of triples made from different
columns are “obviously” pairwise disjoint and invoked IRI classes are bijections.
E.g., quad map patterns for RDF property tables usually satisfy these restrictions
because different columns are for different predicates and column values are
used as object literals unchanged. We are presently extending SPARUL
compiler and run-time in order to make such RDF views updatable.

The translation of a given RDF graph into SQL data manipulation statement
begins with extracting all SQL values from all calculatable fields of triples and
partitioning the graph into groups of triples, one group per one distinct extracted
primary key of some source table. Some triples may become members of more
than one group, e.g., a triple may specify relation between two table rows. After
integrity check, every group is converted into one insert or delete statement.

The partitioning of N triples requires O(N lnN) operations and keeps data in
memory so it’s bad for big dump/restore operations but pretty effecient for
transactions of limited size, like individual bookeeping records, personal FOAF
files etc.

Sunday, 1 April 2012

IP Address Allocation

A new node will be assigned randomly one of the lowest free addresses
contained in the FAT, which means that the IP address is assigned in an
increasing order from a randomly chosen IP Address Block. We impose to
the new joining node to obtain its IP address from at least K nodes. We
use for this purpose the threshold signature described above and the new
concept of ‘On-line Joint IP address and Public Key Certificate’. Each
allocated IP address in the network is bound to node’s identity by means
of this certificate which must be signed by the On-line CA.

After having received a signed IP Address, the new node must broadcast
a signed registration message to all nodes to be able to participate actively
in the network. Any assigned IP address which is not registered yet is
removed from the FAT and kept in the PAT, either by the K signer nodes
after having assigned this address or by all nodes after having received a
registration message for a higher IP address in the same IP Address Block.
If the registration message is received the IP address is removed from the
PAT and put in the RAT.

Figure 1. Functional Blocks of TCSAP and DPKI modules