Search

Recent progress in large language code models (LLCMs) has led to a dramatic surge in the use of software development. Nevertheless, it is widely known that training a well-performed LLCM requires a plethora of workforce for collecting the data and high quality annotation. Additionally, the training dataset may be proprietary (or partially open source to the public), and the training process is often conducted on a large-scale cluster of GPUs with high costs. Inspired by the recent success of imitation attacks in extracting computer vision and natural language models, this work launches the first imitation attack on LLCMs: by querying a target LLCM with carefully-designed queries and collecting the outputs, the adversary can train an imitation model that manifests close behavior with the target LLCM. We systematically investigate the effectiveness of launching imitation attacks under different query schemes and different LLCM tasks. We also design novel methods to polish the LLCM outputs, resulting in an effective imitation training process. We summarize our findings and provide lessons harvested in this study that can help better depict the attack surface of LLCMs. Our research contributes to the growing body of knowledge on imitation attacks and defenses in deep neural models, particularly in the domain of code related tasks., Comment: 11 pages

Due to the open-source nature of the blockchain ecosystem, it is common for new blockchains to fork or partially reuse the code of classic blockchains. For example, the popular Dogecoin, Litecoin, Binance BSC, and Polygon are all variants of Bitcoin/Ethereum. These "forked" blockchains thus could encounter similar vulnerabilities that are propagated from Bitcoin/Ethereum during forking or subsequently commit fetching. In this paper, we conduct a systematic study of detecting and investigating the propagated vulnerabilities in forked blockchain projects. To facilitate this study, we propose BlockScope, a novel tool that can effectively and efficiently detect multiple types of cloned vulnerabilities given an input of existing Bitcoin/Ethereum security patches. Specifically, BlockScope adopts similarity-based code match and designs a new way of calculating code similarity to cover all the syntax-wide variant (i.e., Type-1, Type-2, and Type-3) clones. Moreover, BlockScope automatically extracts and leverages the contexts of patch code to narrow down the search scope and locate only potentially relevant code for comparison. Our evaluation shows that BlockScope achieves good precision and high recall both at 91.8% (1.8 times higher recall than that in ReDeBug). BlockScope allows us to discover 101 previously unknown vulnerabilities in 13 out of the 16 forked projects of Bitcoin and Ethereum, including 16 from Dogecoin, 6 from Litecoin, 1 from Binance, and 4 from Optimism. We have reported all the vulnerabilities to their developers; 40 of them have been patched or accepted, 66 were acknowledged or under pending, and only 4 were rejected. We further investigate the propagation and patching processes of discovered vulnerabilities, and reveal three types of vulnerability propagation from source to forked projects, as well as the long delay (over 200 days) for releasing patches in Bitcoin forks., Comment: The paper was accepted by ISOC NDSS 2023

BackgroundBoth apatinib and programmed death 1 (PD-1) monoclonal antibody (mAb) monotherapy have been licensed in China for the third-line treatment of advanced gastric cancer (AGC). However, whether the combination could improve the prognosis of patients with AGC after second-line treatment has not been evaluated.MethodsWe retrospectively screened 892 patients with AGC who received third-line or later treatment from June 2016 to July 2021 at the Affiliated Cancer Hospital of Zhengzhou University and second People’s Hospital of Pingdingshan. 166 patients who received apatinib plus PD-1 mAb, apatinib, or PD-1 mAb were included. Based on medical records and follow-up data, we analyzed the efficacy and safety of these three treatment options.ResultsPatients received apatinib plus PD-1 mAb (n=49), apatinib monotherapy (n=63), or PD-1 mAb monotherapy (n=54). Apatinib plus PD-1 mAb showed significantly longer progression-free survival (PFS) and overall surivival (OS) compared with the apatinib monotherapy (PFS: 5.5 months versus 3.0 months; p=0.002; OS: 10 months versus 7.6 months; p=0.011) or PD-1 mAb monotherapy (PFS: 5.5 months versus 2.3 months; p=0.017; OS: 10 months versus 6.5 months; p=0.004). Apatinib plus PD-1 mAb showed higher ORR and DCR than the apatinib and PD-1 mAb monotherapy (ORR: 34.7% versus 6.3% versus 9.3%; p=0.001; DCR: 75.5% versus 44.4% versus 40.7%; p=0.001). Further subgroup analysis for PFS and OS shown consistent efficacy in most subgroups with apatinib plus PD-1 mAb versus apatinib monotherapy or PD-1 mAb monotherapy. Multivariate analyses suggested that apatinib plus PD-1 mAb was significantly associated with better PFS and OS. Most of the treatment-related toxicities were mild and tolerable.ConclusionCompared with the monotherapy of either apatinib or PD-1 mAb, apatinib plus PD-1 mAb treatment yielded longer PFS and OS, and achieved significant higher ORR and DCR.

Crowdsourcing mobile user's network performance has become an effective way of understanding and improving mobile network performance and user quality-of-experience. However, the current measurement method is still based on the landline measurement paradigm in which a measurement app measures the path to fixed (measurement or web) servers. In this work, we introduce a new paradigm of measuring per-app mobile network performance. We design and implement MopEye, an Android app to measure network round-trip delay for each app whenever there is app traffic. This opportunistic measurement can be conducted automatically without users intervention. Therefore, it can facilitate a large-scale and long-term crowdsourcing of mobile network performance. In the course of implementing MopEye, we have overcome a suite of challenges to make the continuous latency monitoring lightweight and accurate. We have deployed MopEye to Google Play for an IRB-approved crowdsourcing study in a period of ten months, which obtains over five million measurements from 6,266 Android apps on 2,351 smartphones. The analysis reveals a number of new findings on the per-app network performance and mobile DNS performance., Comment: This paper has been accepted by 2017 USENIX Annual Technical Conference, ATC'17 (https://www.usenix.org/conference/atc17/technical-sessions/presentation/wu)

Cross-app collaboration via inter-component communication is a fundamental mechanism on Android. Although it brings the benefits such as functionality reuse and data sharing, a threat called component hijacking is also introduced. By hijacking a vulnerable component in victim apps, an attack app can escalate its privilege for originally prohibited operations. Many prior studies have been performed to understand and mitigate this issue, but component hijacking remains a serious open problem in the Android ecosystem due to no effective defense deployed in the wild. In this paper, we present our vision on practically defending against component hijacking in Android apps. First, we argue that to fundamentally prevent component hijacking, we need to switch from the previous mindset (i.e., performing system-level control or repackaging vulnerable apps after they are already released) to a more proactive version that aims to help security-inexperienced developers make secure components in the first place. To this end, we propose to embed into apps a secure component library (SecComp), which performs in-app mandatory access control on behalf of app components. An important factor for SecComp to be effective is that we find it is possible to devise a set of practical in-app policies to stop component hijacking. Furthermore, we allow developers design custom policies, beyond our by-default generic policies, to support more fine-grained access control. We have overcome challenges to implement a preliminary SecComp prototype, which stops component hijacking with very low performance overhead. We hope the future research that fully implements our vision can eventually help real-world apps get rid of component hijacking., Comment: This is a technical report on Android security from Singapore Management University

Mobile network performance measurement is important for understanding mobile user experience, problem diagnosis, and service comparison. A number of crowdsourcing measurement apps (e.g., MobiPerf [4, 6] and Netalyzr [5, 7]) have been embarked for the last few years. Unlike existing apps that use active measurement methods, we employ a novel passive-active approach to continuously monitor per-app network performance on unrooted smartphones without injecting additional network traffic. By leveraging the VpnService API on Android, MopEye, our measurement app, intercepts all network traffic and then relays them to their destinations using socket APIs. Therefore, not only MopEye can measure the round-trip time accurately, it can do so without injecting additional traffic. As a result, the bandwidth cost (and monetary cost of data usage) for conducting such a measurement is eliminated, and the measurement can be conducted free of user intervention. Our evaluation shows that MopEye's RTT measurement is very close to result of tcpdump and is more accurate than MobiPerf. We have used MopEye to conduct a one-week measurement revealing multiple interesting findings on different apps' performance., Comment: This is the copy of our CoNEXT'15 poster, published in December 1, 2015. MopEye is available on Google Play at https://play.google.com/store/apps/details?id=com.mopeye