aws-lambda-rust-runtime VS OpenSSL

I've been writing more and more about the benefits of Rust and Lambda quite a bit lately and I plan to take advantage of them in this customizer. Additionally, I've leveraged the Lambda Runtime project that includes data structures for the Lambda Events that I'll encounter while working with these payloads.

The Lambda Rust Runtime project bridges that gap between SDK support and enhanced developer experience. Now this code IS flagged as experimental as it is subject to change. Didn't I just say above that I don't like experimental software in production? For something like a critical SDK into AWS, yes. But for something that is mostly data structures and working with different Lambda events, I don't have an issue. I'm comfortable with recommending builders look into this repository. I've also been fortunate to contribute to it and believe that the libraries included will make builder's lives easier. End of the day, if the experimental piece is a hold-up, a Lambda with Rust will be fine without it.

If you are building Rust applications that are deployed in Lambdas, it's well worth your time to check out this AWS project. And nestled inside that repository is a Lambda Events crate that helps with the serde/deserde of different payloads to be encountered when running Lambdas.

Feel free to take look at the GitHub repo and ask any questions you have there, we're always happy to help in what we can: https://github.com/awslabs/aws-lambda-rust-runtime

Rust on Lambda's using containers as the deployment artifact are also very good, i'd say a perfect match. Low artifact size, low cpu+memory usage, fast execution. I think AWS must be using increasingly using Rust on Lambda internally from the talks I've seen them publish and the work gone in to https://github.com/awslabs/aws-lambda-rust-runtime.

For simple REST API's there's not much extra effort in using Rust once you are familiar.

Check out the official AWS Lambda Rust project https://github.com/awslabs/aws-lambda-rust-runtime. It has a bunch of examples and we’ll designed. I got up and running knowing minimal Rust very quickly.

The official https://github.com/awslabs/aws-lambda-rust-runtime seems well architected.

Hi, maybe check out https://github.com/awslabs/aws-lambda-rust-runtime there's some examples in there.. But essentially you can build a Lambda function and deploy to your AWS account with this toolset.

use aws_lambda_events::apigw::{ ApiGatewayCustomAuthorizerRequestTypeRequest, ApiGatewayCustomAuthorizerResponse, ApiGatewayCustomAuthorizerPolicy, IamPolicyStatement, }; use lambda_runtime::{run, service_fn, Error, LambdaEvent}; use serde_json::json; #[tokio::main] async fn main() -> Result<(), Error> { tracing_subscriber::fmt() .with_ansi(false) .without_time() .with_max_level(tracing_subscriber::filter::LevelFilter::INFO) .init(); run(service_fn(function_handler)).await } pub async fn function_handler(event: LambdaEvent) -> Result { // do something with the event payload let method_arn = event.payload.method_arn.unwrap(); // for example we could use the authorization header if let Some(token) = event.payload.headers.get("authorization") { // do something with the token // my custom logic return Ok(custom_authorizer_response( "ALLOW", "some_principal", &method_arn, )); } Ok(custom_authorizer_response( &"DENY".to_string(), "", &method_arn)) } pub fn custom_authorizer_response(effect: &str, principal: &str, method_arn: &str) -> ApiGatewayCustomAuthorizerResponse { let stmt = IamPolicyStatement { action: vec!["execute-api:Invoke".to_string()], resource: vec![method_arn.to_owned()], effect: Some(effect.to_owned()), }; let policy = ApiGatewayCustomAuthorizerPolicy { version: Some("2012-10-17".to_string()), statement: vec![stmt], }; ApiGatewayCustomAuthorizerResponse { principal_id: Some(principal.to_owned()), policy_document: policy, context: json!({ "email": principal }), // https://github.com/awslabs/aws-lambda-rust-runtime/discussions/548 usage_identifier_key: None, } }

FYI, there’s an offical rust “runtime” in the works: https://github.com/awslabs/aws-lambda-rust-runtime

ENV OPENSSL_PREFIX=/opt/openssl ENV SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt WORKDIR /tmp RUN git clone --branch OpenSSL_1_0_2n https://github.com/openssl/openssl.git RUN cd openssl RUN ./config shared --prefix=$OPENSSL_PREFIX --openssldir=$OPENSSL_PREFIX/ssl RUN make RUN make install RUN rvm install 2.6.0 -C --with-openssl-dir=$OPENSSL_PREFIX ENV PATH /usr/local/rvm/bin:$PATH RUN rvm --default use ruby-2.6.0 ENV PATH /usr/local/rvm/bin:/usr/local/rvm/rubies/ruby-2.6.0/bin:$PATH ENV GEM_HOME /usr/local/rvm/rubies/ruby-2.6.0/lib/ruby/gems/2.6.0

Today, April 7th, 2024, marks the 10-year anniversary since CVE-2014-0160 was published. This security vulnerability known as "Heartbleed" was a flaw in the OpenSSL cryptography software, the most popular option to implement Transport Layer Security (TLS). In more layman's terms, if you type https:// in your browser address bar, chances are high that you are interacting with OpenSSL.

At this point I pretty much understand the entire process on how the xz backdoor came to be: its execution stages, extraction from binary "test" files etc. But one thing puzzles me: how can the ifunc mechanism be used to replace something like RSA_public_decrypt? Granted this probably stems from my lack of understanding of ifunc, but I was under the impression that in order for the ifunc mechanism to work in your code, you have to explicitly mark specific function with multiple implementations with __attribute__ ((ifunc ("the_resolver_function"))). Looking at the source code of the RSA function in question, ifunc attribute isn't present:

https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_crpt.c#L51

So how does the backdoor actually replace the call? Does this means that the ifunc mechanism can be used to override pretty much anything on the system?

OpenSSL and Go crypt/tls has no support yet, so none of the webservers that depend on them support it. Apache, Nginx, and Caddy, they all need upstream ECH support first.

- https://github.com/openssl/openssl/issues/7482

- https://github.com/openssl/openssl/pull/22938

- https://github.com/golang/go/issues/63369

If I'm understanding the draft correctly, I think the webserver you're hosting your sites on would need it implemented as it requires private keys and ECH configuration. In the example of nginx since it uses openssl, openssl would need to implement it. I found an issue on their Github but it's still open: https://github.com/openssl/openssl/issues/7482

I confirmed that the systm was on 1.1.1f with openssl version command. Hmm...... I check the openssl version in the repo with apt list... LOL package names wernt helpful. finally went to the repo pages and found that its still on 1.1.1f, https://launchpad.net/ubuntu/+source/openssl. Meenwhile I looked up the version history on https://www.openssl.org/ and saw that 1.1.1v was released at the beginning of this month... ok. I can understand it it was out less then 30 days. I looked up when f came out, end of MARCH 2020. NEARLY 3-1/2 YEARS